以小见大——那些基于 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 这个命名。

===== 未完待续 =====