rest - 如何合并/合并来自多个 RESTful 微服务的响应？

Question

假设有两个（或更多）服务于 JSON 的 RESTful 微服务。服务 (A) 存储用户信息（名称、登录名、密码等），服务 (B) 存储发往/来自该用户的消息（例如 sender_id、主题、正文、rcpt_ids）。

服务 (A) on/profile/{user_id}可能会响应：

{id: 1, name:'Bob'}

{id: 2, name:'Alice'}

{id: 3, name:'Sue'}

等等

服务 (B) 响应/user/{user_id}/messages返回一个发往该 {user_id} 的消息列表，如下所示：

{id: 1, subj:'Hey', body:'Lorem ipsum', sender_id: 2, rcpt_ids: [1,3]},

{id: 2, subj:'Test', body:'blah blah', sender_id: 3, rcpt_ids: [1]}

---

使用这些服务的客户端应用程序如何处理将消息列表放在一起以便显示名称而不是发送者/rcpt id？

方法 1：拉取消息列表，然后开始拉取每个 idsender_id和rcpt_ids?中列出的个人资料信息 这可能需要 100 个请求并且可能需要一段时间。相当幼稚和低效，可能无法与复杂的应用程序一起扩展？？？

方法2：拉取消息列表，提取所有用户ID并分别对所有相关用户进行批量请求......这假设存在这样的服务端点。在获取消息列表、提取用户 ID、发送批量用户信息请求以及等待批量用户信息响应之间仍有延迟。

理想情况下，我想一次性提供完整的响应集（消息和用户信息）。我的研究使我想到了在服务层合并响应……也就是方法 3：API 网关技术。

但是如何实现呢？

我可以获取消息列表，提取用户 ID，在幕后进行调用并获取用户数据，合并结果集，然后提供最终结果...这可以在幕后使用 2 个服务...但是如果消息列表依赖于更多服务...如果我需要在后台查询多个服务，进一步解析这些服务的响应，根据二级（三级？）结果查询更多服务，然后最后合并......这在哪里疯狂停止？这对响应时间有何影响？

而且我现在已经有效地创建了另一个“客户端”，它将所有微服务响应组合成一个巨型响应......这与上面的方法 1没有什么不同......除了服务器级别。

这就是“现实世界”中的做法吗？有什么见解吗？是否有任何基于我可以检查的 API 网关架构的开源项目？

标签： restmicroservicesapi-designapi-gateway

Answer 1

我们用于此类问题的解决方案是数据和事件的非规范化以进行更新。

基本上，微服务预先拥有它需要从其他微服务获取的数据子集，因此它不必在运行时调用它们。此数据通过事件进行管理。其他微服务在更新时会触发一个带有 id 作为上下文的事件，任何对其感兴趣的微服务都可以使用该事件。这样数据保持同步（当然它需要某种形式的事件故障机制）。这似乎需要做很多工作，但可以帮助我们做出有关整合来自不同微服务的数据的任何未来决策。我们的微服务将始终拥有本地可用的所有数据，以便它处理任何请求，而无需同步依赖其他服务

在您的情况下，即显示带有消息的名称，您可以在 Service(B) 中为名称保留一个额外的属性。因此，每当 Service(A) 中的名称更新时，它都会触发一个更新事件，其 id 为更新后的名称。然后服务（B）消费事件，从服务（A）获取相关数据并更新其数据库。这样，即使 Service(A) 关闭，Service(B) 也将起作用，尽管有一些陈旧的数据最终会在 Service(A) 出现时保持一致，并且您将始终在 UI 上显示一些名称。

https://enterprisecraftsmanship.com/2017/07/05/how-to-request-information-from-multiple-microservices/