与其他服务共享的微服务数据库

Question

我一直在寻找但找不到直接答案的东西是：

对于给定的服务，如果该服务的两个实例部署到两台计算机上，它们是否共享相同的持久性存储，或者它们具有具有某种同步机制（主/从属，集群）的单独存储？

例如，我有一个由MySQL支持的OrderService。我们收到很多订单，因此我需要扩大此服务的规模，因此我们部署了第二个OrderService。它的数据从哪里来？

这听起来很愚蠢，但是对我来说，每次讨论都似乎使服务和数据库看起来像是一起部署的打包单元。但是很少有讨论提到部署第二个服务时会发生什么。

Answer 1

将其发布为答案，因为评论太长了。

微服务是独立的组件，因此负责它们自己的数据。如果要获取数据，则必须与服务API进行通信。这主要适用于不同类型的服务（即，您不会在提供不同类型业务功能的服务之间共享数据库-这是不好的做法，因为您通过数据库将堆中的服务耦合在一起，然后很容易将更多的事情耦合在一起通常可以在API级别完成操作，但通过数据库进行操作更方便=>您可能会失去组件化的风险）。

但是，如果您拥有相同类型的服务，那么正如您提到的，有两个明显的选择：共享一个数据库或让每个服务都包含它自己的数据库。

现在，您必须问自己选择哪种解决方案：

• 您中的这些人是否OrderService真的有能力自己工作，还是需要将所有订单都放在同一个数据库中以供其他应用程序报告或访问？
• 确定您的实际瓶颈是什么。是数据库吗？如果没有，则共享数据库。是服务吗？如果没有，则分发您的数据。
• 需要分发数据吗？您有什么选择，您有什么需求？您是否需要一直保持一致，还是最终的一致性足够好？您是否需要拥有单独的数据库并手动进行同步，还是您的数据库安装可以开箱即用地处理复制和分区？
• 等等

我要说的是，在这种情况下，答案是：取决于情况。在开始进行此类分布式/可伸缩性/体系结构之旅之前，我们的技术极客经常忘记做的事情就是与业务联系。通常，企业可以处理一定程度的不一致，处理过程不理想或在更多地方而不是一个地方查找数据（即，您认为重要的事情不一定适用于企业）。因此，与他们交谈，看看他们可以容忍什么。以一种可操作的方式解决问题的成本可能要比投入大量精力来尝试构建高度可分配的系统便宜。