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

赖勇浩（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 ，全文如下：

// // 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 explicit option 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 ，全文如下：
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 这个命名。
===== 未完待续 =====