Restful微服务的双向通信，通知是否合理？

许多书籍和文章指出，微服务中的周期通常是不好的，因为它们引入了相互依赖性，这导致更大的依赖性、版本控制和部署问题需要解决

---

但是，假设存在服务A，调用服务B，也假设由于此调用将启动冗长的计算，因此我们不应使此调用同步。一种可能的解决方案是服务A将资源url传递给服务B，这样当B计算结果时，它应该按照restful范式将结果发布到给定的url。最后一个资源类似于某种回调。这种方法确实可以解决我的问题，但是正如上面一段所解释的，它引入了循环依赖。这样行吗？如果不是的话，你将如何解决同样的问题？

这没问题，但不是一个好的设计，因为你可以看到依赖关系是相当硬编码的

您可以选择使用消息传递，将请求消息放在一个队列中，将响应消息放在另一个队列中

通过这种方式，您的通信将是异步的、松散耦合的，并且任何服务都不需要非常明确地了解彼此及其位置/地址。

---

这也是《反应宣言》推荐的沟通方式。

在这种情况下，使用两个队列听起来有点过头了。在问题中，注意只有A知道B的地址。所以这不是一个大问题。另外，在解决方案中，队列必须知道这些地址，除非服务本身进行轮询（这是我想要避免的）。不需要这样做…队列的发送方和接收方只需要知道队列的名称。在队列的侦听端，消息接收方不需要轮询，它最初是基于事件的，尽管您可以使用轮询机制，但这不是目的。因此，没有人知道或不需要知道发送方或接收方的任何地址；但只有队列名称和消息传递服务器的位置，例如JMS实现服务器。