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

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

多看了三五个 rpc 实现之后，这个事儿就变得很有趣了，今儿来看 fepss-rpc 和 casocklib，分别基于 java 和 C++ 开发。

fepss-rpc

它的简介是Protocol Buffers RPC Server Implemention based on Mina(2.0.0-RC1) and Protobuf(2.1.0)，基本的包格式见：https://github.com/jcai/fepss-rpc/blob/master/src/main/resources/com/fepss/rpc/client/rpc.proto
，全文如下：

package com.fepss.rpc.client;
option java_package = "com.fepss.rpc.client";
option java_outer_classname = "RpcProtobuf";
option optimize_for = SPEED;
// Possible error reasons
enum ErrorReason {
BAD_REQUEST_DATA = 0;
BAD_REQUEST_PROTO = 1;
SERVICE_NOT_FOUND = 2;
METHOD_NOT_FOUND = 3;
RPC_ERROR = 4;
RPC_FAILED = 5;
CLIENT_FAILED=6;
}
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;

// Eror, if any
optional string error = 2;

// Was callback invoked
optional bool callback = 3 [default = false];

// Error Reason
optional ErrorReason error_reason = 4;
}

可以看到 ErrorReason 定义了几个常见的错误：比如没有 Service，或有 Service 却没有相应的 method 等等，不过我对 BAD_REQUEST_DATA、BAD_REQUEST_PROTO、CLIENT_FAILED 表示不淡定，原因是对于前两者，我推崇发现非法协议就断开连接甚至采取更严厉的手段，而后者，客户端都出问题了，那 response 还能发送过去吗？

这个 Request 的设计比 protobuf-rpc 要好得多，因为它把 service_name 和 method_name 作为两个字段，非常明晰。但是它采用了无 id 设计，所以没有办法实现 Parallel Pipelining，肯定并发性能很差。关于 pp，我借用 msgpack-rpc 的一张图来说明一下：



而 Response 类的设计，我比较不明白 callback 的意图，还请读者中的行家赐教一二，多谢先。这里采用了 ErrorReason 和 error 分为两个字段的设计，我个人觉得有会让人有点小困惑，还不如 protobuf-rpc 的 Error 设计，通过 optional 实现 union。

casocklib

看完一个 python 的 rpc，一个 java 的 rpc，终于来了一个 C++ 的，先看它的简介：An asynchronous communication library for C++，而它基本包格式见：http://code.google.com/p/casocklib/source/browse/trunk/src/casock/rpc/protobuf/api/rpc.proto
，如下：

package casock.rpc.protobuf.api;
enum ResponseType {
RESPONSE_TYPE_OK = 1;
RESPONSE_TYPE_ERROR = 2;
};
message RpcRequest {
required uint32 id = 1;
required string operation = 2;
optional bytes request = 3;
}
message RpcResponse {
required uint32 id = 1;
required ResponseType type = 2;
optional bytes response = 3;
}

代码很短，采用了相当轻量级的设计。首先旗帜鲜明地声明了响应包的种类：成功以及失败，对于失败，并没有细分。RpcRequest.id 使用 32 位无符号整型，跟 protobuf-rpc 一样，不过这里的 operation 却跟后者的 method 不一样，operation 是货真价实的 MethodDescriptor.name，从代码（http://code.google.com/p/casocklib/source/browse/trunk/src/casock/rpc/protobuf/client/RPCRequestBuilder.cc#50
）可以证实。因为每一个 RpcRequest.operation 都不带 service name，所以使用 Casocklib 是无法将多个 service host 到同一个端口的。

RpcResponse 因为带了一个 ResponseType，所以可以知道 method 到底有没有执行成功，同理 response 就设计成 optional 了，因为执行错误就不需要返回 response 了呀。

===========

未完待续，明天讲一个重量级一点的，设计独特的，基于 c++ 的 rpc 实现。