Quic-Rpc

基于Quic的流式RPC系统

目标

交互模式

不仅提供请求/响应RPC，还提供双向流式传输，类似于grpc。

• 1个请求 -> 1个响应
• 1个请求，更新流 -> 1个响应
• 1个请求 -> 响应流
• 1个请求，更新流 -> 响应流

它仍然是一个RPC系统，因为在交互中客户端发起。

传输

• 具有非常低开销的内存传输。特别是没有序列化/反序列化，目前使用flume
• 通过quinn crate的Quic传输
• 透明组合上述内容

API

• API应类似于quinn api。基本上是“带类型的quinn”。

非目标

• 跨语言互操作。这是从Rust到Rust进行通信
• 任何类型的版本控制。你必须自己完成
• 让远程消息传递看起来像本地异步函数调用
• 运行时无关。这是为tokio

示例

计算服务

为什么？

quic-rpc的目的是作为可选 RPC框架。其中一个主要目标是能够将其用作进程内方式，以便在子系统之间（包括异步边界）拥有良好的指定协议和边界。

与在复杂单进程应用程序中隔离子系统相比，它不应产生明显的开销，但应具有通过其中一个非内存传输发送消息跨越进程边界的选项。

你在Rust中通常如何实现子系统之间的隔离，例如数据库和网络层之间的隔离？你在这两个系统之间有一些类型的通道，并定义通过该通道来回流动的消息。对于几乎所有交互，这些消息本身将再次包含（oneshot或mpsc）通道，用于子系统之间的独立异步通信。

Quic-rpc使用内存通道做的是完全一样的事情，只不过它隐藏了细节，并允许你在Rust类型系统中指定干净的、高级的交互协议。

而不是使用明确包含某些数据的信息和用于响应的单次或mpsc通道的发送端，它内部创建了一对flume通道，并将其中一端发送到服务器。这对于RPC交互来说有一些轻微的开销（2个flume通道比1个单次通道），但对于流式交互来说，这种开销可以忽略不计。

对于存在进程边界的情况，对于已经具有廉价子流概念（http2、quic等）的传输方式，开销非常低。Quic是具有内置廉价子流（包括每个子流的回压）的网络传输的典范。然而，我发现对于原始数据传输，http2/tcp仍然具有更好的性能。这就是为什么存在http2传输的原因。

目前，您会使用quinn传输，如果您想要与许多不同的对等连接，并且无法接受较大的每连接开销，或者您希望对于小消息有低延迟。

您会使用hyper传输，如果您有少量连接，因此每连接的开销不是很重要，并且您希望以牺牲一些延迟为代价获得最大吞吐量。

随着quic实现得到更多优化，这在未来可能会发生变化。