微服务：聚合数据：有没有一些好的模式？ [英] Microservices : aggregate data : is there some good patterns?

问题描述

我有以下微服务体系结构的使用案例。

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

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

请查看图片了解更多详细信息！

这是个好式样吗？还有其他图案吗？

推荐答案

上述是微服务的常见问题-域分离。虽然每个服务在不同的域中执行任务，但它们包含与其他服务"拥有"的数据的关系。您当前解决该问题的方法实际上是管理实现的较简单方法之一，因为它并不是特别复杂，但是有一些解决方案更有效。

1.复制

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

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

来源：The Hardest Part About Microservices: Your Data

2.将数据库内翻过来

另一种日益常见的策略甚至更难理解，但它为不断发展的微服务体系结构提供了很多长期价值。不要将服务的数据库视为持久存储，而应将其视为视图。所有写入都可以转到一个中心源，而服务则定义如何将该中央数据映射到其读取服务的持久视图中。这让服务定义包括由其他服务编写的数据的视图-同样，不限制服务创建者的自主性。

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

3.合并服务

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

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

这篇关于微服务：聚合数据：有没有一些好的模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！