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

赖勇浩（http://laiyonghao.com）

快刀斩乱麻，祭上最后两个 rpc 分析，再整上我自己的设计，这个系列就完结了。

protobuf-socket-rpc

好，废话不多说，看看这个 protobuf-socket-rpc，简介是 Java and Python protobuf rpc implementation using tcp/ip sockets，听说支持 java 的服务器和 python 的客户端，有点怪怪地哈？基本格式见：http://code.google.com/p/protobuf-socket-rpc/source/browse/trunk/proto/rpc.proto ，引用全文如下：
package protobuf.socketrpc; option java_package = "com.googlecode.protobuf.socketrpc"; option java_outer_classname = "SocketRpcProtos"; message Request { // RPC service full name required string service_name = 1; // RPC method name required string method_name = 2; // RPC request proto required bytes request_proto = 3; } message Response { // RPC response proto optional bytes response_proto = 1; // Error, if any optional string error = 2; // Was callback invoked optional bool callback = 3 [default = false]; // Error Reason optional ErrorReason error_reason = 4; } // Possible error reasons // The server-side errors are returned in the response from the server. // The client-side errors are returned by the client-side code when it doesn't // have a response from the server. enum ErrorReason { // Server-side errors BAD_REQUEST_DATA = 0; // Server received bad request data BAD_REQUEST_PROTO = 1; // Server received bad request proto SERVICE_NOT_FOUND = 2; // Service not found on server METHOD_NOT_FOUND = 3; // Method not found on server RPC_ERROR = 4; // Rpc threw exception on server RPC_FAILED = 5; // Rpc failed on server // Client-side errors (these are returned by the client-side code) INVALID_REQUEST_PROTO = 6; // Rpc was called with invalid request proto BAD_RESPONSE_PROTO = 7; // Server returned a bad response proto UNKNOWN_HOST = 8; // Could not find supplied host IO_ERROR = 9; // I/O error while communicating with server }
很眼熟啊，是的，跟之前看过的 fepss-rpc 几乎一样，除了这里定义了更多的错误类型，连注释都几乎一模一样啊，不知道谁抄谁的。所以没啥好说的了，唯一可以唠叨一下的是它跟 fepss-rpc 都采用无 ID 的设计，所以不能 parallel pipelining，细节见（http://blog.csdn.net/lanphaday/archive/2011/04/11/6316099.aspx ）。

txprotobuf

以 Python 始，再以 Python 终，最后一个是 protocol buffers (http://code.google.com/p/protobuf/) RPC implemented using python twisted framework.，基于 twisted 的 rpc，虽然我不喜欢 twisted，但不影响我看 txprotobuf 哈。它的基本格式见：http://bazaar.launchpad.net/~proppy/txprotobuf/master/view/head:/protobuf/txprotobuf.proto ，照例全文引过来：
// Copyright (c) 2008 Johan Euphrosine // See LICENSE for details. message Call { required uint32 token = 1; required string method = 2; required bytes request = 3; } message Result { required uint32 token = 1; required bytes response = 2; } message Box { optional bytes call = 1; optional bytes result = 2; }
简洁，跟 casocklib 相似的设计。唯一能够说一下的就是只有 method 字段而没有 service 字段所以没有办法做到 multi-service。另外，Box 这个命名我很喜欢。

我自己的设计

本来想单独作为一篇的，后来发现前两个实在没啥好说啊，干脆就整合在一起得了。好，上代码：
enum PackageType { HEARTBEAT = 0; ERROR = 1; REQUEST = 2; RESPONSE = 3; }; message Heartbeat { }; message Error { required string info = 1; }; message Request { required string service = 1; required string method = 2; optional bytes request = 3; }; message Response { optional bytes response = 1; }; message Package { required PackageType type = 1; required uint32 identify = 2; required bytes serialized = 3; }; message Placeholder { };
首先是学习 server1 定义了几种数据包的类型，不过我扩展了一下，加了心跳和错误这两种包。心跳在这里就是简单的一个空包，只是激活一下 TCP 连接，以免超时断开。如果要复杂一点的，可以参考陈硕《分布式系统的工程化开发方法》 p.51 心跳协议的设计（http://blog.csdn.net/Solstice/archive/2010/10/19/5950190.aspx ）。
message Error 很简单，只有一个 info 字段。之前也在想要不要加个数字枚举来让调用端了解一下基本出了啥错，后来我想还是不要了。主要是出错了对于调用端来说没有什么挽救手段啊，只能是往日志里写一句，然后该干啥干啥去，既然如此，又何必多此一举呢，直接把错误的文本从服务器端传过来就好了。
message Request 带了 service 和 method 字段，为的是明晰地表达咱支持 multi-service。而的 request 字段是 optional 的，为的是支持“空”参数调用 RPC。Message Response 的 optional bytes response 也是类似，为了支持“空”返回值。因为 protobuf 的 rpc 声明不支持 rpc XXX()returns() 这样的无参数无返回值的声明，所以我又在后面声明了一个 message Placeholder，这样 rpc 声明就可以写成 rpc XXX(Placeholder)returns(Placeholder)。调用代码时，可以直接写成 proxy.service.XXX() 这样子，由我们自己的 Proxy/Channel 实现去处理好这个占位参数和返回值就行了。
最后，整个连接上传输的数据包就只有一种：message Package，不论是 Heartbeat、Error、Rquest 或 Response，最后都会序列化到 Package.serialized 里去。
对比这么多实现，我的这个版本既没有像 protobuf-remote 般自由开放的调用参数机制，也没有 protobuf-rpc-pro 可以返回超大块数据的内置方案。不过我还是比较满意，太自由和太重量的方案不符合我的技术观。
我打算基于 gevent 实现这个 rpc。
===== 完 ======