微服务中的数据聚合器/组合服务答案

【问题标题】：Data Aggregator/composition service in Microservices微服务中的数据聚合器/组合服务
【发布时间】：2022-08-19 23:38:02
【问题描述】：

我正在开发一个应用程序，其中有一个用于数据洞察的仪表板。后端是一组用 NodeJS express 框架编写的微服务，带有 MySQL 后端。使用的模式是 Database-Per-Service 模式，中间有一个消息代理。

我面临的问题是，我有这个仪表板，它从多个后端服务中获取数据（完全不同的数据库，有些是 sql，有些是 nosql，有些来自 graphDB）

我想避免此屏幕在前端和后端之间进行多次查询。但是，我也想避免单点故障。我想出了以下解决方案。

使用 API 网关聚合器/组合来代表单个前端请求对后端服务进行多次调用，然后将所有响应组合在一起并将其发送到客户端。但是，即使扩展一台服务器也需要扩展网关本身。此外，它使网关成为单点联系。
创建一个外观服务，可能称为仪表板服务，它在后端发出对多个服务的调用，然后将响应组合在一起并将单个有效负载发送回服务器。但是，这会创建同步依赖项。

我赞成方法 2。但是，我也有一个问题。由于服务是用 nodeJs 编写的，有没有办法为每个服务强制执行有时限的 SLA，如果服务不响应外观聚合器，客户端应该返回部分或缓存的数据？有没有相同的机制？

您是否考虑过允许dashboard-svc 拥有自己的数据库，也许是 Redis 用于性能/缓存，这样您就可以通过您的消息代理镜像来自其他服务的数据？您还可以通过实施健康检查服务（或利用现有服务）来避免调用“失败”服务。如果您认为这是一个可行的解决方案，我很乐意进一步详细说明。

【解决方案1】：

GraphQL 就是为此而设计的。

您首先定义一个涵盖微服务所有模式的全局 GraphQL 模式。然后你实现获取器，它将通过查询适当的微服务来“填充”响应。您可以启动多个实例，以免出现单点故障。如果您有超时，您可以返回部分响应（您的答案将包括解析器错误）。 GraphQL 知道如何管理缓存。

老实说，一开始有点困惑，但是一旦你掌握了它，扩展模式并将新的微服务包含到其中就真的很简单了。

【讨论】：