微服务：汇总数据：是否有一些好的模式？

我有以下微服务架构用例。

我的问题是，在当前情况下，我有3个微服务和一个APIGateway。

最后，网关必须进行大量查询，然后才能聚合（组合）来自这三个服务的数据。因为这三个微服务仅提供基本数据集。

请检查图片以获取更多详细信息！

这是一个好模式吗？还有其他模式吗？

上面是微服务的一个常见问题-域的分离。尽管每个服务都在不同的域中执行任务，但它们包含与其他服务“拥有”的数据的关系。您当前正在解决的方法实际上是管理实现的一种较容易的方法，因为它并不十分复杂，但是有些解决方案却更有效。

1.复制

采用微服务时，很难扎根的一件事是数据复制并不是一件坏事。尽管感觉好像数据在多个地方晃来晃去，但实际上通过将服务所需的数据复制到自己的托管数据库中，可以为服务的创建者提供更大的自治权。

如果要将事件发布到共享队列中，则可以为微服务设置读取/同步过程，该过程依赖于来自其他服务的数据来读取所述事件并将数据镜像到私有数据库中。在您的示例中，这意味着Catalog服务将能够返回API网关返回的完全填充的模型，而无需调用其他服务。

资料来源：关于微服务的最困难部分：您的数据

2.由内向外翻数据库

另一个日益普遍的策略甚至更难以为继，但它为不断发展的微服务架构提供了许多长期价值。不要将服务的数据库视为持久性存储，而应将它们视为视图。所有写入都可以转到中央源，而服务定义了如何将中央数据映射到用于其读取服务的持久性视图中。让我们的服务定义视图，该视图包含其他服务编写的数据-再次，不限制服务创建者的自治权。

资料来源：使用Apache Samza彻底颠覆数据库

3.合并服务

根据您对增长的期望，可能不值得实施上述两种解决方案。考虑到数据的关系性质，您可能只想将服务合并到一个可以使用联接进行查询和自身构建模型的服务中。

注意：以上所有选项都具有一个主要相似点-不必依赖自定义网关来深入了解每种服务并建立模型关系。确保每个服务都有足够的信息和上下文来独自执行有意义的任务。