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

Question

假设有两个(或多个)RESTful微服务为JSON提供服务。服务(A)存储用户信息(名称，登录名，密码等)，服务(B)存储去往该用户的消息/来自该用户的消息(例如sender_id，主题，正文，rcpt_ids)。
/profile/{user_id}上的服务(A)可能会响应:
{id: 1, name:'Bob'}{id: 2, name:'Alice'}{id: 3, name:'Sue'}
等等

响应/user/{user_id}/messages的服务(B)返回发往该{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 :拉出消息列表，然后开始拉出sender_id和rcpt_ids中列出的每个ID的配置文件信息？这可能需要100的请求，可能要花一些时间。相当幼稚和低效，可能无法与复杂的应用程序一起扩展？？？

方法2 :提取消息列表，提取所有用户ID并分别对所有相关用户发出批量请求...这假定存在这样的服务终结点。在获取消息列表，提取用户ID，发送对批量用户信息的请求以及等待批量用户信息响应之间仍然存在延迟。

理想情况下，我想一次性提供完整的响应集(消息和用户信息)。我的研究将我带到了服务层的响应合并……也称为方法3 :API网关技术。

但是，如何实现这一目标呢？

我可以获取消息列表，提取用户ID，在后台进行调用并获取用户数据，合并结果集，然后将最终结果提供...在后台进行2种服务都可以。消息列表取决于更多服务...如果我需要在后台查询多个服务，进一步解析这些响应，基于次要(三次)结果查询更多服务，然后最终合并...该怎么办？疯狂停止？这如何影响响​​应时间？

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

在“现实世界”中是这样吗？有什么见解吗？我可以检查基于此类API网关体系结构构建的任何开源项目吗？

Answer 1

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

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

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

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