design-patterns - 微服务 : aggregate data : is there some good patterns?

Question

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

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

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

请查看图片了解更多详情!

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

Answer 1

以上就是微服务的一个常见问题——域的分离。尽管每个服务都在不同的域中执行任务，但它们包含与其他服务“拥有”的数据的关系。您当前解决它的方式实际上是管理实现的更简单的方法之一，因为它不是非常复杂，但是有一些更有效的解决方案。

1. 复制

采用微服务时很难理解的一件事是数据复制并不是一件坏事。虽然感觉数据在多个地方徘徊，但服务的创建者实际上通过将他们需要的数据复制到他们自己的托管数据库中而获得了更多的自主权。

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



来源:The Hardest Part About Microservices: Your Data

2. 将数据库从里到外

另一个越来越普遍的策略更难理解，但为不断发展的微服务架构提供了很多长期值(value)。与其将服务的数据库视为持久存储，不如将它们视为 View 。所有写入都可以转到中央源，而服务则定义如何将该中央数据映射到持久 View 中以供其读取服务。这让我们的服务定义了包含其他服务写入的数据的 View ——同样，不限制服务创建者的自主权。

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

3.合并服务

根据您对增长的预期，可能不值得实现上述任何一种解决方案。鉴于数据的关系性质，您可能只想将服务合并到一个服务中，该服务可以使用连接来查询并自行构建模型。

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