我使用的是带有Rest端点的事件驱动微服务架构。
我正在寻求关于微服务往返电话的建议。
例如，在我的应用程序中，我有"服务"；A"；以及"；B"；。
服务B调用A的post方法；A"；再次调用"上的get方法；B"；以获取一些数据来准备最终结果。我正在使用这种方法来打破循环依赖关系。
到目前为止，我读过的几乎所有文章都在谈论"减少"往返旅行，而不一定要"消除"往返旅行。
微服务最佳实践如何看待这种往返？
首先，事件驱动的微服务通过从事件代理生成和消费事件，精确地避免了这种同步的直接通信。
不管怎样，使用事件异步通信还是直接通信都无关紧要，服务之间的通信越少，性能越好。因此，在你的情况下，你能做的最好的事情就是传递服务B从服务A需要的所有信息，这样服务B就不需要打另一个电话了。
使用事件驱动的方法，服务A将生成一个包含服务B所需的所有信息的事件，并将其发送到服务B将要侦听的主题。
根据您的体系结构质量目标，有三种可能的往返解决方案：
- 执行调用并增加客户端请求的延迟
- 预先复制数据以更快地响应客户端。例如，您可以使用异步pub-sub机制
- 将两个服务合并为一个更大的服务
最佳实践(尚未验证，但灵感来自SCS(：尝试在服务之间进行0跳，以使用复制数据来回答客户端请求。