architecture - 微服务架构 : Chatty services or data duplication

Question

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

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

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

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

这是一个过于简化的例子，但问题仍然存在。哪种更推荐的架构设计方式？
这通常适用于例如当一些相当静态的数据通过某个服务时，并且该服务将在这些事务的生命周期内再次需要这些数据几次。所以我不确定服务是否应该在生命周期中暂时保存它，因为知道数据不会改变，或者不关心它是否在生命周期内发生变化，或者选择更多健谈的服务并每次都保持请求。

Answer 1

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

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

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

这将导致衬衫配置器拥有自己的数据库，其中包含所有相关信息，包括 session 、库存等。此外，包括用户界面。

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

等等...

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