这里是RPC的不方便实现：https://github.com/gaevoy/Gaev.Rpc/tree/master/Gaev.Rpc.Rebus.这种实施方式有许多缺点。例如，当客户端达到数百时，他们将收到不到1%的有用响应，而服务器发送的数据将是所需数据的数百倍。
当使用带有传输RabbitMQ的Rebus时，远程过程调用的典型实现是什么？类似于RabbitMQ教程中给出的RPC实现。
理想情况下，我希望实现返回强类型任务结果或异常，该结果或异常可能在处理请求时发生在服务器上，类似于WCF中的情况。
请永远不要使用Rebus来实现RPC(*)。
事实上，我不建议您使用任何一种基于持久消息传递的技术来实现假装同步的东西——IMHO使用像RabbitMQ这样的持久集中式代理来实现"可靠的HTTP"是非常愚蠢的(但这是一个太大的讨论，不能包含在这里…)
我特别建议您不要以任何方式使用Rebus来实现RPC，因为Rebus充满了异步性和持久性的思想，在需要达到其交付保证的地方牺牲了原始性能。
虽然实现基于Task的请求/响应类型的API当然是可能的(这可能是具有本地代理和封送方法调用的全面RPC协议的基本构建块)，但这在很大程度上违反了Rebus的API中固有的意图，因此这将给混合增加更多的开销。
总之：Rebus旨在用于异步消息传递，然后建议使用轻量级请求/响应类型的通信通道(如HTTP)来实现"远程方法调用"。
我希望这是有道理的：)
(*)所谓"RPC"，我假设你指的是一种编程API，它假装是函数类调用，即与调用站点同步(可能仍然是基于Task的)