使用RabbitMQ进行RPC样式的通信：模板convertSendAndReceive与推送/订阅样式

Question

我正在使用RabbitMQ实现RPC样式的通信，并具有创建异步管道体系结构的想法。我正在使用Java Spring和AMQP。

我将执行一系列RPC风格的通信-与一台服务器的通信将触发另一台服务器，而另一台服务器将触发另一台服务器，直到最终到达该链的末尾，并且服务器开始接收该最终答案的链。我发现了两种似乎很适合我的技术：

1. asyncRabbitTemplate的{​​{1}}：使用此方法进行推送，一旦消费者收到，便触发另一个convertSendAndReceive(...)，依此类推...一条链，直到最终结果结束在启动整个过程的服务器上。

2. 使用推送/订阅模式，其中一个生产者将使用convertSendAndReceive(...)进行推送，消费者将通过convertAndSend(...)进行监听，然后推送到另一个正在监听的对象，依此类推；在此设置中，具有初始@RabbitListen调用的服务器将收到最终响应。

我不确定这些方法之间有什么区别？什么时候去另一个？是否有性能折衷？一个比另一个需要更多的编程工作吗？

Answer 1

我认为这里存在一个概念上的问题。我没有方便的序列图工具，但是在RPC中，

1. 我们有一个消费者 C 和提供者 P
2. C 向 P 发送一条消息，以调用 P
提供的服务
3. P 直接回复 C 并返回 C 的请求消息中要求的结果

除此以外的所有内容都不是RPC。我用来描述此问题的其他术语是“请求/响应”和“客户端/服务器”。这是几乎所有Web服务都使用的模式，因此在应用程序体系结构中无处不在。

您似乎在此处描述的做法称为event chaining。这个概念在概念上似乎很简单，但是实际上您是由一系列相互独立的动作组成的。它是现实世界的工作方式，并且现实世界的一个关键特征是它是不确定的。这意味着，如果执行相同的操作顺序，则不能保证结果输出 相同。

大多数计算机程序都依赖确定性行为，其中相同的输入总是导致完全相同的输出。

Answer 2

这应该是对@theMayer答案的评论。但是，我想用图像详细说明RPC。 @theMayer可以随意嵌入此图像，然后我将删除此答案。

RPC调用通常如下运行：

Answer 3

据我了解，您正在构建一系列应在开始时结束的事件。 RPC模式用于彼此了解的两方之间的直接调用。

因此，如果您可以定义每个工作站之后数据的转换方式（例如，metal_bar-> squeezed_metal_bar-> curved_metal_bar->勺子），那么您可以肯定地讨论主题，这将使独立扩展每个工作站甚至添加监视/对任何阶段都做出反应，而无需进行任何其他更改，但要小心扩展初始调用方-您可能需要针对this problem

的解决方案