如何合并/合并来自多个RESTful微服务的响应? [英] How to merge/consolidate responses from multiple RESTful microservices?
问题描述
假设有两个(或多个)RESTful微服务提供JSON.服务(A)存储用户信息(名称，登录名，密码等)，服务(B)存储发往该用户的消息/来自该用户的消息(例如sender_id，主题，正文，rcpt_ids).
Let's say there are two (or more) RESTful microservices serving JSON. Service (A) stores user information (name, login, password, etc) and service (B) stores messages to/from that user (e.g. sender_id, subject, body, rcpt_ids).
/profile/{user_id}上的服务(A)可能会响应:
Service (A) on /profile/{user_id} may respond with:
{id: 1, name:'Bob'}
{id: 2, name:'Alice'}
{id: 3, name:'Sue'}
以此类推
服务(B)返回发往该{user_id}的消息列表，如下所示:
Service (B) responding at /user/{user_id}/messages returns a list of messages destined for that {user_id} like so:
{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?
How does the client application consuming these services handle putting the message listing together such that names are shown instead of sender/rcpt ids?
方法1 :提取消息列表，然后开始提取sender_id和rcpt_ids中列出的每个ID的配置文件信息?这可能需要100的请求，可能要花一些时间.相当幼稚和低效，可能无法与复杂的应用程序一起扩展??
Method 1: Pull the list of messages, then start pulling profile info for each id listed in sender_id and rcpt_ids? That may require 100's of requests and could take a while. Rather naive and inefficient and may not scale with complex apps???
方法2 :拉出消息列表，提取所有用户ID，并分别对所有相关用户发出批量请求...这假定存在这样的服务端点.在获取消息列表，提取用户ID，发送对批量用户信息的请求以及等待批量用户信息响应之间仍然存在延迟.
Method 2: Pull the list of messages, extract all user ids and make bulk request for all relevant users separately... this assumes such service endpoint exists. There is still delay between getting message listing, extracting user ids, sending request for bulk user info, and then awaiting for bulk user info response.
理想情况下，我想一次性提供完整的响应集(消息和用户信息).我的研究将我带到了服务层的响应合并……又称为方法3 :API网关技术.
Ideally I want to serve out a complete response set in one go (messages and user info). My research brings me to merging of responses at service layer... a.k.a. Method 3: API Gateway technique.
但是如何实现呢?
我可以获取消息列表，提取用户ID，在后台进行呼叫并获取用户数据，合并结果集，然后将此最终结果提供...在后台进行2种服务都可以正常工作...但是，如果消息列表取决于更多服务，该怎么办...如果我需要在后台查询多个服务，进一步解析这些响应，基于次要(三次)结果查询更多服务，然后最终合并...这种疯狂在哪里停止?这如何影响响应时间?
I can obtain list of messages, extract user ids, make a call behind the scenes and obtain users data, merge result sets, then serve this final result up... This works ok with 2 services behind the scenes... But what if the message listing depends on more services... What if I needed to query multiple services behind the scenes, further parse responses of these, query more services based on secondary (tertiary?) results, and then finally merge... where does this madness stop? How does this affect response times?
我现在已经有效地创建了另一个客户端"，它将所有微服务响应组合为一个大型响应...与上面的方法1 ......在服务器级别上没有什么不同.
And I've now effectively created another "client" that combines all microservice responses into one mega-response... which is no different that Method 1 above... except at server level.
在现实世界"中是这样吗?有什么见解吗?我可以检查基于此类API网关体系结构构建的任何开源项目吗?
Is that how it's done in the "real world"? Any insights? Are there any open source projects that are built on such API Gateway architecture I could examine?
推荐答案
我们用于此类问题的解决方案是对数据和事件进行非规范化以进行更新.
The solution which we used for such problem was denormalization of data and events for updating.
基本上，微服务预先拥有其他微服务所需的数据子集，因此不必在运行时调用它们.该数据通过事件进行管理.其他微服务在更新时会触发一个ID为上下文的事件，任何对此感兴趣的微服务都可以使用它.这样，数据保持同步(当然，它需要某种形式的事件失败机制).这似乎有很多工作要做，但可以帮助我们做出有关合并来自不同微服务的数据的任何未来决策.我们的微服务将始终在本地提供所有可用数据，以便在不同步依赖其他服务的情况下处理任何请求
Basically, a microservice has a subset of data it requires from other microservices beforehand so that it doesn't have to call them at run time. This data is managed through events. Other microservices when updated, fire an event with id as a context which can be consumed by any microservice which have any interest in it. This way the data remain in sync (of course it requires some form of failure mechanism for events). This seems lots of work but helps us with any future decisions regarding consolidation of data from different microservices. Our microservice will always have all data available locally for it process any request without synchronous dependency on other services
在您的情况下，即为了显示带有消息的名称，您可以在Service(B)中保留名称的额外属性.因此，每当Service(A)中的名称更新时，它将触发一个ID为该更新名称的更新事件.然后，服务(B)获取该事件，从服务(A)获取相关数据并更新其数据库.这样，即使Service(A)关闭，Service(B)仍将起作用，尽管它具有一些过时的数据，这些数据最终将在Service(A)出现时保持一致，并且您将始终在UI上显示一些名称.
In your case i.e. for showing names with a message, you can keep an extra property for names in Service(B). So whenever a name update in Service(A) it will fire an update event with id for the updated name. The Service(B) then gets consumes the event, fetches relevant data from Service(A) and updates its database. This way even if Service(A) is down Service(B) will function, albeit with some stale data which will eventually be consistent when Service(A) comes up and you will always have some name to be shown on UI.
这篇关于如何合并/合并来自多个RESTful微服务的响应?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
