以小见大——那些基于 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 ,全文如下:

哇,好长好长,一定是场硬仗。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 ,全文如下:

很简单,只有一个 message MetaData?对的。感觉上跟 protobuf-rpc 差不多,两个不同:一是 MetaData 带了一个 Type,用来标明它是请求还是响应;还有一个是 MetaData 使用了无符号 64 位整型作为 ID。使用 type 字段我个人感觉比 repeated/optional 的方式比起来有点没有充分利用到 protobuf 特性的感觉,不过相当地清晰明了。还有就是 response_identify 我专门在 GTalk 上问过作者,他说记不起为什么要加这个字段了……囧。我的看法是这个字段是不必要的。嗯,这个设计真的很简洁,不过,我不喜欢 Meta 这个命名。
===== 未完待续 =====

posted on 2011-04-13 19:47  张大大123  阅读(164)  评论(0编辑  收藏  举报

导航