4

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

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

例如，我有一个由 MySQL 支持的 OrderService。我们收到了很多订单，所以我需要扩大这项服务，所以我们部署了第二个 OrderService。它的数据来自哪里？

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

4

1 回答 1

5

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

微服务是自包含的组件，因此对自己的数据负责。如果您想获取数据，您必须与服务 API 对话。这主要适用于不同类型的服务（即，您不会在提供不同类型业务功能的服务之间共享数据库 - 这是不好的做法，因为您通过数据库在堆上耦合服务，然后很容易耦合更多会通常在 API 级别完成，但通过数据库更方便 => 您可能会失去组件化）。

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

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

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

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

于 2015-05-16T11:16:44.413 回答