我应该加入还是拆分这些使用相同数据库的微服务？

Question

我正在为餐厅开发一个应用程序来管理他们拥有的产品和顾客的订单。所以我在设计微服务架构时遇到了问题。

我想拥有一个

ProductManagementService

和另一个

OrderService

。但我面临的问题是

OrderService

应该能够访问我的数据库中的

Products

表并访问其价格等信息，出于显而易见的原因，

ProductManagementService

也是如此。

遇到这种情况我该怎么办？我想我有两个选择：

1. 在这两个服务之间共享数据库
2. 或

   OrderService

   每次询问

   ProductManagementService

   产品信息

但我认为第二个选项会使

OrderService

过于依赖于

ProductManagementService

，因为每次下订单时都必须调用它，使它们过于耦合。

还有其他方法可以使其适用于不同的数据库吗？

我想过让 2 个不同的数据库同步同一个表，但我不知道这是否是一个好方法。

Answer 1

最好避免跨微服务共享数据库。它违背了微服务的基本特性。

您拥有两个不同数据库的方法很好。有一种称为“每个服务一个数据库”的模式，它有助于松散耦合、可扩展和独立的微服务。它还允许您为每个微服务选择不同的数据库。 您不需要复制两个数据库中的表，只需在需要时从您的

ProductManagementService

调用

OrderService

API即可。但在这种情况下，一项服务依赖于其他服务来获取信息，因此您还需要处理故障场景。就像

ProductManagementService

宕机一样，您需要实施断路器机制来处理这种情况。

Answer 2

OrderService

和

ProductManagementService

）。当订单服务需要产品数据时，应通过API或其他技术请求。如需更多见解，请参阅 Martin Fowler 在其文章的“去中心化数据管理”部分中关于独立微服务的数据存储分离的想法：

Martin Fowler 的微服务

。 但是，正如您所观察到的，这种方法引入了跨多个数据源同步数据和维护一致性的复杂性（Fowler 也解决了这一挑战）。

最终，这个

决定需要权衡

。考虑诸如系统规模、您想要的粒度级别以及您想要实现的关注点分离等因素。如果分离数据库的决定可以通过其带来的好处来证明（尽管重构工作量增加、数据同步的开销以及潜在的额外基础设施成本），那么您可以继续为每个服务使用一个单独的数据库。 作为一种稍微妥协的方法，您可以使用单个数据源，但明确定义和分离服务及其数据所有权。例如，

OrderService

不应操纵产品数据，这应由

ProductManagementService

承担全部责任。有关此方法的更多信息，请阅读本文：

每个服务的数据库或共享数据库

。