Architecture 微服务间同步REST通信的替代方案

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

我有两项服务：

• 管理用户位置的

  位置服务

• 评分服务

  管理用户评分

现在，我必须构建另一个服务：

usersfeedservice

（UFS）。它必须返回靠近给定位置的用户，按分数排序（降序）

同步解决方案

给定一个位置，UFS从位置服务（REST）获取附近的用户

对于他们中的每一个人，它都会从计分服务中获得分数（其余）

最后，它对内存中的用户进行排序并返回它们

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

事件队列解决方案

• UFS将用户的位置和分数存储在数据库或内存缓存中
• 当score服务和location服务在队列中发布时，它侦听队列中的更改以更新其数据

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

---

这是一个好的解决方案吗？我怎样才能改进它？它会在大量用户中扩展吗？

也许您还有一些未列出的额外需求，但在我看来，在这种情况下，基于事件的解决方案将从其他服务复制大量数据，这远远超过了工程

如果UFS在位置服务发生更改时获取位置，那么将其调用绑定到位置更改时来自位置服务的事件是有意义的

---

关于scores服务，我会让它保持同步，但让它的接口接受一个客户列表，而不是对它进行n个“getcustomerscore”调用

它将比同步解决方案扩展得更好。队列比API更好，处理量也更大。但是，您必须抵消排队传输基础结构的复杂性。你确定你没有过早地优化吗？也许我是。不过，我担心将来会发生变化。从同步系统迁移到基于队列的系统可能很困难。无论如何，我认为你是对的。也许我正试图解决不存在的可伸缩性问题。谢谢你的回答。如何处理大量用户？我应该根据得分服务将其分成几个呼叫吗？取决于大的呼叫数？您可以更改score服务API，以便它接受客户机列表并返回得分最高的X个客户机-（m中的前n个），然后您必须来回传输更少的数据