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

Question

对于微服务体系结构，我有以下用例。

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

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

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

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

Answer 1

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

1。复制

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

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

来源：The Hardest Part About Microservices: Your Data

2。由内而外翻数据库

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

来源：Turning the database inside-out with Apache Samza

3。合并服务

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

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