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

Google protobuf(http://code.google.com/p/protobuf)提供了 service 关键字来描述 RPC，但没有实现，所以大家都纷纷自制 RPC，仅仅是在 protobuf 官网列出来的，就有十几个（http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns#RPC_Implementations）。它们使用不同的语言、框架的大不同就不用多说了，没想到的是我看了几个之后，发现即使是每个调用的请求和响应包格式都大有不同哦，体现了蛮多不同理念。有兴趣的不妨先跟我一起浏览一下其中比较有特点的七八个实现，然后我们再画个表来总结总结。

protobuf-rpc

它的自我简介是 RPC based on Google's protocol buffers。基本的包格式见：http://code.google.com/p/protobuf-rpc/source/browse/trunk/protocol/protobufrpc.proto，全文如下：
message Rpc { repeated Request request = 1; repeated Response response = 2; } message Request { required string method = 1; // name of a method_descriptor optional bytes serialized_request = 2; // pb2-encoded message optional uint32 id = 3; } message Error { required sint32 code = 1; optional string text = 2; } message Response { optional bytes serialized_response = 1; // pb2-encoded message optional Error error = 2; required uint32 id = 3; }
不知道大家有没有注意到 message Rpc 里的两个字段都是 repeated 的！我设想，这个设计的有以下特点：同一个数据包里可以有多个 request 或 response，甚至是返回 response 的同时丢若干 request 回去给另一端，相当地灵活。
再来看 Request.method，注释是 name of a method_descriptor，实际上是 service_descriptor 的 name 加上 method_descriptor 的 name 来的，不过如果你不看代码无法知道这一点（代码见：http://code.google.com/p/protobuf-rpc/source/browse/trunk/python/protobufrpc/synchronous.py#60）；这样做的好处是你可以在同一个端口 host 若干个 service。但是这跟不上变化的注释和隐晦的字段名，真的让人很纠结，破代码的典范。
id 字段居然是 optional 的，让我有点迷惑，特别是看到 Response.id 居然是 required，额……天哪，Request 不是自带 id 的话拿什么东西来设置 Response 哦！事实上，从代码来看，Request.id 都是有设置的，读的时候也是当这个字段是 required 来处理。
Error 的设计中规中矩，不过 code 就没有先用 enum 包装一下，预设几种常见错误，有点过于自由化了。
最后，因为看到 Request.serialized_request 和 Response.serialized_response 都是 optional，我惊了一下，以为 protobuf 的 RPC 可以没参数和返回值的，但又想起从来没见文档提到过。最后还是小马过河，自己写了一个没有参数的 RPC 去编译，protoc 老实不客气地丢出来一句“Expected type name.”，确认了 RPC 都需要参数和返回值。所以这个Request.serialized_request 的 optional 应该改用 required；而 Response.serialized_response 则可以是 optional，因为当 RPC 执行错误的时候，无法返回 Response 实例，只能返回 Error 实例，所以需要 optional 来满足这个灵活性。作者这货真不严谨。
未完待续……