跨微服务查询/分页

Question

我们的工作室最近开始采用SOA方法进行应用程序开发.我们看到SOA /微服务的关注点,可重用性和其他好处的分离带来了很多好处.

但是,我们坚持的一个重要项目是跨服务聚合,过滤和分页结果.让我用场景描述问题.

假设我们有3项服务:

1. PersonService - 存储人员信息(姓名,地址等)
2. ItemService - 存储可购买物品的信息.
3. PaymentService - 存储有关人们为不同项目付款的信息.

现在,假设我们要构建一个可以汇总显示/报告多个服务的报告/管理工具.例如,我们希望显示付款的分页列表,以及每笔付款所针对的人员和项目.这非常简单:获取付款清单,然后查询PersonService和ItemService以获取相应的Person和Item记录.

但是,当我们想要过滤掉这些数据时,问题就会发挥作用:例如,显示由名为"Bob"的人制作的分段付款清单,他们购买了"Car"项.这使得事情变得更加复杂,因为我们需要从3个不同的服务中过滤结果,而不知道每个服务将返回多少结果.

从性能的角度来看,一遍又一遍地查询所有服务以缩小结果将是代价高昂的,所以我一直在研究更好的解决方案.但是,我找不到解决这个问题的具体方法(或者至少是"最佳实践").在单个应用程序中,我们只是在不同的表中使用SQL连接.我在确定如何/如果在服务之间可能出现类似情况时遇到了很多麻烦.

我对社区的问题是:你的方法是什么？我考虑过的事情:

1. 使用某种搜索索引(Elasticsearch,Solr),其中包含所有服务的所有数据(通过服务推出的事件更新),然后查询搜索索引的结果.
2. 试图了解GraphQL和Neo4j等项目如何帮助我们解决这些问题.

Answer 1

我坚持使用Sam Newman，他在他的书的第 4 章“共享数据库”中说：

还记得我们讨论过良好微服务背后的核心原则吗？强内聚和松耦合——通过数据库集成，我们失去了这两样东西。数据库集成使服务共享数据变得非常容易，但对共享行为没有任何作用。我们的内部表示通过网络暴露给我们的消费者，并且很难避免进行重大更改，这不可避免地导致对任何更改的恐惧。不惜一切代价避免（几乎）。

这就是我在内容管理系统中诅咒时提出的观点。

在我看来，微服务是自治的，如果它共享事物或消费共享事物，它就不是自治的。我在这里提出的唯一例外是域对象，它们代表了对业务模型的共同理解，并且必须仅用于微服务之间的通信。

如果 ER 或 AggregationOriented 数据库（分为基于文档或基于图）更适合需求，这取决于微服务本身。有趣的是，通过 loosley 耦合和自治，您可以做到这一点！

如果 PaymentService 共享“为 A 人支付了多少款项”的行为，则他需要了解 A 人才能实现这一点。但是他所知道的关于 Person A 的一切都必须来自 PersonService，可能是在运行时（PaymentService 可能只存储一个 id）或基于事件（PaymentService 将它需要的数据存储到域对象用户，更新触发和提供的数据）由 PersonService 提供）。PaymentService 本身不共享用户本身。

Answer 2

这个问题的答案是，您需要一个单独的Read Database或Materialized View聚合来自多个数据库的数据，并使其为快速检索做好准备。请参阅 CQRS 模式：https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs

中的数据Materialized View可能不是“最新的”，这意味着相应微服务进行更改的时间与更新“物化视图”的时间之间可能存在微小的延迟，但这很好，因为快速检索数据比数据陈旧几秒钟甚至几分钟更重要（在某些系统中，物化视图可能需要 2-5 分钟才能更新，但这可能仍然可以接受）

实现此功能Read Database或Materialized View来自 CQRS 的最佳模式通常是事件溯源模式，我们可以在其中监听队列以获取新更新并Read Database立即更新。请参阅事件溯源模式：https ://learn.microsoft.com/en-us/azure/architecture/patterns/event-commerce