微服务之间的同步REST通信的替代

Question

我知道服务之间的同步通信是一种反模式，所以我正在为我的用例寻找一个好的解决方案。

我有这两个服务：

• Location Service管理用户位置
• Score Service管理用户评分

现在，我必须建立另一个服务：Users Feed Service（UFS）。它必须将用户返回给定位置，按照分数（降序）排序。

同步解决方案

1. 给定的位置，UFS获取从位置服务（REST）
2. 对于他们中的每一个附近的用户，它得到她的得分从分服务（REST）
3. 最后，它对内存中的用户进行排序并返回它们

什么是替代方案？我一直在思考这样的事情：

事件队列解决方案

• UFS在数据库中，或内存缓存或东西
• 它侦听到的变化在队列中来店用户的位置和分数当得分服务和位置服务发布时更新其数据

这样，当客户端请求用户的feed时，用户的feed服务不必执行任何网络请求（它拥有必要的数据）

这是一个很好的解决方案吗？我该如何改进它？它会扩展到大量的用户吗？

Answer 1

也许你有一些额外的要求，你没有列出，但在我看来，在这种情况下，基于事件的解决方案，将从其他服务复制大量数据是工程的方式。

如果当有位置服务 - 改变的话很有道理其调用绑到从位置服务未来的变化位置

至于得分服务的事件UFS得到的位置，我'd保持同步，但使其界面接受客户名单，而不是让客户成为“获得客户分数”的电话。