将Rebus与传输RabbitMQ一起使用时，远程过程调用的典型实现是什么？

此处不方便实现RPC:。 这种实现有许多缺点。例如，当客户端发送数百次时，它们将收到不到1%的有用响应，而服务器将发送比所需数据多数百倍的数据

将Rebus与传输RabbitMQ一起使用时，远程过程调用的典型实现是什么？类似于中给出的RPC实现

---

理想情况下，我希望实现返回强类型任务结果或异常，该结果或异常在处理请求时可能在服务器上发生，类似于WCF中的情况。

请不要使用REBS实现RPC（*）

事实上，我不建议您使用任何一种基于持久消息传递的技术来实现假装是同步的东西——我认为使用像RabbitMQ这样持久的集中式代理来实现“可靠的HTTP”是非常愚蠢的（但这是一个太大的讨论，无法在这里包括……）

我特别建议您不要以任何方式使用Rebus来实现RPC的原因是，Rebus充满了异步性和持久性的思想，在需要达到这些要求的地方牺牲了原始性能

虽然很有可能实现基于任务的请求/响应类型的API（这可能是具有本地代理和封送方法调用的完整RPC协议的基本构建块），但这几乎违反了Rebus API中固有的意图，因此，它将为组合增加更多的开销

总之：Rebus用于异步消息传递，然后建议使用轻量级请求/响应类型的通信通道（如HTTP）来实现“远程方法调用”

我希望这是有道理的：）

---

---

（*）通过“RPC”，我假设您指的是一个假装类似于函数调用的编程API，即与调用站点同步（可能仍然是基于任务的）

谢谢您的回复！你是对的。最好运行一个自我复制任务，定期向所有等待的客户端发送新结果。