[闻数起舞]gRPC和RSocket之间的区别( 二 )
负载均衡gRPC仅限于HTTP/2负载平衡 。 一元gRPC调用的负载平衡与流调用的负载平衡不能相同 。 这意味着短暂的请求/回复调用将与长时间运行的流相同地进行负载平衡 。
RSocket负载平衡可以发生在传输级别和应用程序级别 。 这是因为在消息中封装了有关正在发生的事情的完整信息 。 您可以创建一个负载平衡器 ， 以不同于请求/流的方式对待请求/响应 。
空间耦合gRPC已耦合到要将请求发送到的URL和服务 。 另一端必须有一个收件人才能接听电话 ， 因为该消息是直接发送给他们的 。 如果接收者不存在 ， 通话将失败 。 如果您在客户端和服务器之间放置一个代理 ， 这仍然是正确的 。 然后 ， 该代理必须存在 。 如果不存在 ， 则请求将失败 。 如果没有任何要调用的代理 ， 那么它的请求也会失败 。
【[闻数起舞]gRPC和RSocket之间的区别】RSocket是基于消息传递的 ， 因此对它的帧发送位置没有意见 。 发送消息时 ， 接收方不必在另一侧 ， 因为消息是通过流发送的-流中的帧仅需要处理 。 另外 ， 由于流中的帧是根据RSocket协议处理的 ， 因此无论在何处或由谁处理它们都无关紧要 。
这意味着使用RSocket可以对交互进行建模 ， 例如多播和广播 。
互动模型gRPC作为HTTP/2流通过网络发送信息 。 这意味着对于请求/答复和触发/忘记交互 ， 必须通过网络发送更多帧 。 同样 ， 使用gRPC ， 有关流的信息封装在应用程序代码中 。 这意味着只能通过查看应用程序代码来区分GET和POST之间的区别 。
RSocket具有协议内置的交互概念 。 这在概念上与HTTP方法类似（但不起作用） 。 交互模型是请求-答复（发送一个/接收一个） ， 解雇（发送一个） ， 请求流（发送一个/接收很多）和请求通道（发送/接收很多） 。 这些包含在协议的框架中 ， 并允许实现针对不同的交互模型进行优化 。 流通过单个连接发送 。
开发人员APIgRPCAPI仅限于gRPC生成的代码 ， 并且您必须使用RPC样式的交互 。
RSocket更灵活 。 如果您喜欢RPC样式的语义 ， 则可以使用RSocket-RPC 。 如果不喜欢 ， 可以使用SpringMessaging 。 而且 ， 如果您对底层应用程序编程感到满意 ， 则可以直接使用RSocket 。
时间耦合gRPC和RSocket都提供了非阻塞API 。
保持健康和健康检查gRPC同时保持活动和运行状况检查 。 健康检查是可以执行的特殊协议 。
RSocket只是保持活动状态 。 如果保持活动失败 ， 则连接将终止 。
恢复RSocket支持恢复连接 。 如果连接失败 ， RSocket可以自动重新连接 ， 给人以稳定连接的印象 。
RSocketJava特定差异零拷贝RSocketJava提供了一个API ， 使开发人员可以管理NettyByteBuf生命周期 ， 从而实现零拷贝 。
自动请求批处理RSocketJava利用响应流语义来通过网络批量处理请求 。 使用此信息 ， RSocket可以确定在网络缓冲区已满或是否需要基于有关流的信息进行刷新时刷新数据 。 结果是RSocket将根据其观察到的内容通过网络发送最佳数据量 ， 而无需用户进行调整 。
基于Flyweight的帧RSocketJava使用flyweight模式对帧进行编码和解码 。 这些flyweight不分配任何数据 。 取而代之的是 ， 它们充当ByteBuf上的镜头来读取 ， 而没有解码帧的开销 。
RSocket编程APIRSocket是OSI5/6层协议 ， 虽然可以根据用例直接使用 ， 但使用第7层协议开发应用程序要容易得多 。 当前有RPC ， IPC ， 不久便增加了GraphQL支持 。 现在最成熟的是RSocketRPC ， 它是一个Protobuf自动编组层 ， 位于RSocket之上 ， 以使消息传递更加方便 。 从本质上讲 ， 它不是RPC ， 而是一个消息传递层 ， 它生成样板方法并自动封送消息 。 它使用protobuf编译器执行此操作 。 与gRPC不同 ， 后者创建带有标题信息的HTTP/2消息 ， 而RSocketRPC生成二进制编码的帧 。 框架已标准化为RSocket扩展框架 。