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

Question

我搜索过但找不到直接答案的是：

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

E.g。我有一个由MySQL支持的OrderService。我们收到了很多订单，因此我需要扩展此服务，因此我们部署了第二个OrderService。它的数据来自哪里？

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

Answer 1

将此作为答案发布，因为评论时间过长。

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

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

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

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

我想说的是，在这种情况下，答案是：它取决于。在开始这样的分布式/可扩展性/架构旅程之前，我们技术人员经常忘记做的事情就是与业务部门交谈。业务通常可以处理某种程度的不一致，次优的流程或在更多地方查找数据而不是一个（即您认为重要的可能不一定是业务）。所以和他们交谈，看看他们能忍受什么。以操作方式解决问题可能比投入大量资金以建立高度可分配的系统更便宜。