以小见大——那些基于 protobuf 的五花八门的 RPC(1)
来源:互联网 发布:lol个人数据carry查询 编辑:程序博客网 时间:2024/06/05 10:48
赖勇浩(http://laiyonghao.com )
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 来满足这个灵活性。作者这货真不严谨。
未完待续……
转自http://blog.csdn.net/lanphaday
- 以小见大——那些基于 protobuf 的五花八门的 RPC(1)
- 以小见大——那些基于 protobuf 的五花八门的 RPC(1)
- 以小见大——那些基于 protobuf 的五花八门的 RPC(2)
- 以小见大——那些基于 protobuf 的五花八门的 RPC(3)
- 以小见大——那些基于 protobuf 的五花八门的 RPC(4)
- 以小见大——那些基于 protobuf 的五花八门的 RPC(5 完)
- 基于protobuf的RPC实现
- 基于protobuf的RPC实现
- 基于protobuf的RPC实现
- 基于protobuf的RPC实现
- 基于protobuf的RPC实现
- 基于protobuf的RPC实现
- 基于protobuf的RPC实现
- Hadoop 基于protobuf 的RPC的服务器端实现原理
- Hadoop 基于protobuf 的RPC的客户端实现原理
- 基于HTTP/2和protobuf的RPC框架GRPC
- Protobuf的那些事
- 五花八门的Barcamp和五花八门的人
- 最新刷机包1200.A1200R\E版本通刷
- 结构型模式 Bridge和Adapter
- Windows下Android开发环境搭建
- 皮带输送机控制
- java任务调度之Quarts
- 以小见大——那些基于 protobuf 的五花八门的 RPC(1)
- ios中使用自定义的字体库
- python学习笔记(三)
- 支持向量机(SVM)基础
- windows WDM驱动程序设计
- windows WDF驱动程序设计
- linux入门常用命令
- fatal error LNK1169: one or more multiply defined symbols found
- STM32F 好书推荐