如何合并/整合来自多个 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'}
等等
在 /user/{user_id}/messages 处响应的服务 (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.
但是如何实现这一点呢?
But how does one even implement this?
我可以获取消息列表，提取用户 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屋！
