以小见大——那些基于 protobuf 的五花八门的 RPC（4）

深碍√TFBOYSˉ_ 2022-02-15 02:00 191阅读 0赞

赖勇浩（[http://laiyonghao.com][http_laiyonghao.com]）

## protobuf-rpc-pro ##

不知道你还记不记得 protobuf-rpc，这货在后面加了个 pro，就真的重量级了许多。照例先看看简介：A java ProtocolBuffers RPC implementation featuring bidirectional calls，特点是双向调用，跟之前的看的 rpc 都不一样。姑且按下不表，单来看看基本格式文件，[http://code.google.com/p/protobuf-rpc-pro/source/browse/trunk/protobuf-streamer-pro/src/main/protos/protobuf-stream.proto][http_code.google.com_p_protobuf-rpc-pro_source_browse_trunk_protobuf-streamer-pro_src_main_protos_protobuf-stream.proto] ，全文如下：

TcpClient->TcpServer : PullRequest// TcpClient->TcpServer : PushRequest// TcpServer->TcpClient : Chunk// TcpClient->TcpServer : CloseNotification ( for closing pulls before transfer end. )// TcpServer->TcpClient : CloseNotification ( for closing pushes before transfer end. )//option java\_package = "com.googlecode.protobuf.pro.stream.wire";option java\_outer\_classname = "StreamProtocol";// This is default, but it's nice to be explicitoption optimize\_for = SPEED;message PullRequest \{    required int32 correlationId = 1;    required bytes requestProto = 2;\}message PushRequest \{    required int32 correlationId = 1;    required bytes requestProto = 2;\}message CloseNotification \{    required int32 correlationId = 1;\}message Parameter \{        required string name = 1;        required string value= 2;\}message Chunk \{    required int32 correlationId = 1; // unique for each push/pull per channel    required ChunkTypeCode chunkType = 2;    required int32 seqNo = 3; // incremented for each sent chunk    repeated Parameter parameter = 4;    optional bytes payload = 5;\}enum ChunkTypeCode \{  START = 0;  MIDDLE = 1;  END = 2;\}message WirePayload \{        optional Chunk chunk = 1;        optional PullRequest pull = 2;        optional PushRequest push = 3;        optional CloseNotification close = 4;\}

哇，好长好长，一定是场硬仗。Protobuf-rpc-pro 的特点就是双向调用，所以有 pull 和 push 两种 request message，让人纠结的是，其实他们是一样的，简单地采用 32 位 ID 加序列化后的 message 方案。响应包叫做 Chunk，独特的地方是一个响应包，可以分在若干个 Chunk 中发送到另一端，这样的话如果返回的结果很大，也算是有内置的解决方案了。带了一个 pro 的东西，就是比较重量级啊。这个特性是通过 chunkType 和 seqNo 两个字段共同来完成的，chunkType 用以标识起始点，而 seqNo 用来组织顺序。repeated Parameter parameter 的作用是传递一些扩展的参数，这些参数可能在处理 payload 的时候用得着，而这个 payload 是序列化的 message，它才是调用返回的结果（或结果的一部分）。  
最后来看一下 WirePayload，现在来看，这货就简单了，跟 protobuf-rpc 中的 message Rpc 或 protobuf-remote 中的 message RpcMessage 是一样的封装类，见得多了也就没什么好说。  
看来带 pro 的设计的确是考虑得比较周全，刚才还有一个 message CloseNotification 一直压着没谈，现在来说一下：它用来告知另一端自己马上就要关闭服务了。关于这一点，我觉得利用 TCP 本身的是半关闭特性就够了，没有必要做这个。

## server1 ##

server1 出自国人之手，是一个利用了 Boost 的 a c++ network server/client framework，它的作者 xiliu tang 是我的前同事。server1 的代码还是非常简明的，先来看一下基础格式：[http://code.google.com/p/server1/source/browse/trunk/server/meta.proto][http_code.google.com_p_server1_source_browse_trunk_server_meta.proto] ，全文如下：  
package ProtobufLineFormat;message MetaData \{  enum Type \{    REQUEST = 1;    RESPONSE = 2;  \};  required Type type = 1;  required uint64 identify = 2;  // the request should bring the response identify.  optional uint64 response\_identify = 3;  required bytes content = 4;\};  
很简单，只有一个 message MetaData？对的。感觉上跟 protobuf-rpc 差不多，两个不同：一是 MetaData 带了一个 Type，用来标明它是请求还是响应；还有一个是 MetaData 使用了无符号 64 位整型作为 ID。使用 type 字段我个人感觉比 repeated/optional 的方式比起来有点没有充分利用到 protobuf 特性的感觉，不过相当地清晰明了。还有就是 response\_identify 我专门在 GTalk 上问过作者，他说记不起为什么要加这个字段了……囧。我的看法是这个字段是不必要的。嗯，这个设计真的很简洁，不过，我不喜欢 Meta 这个命名。  
===== 未完待续 =====

[http_laiyonghao.com]: http://laiyonghao.com
[http_code.google.com_p_protobuf-rpc-pro_source_browse_trunk_protobuf-streamer-pro_src_main_protos_protobuf-stream.proto]: http://code.google.com/p/protobuf-rpc-pro/source/browse/trunk/protobuf-streamer-pro/src/main/protos/protobuf-stream.proto
[http_code.google.com_p_server1_source_browse_trunk_server_meta.proto]: http://code.google.com/p/server1/source/browse/trunk/server/meta.proto