微服务架构：查询服务或数据备份

Question

TL; DR服务是否应该选择将数据保存在本地数据库中，或者每次从数据源发出的服务请求数据？

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

用户开始创建一件衬衫，因此服务来自服务B的请求，可用的样式/颜色。服务B发送服务A然后显示给用户的可能选择的列表。用户然后选择一个，定制它并移动到新的衬衫上。再次，服务A必须从服务B请求什么样式/颜色可用。

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

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

Answer 1

有一个不同的解决方案，“副作用”这种权衡。

您的问题表明您正在考虑采用“旧”“面向服务”方式。也就是说，服务基本上是提供数据的面向数据的服务。如“库存”，“会话”，“客户”等。

另一种方法是，根据业务领域分解应用程序，这与DDD有界上下文非常相似。这导致了一个完全不同的体系结构，其中数据不会与其上运行的函数分离。有点像面向对象。

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

另一个应用程序可能是结帐。结帐可以是一个完全独立的应用程序，只需将URL返回到衬衫配置器即可获得适当的展示。 Checkout应用程序不需要打电话甚至不知道衬衫配置器。

等等......

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

Answer 2

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

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

几件事因素：

• 多久数据更新？

• 更重要的是，当您使用陈旧的数据时会发生什么（商业逻辑）。您的用户/应用程序甚至可以接受吗？

• 每次获取新数据会对系统产生什么影响？这样做的基础设施成本是多少（以机器/货币计算），它会产生什么样的延迟？

Answer 3

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

我不想说这个，但它取决于。这取决于您的业务需求。这取决于你是否想要有一个rezilient系统。如果service B不可用，您希望service A的行为如何？你有两个，选项：

1. 你想Service A拒绝工作，因为它不能从service B获得新的数据。如果数据变化很大，或者在service A中使用的数据必须始终保持超新，您可以这样做。

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