微服务架构：聊天服务或数据复制

Posted 2023-03-08

【中文标题】微服务架构：聊天服务或数据复制

【英文标题】：Microservices Architecture: Chatty services or data duplication

【发布时间】：2017-08-31 23:24:24

【问题描述】：

TL;DR 服务应该选择将数据保存在其偶尔需要的本地数据库中，还是每次都向数据来源的服务请求数据？

让我们举一些网络商店/订购应用程序的通用示例。服务 A 是用户会话管理服务。它处理用户正在做什么、他能做什么等业务逻辑。用户可以创建自己的衬衫以供购买。服务 B 是一个数据聚合器，包含大量库存和可用数据。

用户开始创建衬衫，因此服务 A 向服务 B 请求，有哪些款式/颜色可用。服务 B 发送一个可能的选择列表，然后服务 A 为用户显示该列表。然后用户选择一件，对其进行定制，然后穿上一件新衬衫。同样，服务 A 必须向服务 B 请求可用的样式/颜色。

现在让我们假设在用户会话的生命周期内，这些样式/颜色不会改变，我们知道这将是一遍又一遍地检索相同的数据。不仅仅是这个用户，而是所有用户。所以在这种情况下，由于样式/颜色确实是服务 B 域的一部分，它们应该留在那里并住在那里，或者是否建议防止所有这些不必要的调用，并在第一次请求时（暂时）保存在服务 A 中会话生命周期的数据，以防止聊天服务。

这是一个过于简单的示例，但问题仍然存在于现实世界中。哪种方式更适合构建此设计？ 这通常适用于例如当一些相当静态的数据正在通过某个服务时，并且该服务将在这些事务的生命周期内再次需要这些数据几次。所以我不确定该服务是否应该在生命周期中暂时保存它，知道数据不会改变，或者不关心它是否在生命周期内发生变化，或者选择更多的聊天服务并每次都继续请求。

【参考方案1】：

我必须赞扬你写得很好的问题，但答案当然很大程度上取决于你正在处理的业务逻辑。这个问题与最终一致性（一些无 sql 数据库提供的属性 - 如 Couchbase）有关。

最终，这是一个权衡问题：检索最新数据的“成本”与使用容易获得的陈旧数据的成本。

有几个因素：

数据多久更新一次？

更重要的是，当您使用陈旧数据时会发生什么（业务逻辑方面）。您的用户/应用是否可以接受它？

每次获取新数据对您的系统有何影响？这样做的基础设施成本是多少（机器/金钱）以及它会产生什么延迟？

【讨论】：

最重要的是，复制状态甚至可能导致数据源中的不同步 - 由于错误、停机时间等原因，通常甚至无法保证最终的一致性。因此，虽然过期缓存似乎没问题，但复制持久化数据也有风险。

【参考方案2】：

TL;DR 服务应该选择将数据保存在其偶尔需要的本地数据库中，还是每次都向数据来源的服务请求数据？

我不想这么说，但这取决于。这取决于您的业务需求。这取决于您是否想要拥有一个灵活的系统。如果service B 不可用，您希望service A 表现如何？你有两个选择：

您希望 Service A 拒绝工作，因为它无法从 service B 获取新数据。如果数据变化很大或者service A 中使用的数据必须始终是超新鲜的，您可以这样做。

您希望Service A 继续工作，可能通过通知用户数据可能不是最新的。在这种情况下，您应该通过监听事件或缓存将数据从 service B 复制到 service A。

【参考方案3】：

有一种不同的解决方案可以“回避”这种权衡。

您的问题表明您更多地考虑“旧”“面向服务”的方法。也就是说，服务基本上是提供数据的面向数据的服务。比如“Inventory”、“Session”、“Customer”等。

另一种方法是，这与 DDD 有界上下文非常相似，根据业务领域分解应用程序。这导致了一个完全不同的架构，其中数据没有与在其上工作的功能分离。有点像面向对象。

这将导致 Shirt-Configurator 拥有自己的数据库，其中包含所有相关信息，包括会话、库存等。此外，还包括 UI。

另一个应用程序可能是结帐。结帐可以是一个完全独立的应用程序，只需将 URL 返回到 Shirt-Configurator 以获得正确的演示。 Checkout 应用程序不必调用甚至知道 Shirt-Configurator。

等等……

更多关于这种架构风格的信息：http://scs-architecture.org/

【讨论】：

这里的挑战是业务领域重叠很多。如果衬衫配置器需要库存，您要么将它们视为单个有界上下文（并创建一个大型单体），要么处理非常闲聊的通信以更新库存。我同意分离功能的一般想法，但这与微服务架构的更“微”变体形成对比。