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

===== 完 ======