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

Question

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

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

用户开始创建衬衫，因此service a请求service B提供可用的样式/颜色。服务B向下发送一个可能的选择列表，然后服务a为用户显示该列表。然后，用户选择一件衬衫，对其进行自定义，然后换上一件新衬衫。同样，服务A必须向服务B请求可用的样式/颜色。

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

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

Answer 1

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

我不想这么说，但这要看情况而定。这取决于您的业务需求。这取决于您是否想要一个rezilient系统。如果service B不可用，您希望service A如何表现？您有两种选择：

>

您希望服务A拒绝工作，因为它无法从服务B获取新数据。如果数据发生了很大变化，或者服务a中使用的数据必须始终保持超级新鲜，则可以执行此操作。

您希望Service A继续工作，可能需要通知用户数据可能不新鲜。在这种情况下，您应该通过侦听事件或缓存将数据从服务B复制到服务A。

Answer 2

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

归根结底，这是一个权衡的问题：检索最新数据的“成本”与使用现成的陈旧数据的成本。

一些因素包括：

>

数据多久更新一次？

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

每次获取新数据会对您的系统产生什么影响？这样做的基础架构成本是多少（以机器/金钱为单位），以及它会导致什么样的延迟？

Answer 3

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

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

另一种方法是根据业务领域分解应用程序，这与DDD有界上下文非常相似。这会导致完全不同的架构，其中数据不会与处理它的函数分开。有点像面向对象。

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

另一个应用程序可能是Checkout。签出可以是一个完全独立的应用程序，只需将URL返回Shirt-Configurator以获得正确的演示文稿。Checkout应用html" target="_blank">程序不必调用甚至不知道Shirt-Configurator。

等等

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