微服务架构中的数据库位置

Posted 2023-03-08

【中文标题】微服务架构中的数据库位置

【英文标题】：Database location in Microservices Architecture

【发布时间】：2017-09-09 02:52:32

【问题描述】：

我们有一个单体应用程序，现在我们正在使用容器将其转换为微服务架构。

我们的微服务是有状态的（即它们需要从数据库中插入/检索数据）。根据微服务架构，每个微服务都应该有自己的数据（在我们的例子中就是数据库）。

我的问题是每个微服务的数据库应该部署在哪里，是否应该在部署微服务的同一主机中，在部署微服务的同一容器中还是它应该在 azure db 之类的单独服务器中？

每种方法的优缺点是什么？根据微服务最佳实践，最佳方法是什么？ *

【问题讨论】：

“在部署微服务的同一个容器中” - 绝对不是，容器最佳实践规定容器中只能运行一个进程

这是一个很好的观点@ConstantinGALBENU

只是为了澄清（并且稍微偏离主题），Service Fabric 上下文中的有状态服务与将其状态存储在外部数据存储中的服务不同。 SF 中的有状态服务假设它们会将其状态存储在可靠的集合中，这些集合是 Service Fabric 的一部分。

“我们的微服务是有状态的（即它们需要从数据库中插入/检索数据）。”你确定它们是有状态的吗？

【参考方案1】：

您是对的，每个微服务都应该使用最适合其需求的自己的数据存储。可能有一个服务想要将其数据存储在 blob 存储中，另一个可能将其数据存储在表存储或 DocumentDb 或 SQL 数据库中。

您可能希望使用数据库即服务，因此不托管您自己的数据库，因为您不必担心可用性、扩展性和备份。 ..

【参考方案2】：

Martin 的回答很好，但我想补充一点，因为您使用的是容器化应用程序，您应该绝对将数据库与服务容器分开部署。原因是您的服务可以（独立地）发展，而无状态服务容器的最大好处之一是，如果您拥有它们的集群，您可以使用滚动更新来更新它们，而不会影响您的应用程序可用性。有状态数据库服务的更新更加困难，但预计也不会那么频繁（cockroachdb 等新技术即将出现）。 Good read.

【参考方案3】：

我并不在乎在哪里，只是它不能与您的应用程序在同一个容器中，如本线程前面所述。

重要的是只有 一 (1) 个微服务拥有数据的所有权。如果多个微服务需要访问数据，则它们必须通过拥有该数据的微服务提供的 API 访问它。

你可以这样组织它：

“Sql 微服务” - 处理所有进出 SQL Server 的流量。所有需要来自 Sql 的数据的微服务都与这些人交谈。您将拥有一个类似的 TableStorage 微服务。

如果“微服务 A”使用 Sql/TableStorage 中的其他数据存储，并且该数据存储是微服务 A 的本地数据，我将创建 2 个微服务。

微服务 A1 将是您的代码运行的地方 微服务 A2 有一个 API 将数据库操作公开给 A1。 当 A1 需要数据时，他会与 A2 对话。

除了这种模式允许您独立于应用程序节点扩展数据层之外，您还可以确保 数据 仅由一 (1) 个微服务拥有 这就是关键。