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

Question

这里不方便实现RPC：https://github.com/gaevoy/Gaev.Rpc/tree/master/Gaev.Rpc.Rebus。 这种实现有许多缺点。例如，当客户数百时，他们将收到不到1％的有用响应，服务器将发送数百倍于所需数据。

将Rebus与传输RabbitMQ一起使用时，远程过程调用的典型实现是什么？类似于the tutorial on RabbitMQ中提供的RPC实现。

理想情况下，我想让实现返回处理请求时服务器上可能出现的强类型任务结果或异常，类似于WCF中的方式。

Answer 1

请勿使用Rebus实施RPC（*）。

事实上，我不建议您使用任何类型的基于消息的持久技术来实现假装同步的东西 - 恕我直言，使用像RabbitMQ这样的持久集中式代理来实现可靠的HTTP＆是非常愚蠢的＃34; （但这个讨论太大了，不能包含在这里......）

我特别建议你不要以任何方式使用Rebus来实现RPC的原因是因为Rebus充满了异步性和持久性的想法，在需要达到its delivery guarantee的地方牺牲原始性能

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

总结：Rebus旨在用于异步消息传递，然后建议使用轻量级请求/响应类型的通信通道（如HTTP）来实现远程方法调用＆＃34;。

我希望这是有道理的：）

（*）通过＆＃34; RPC＆＃34;，我假设你的意思是编程API，假装是类似函数调用，即与调用站点同步（可能仍然是基于Task）