深入Protobuf源码-Descriptor、Message、RPC框架

简介:

Descriptor框架

对非 optimize_for LITE_RUNTIME proto 文件, protobuf 编译器会在编译出的 Java 代码文件末尾添加一个 FileDescriptor 静态字段以描述该 proto 文件定义时的所有元数据信息、为每个 message 对象定义一个 Descriptor 静态字段以描述该 message 定义时的元数据信息、为每个 message 对象定义一个 FieldAccessorTable 静态字段用于使用反射读取 / 设置某个字段的值等(以提供 GeneratedMessage 中方法的反射实现):     
private  static Descriptor inter-nal_static_levin_protobuf_Result_descriptor;
private  static FieldAccessorTable inter-nal_static_levin_protobuf_Result_fieldAccessorTable;
private  static Descriptor inter-nal_static_levin_protobuf_SearchResponse_descriptor;
private  static FieldAccessorTable inter-nal_static_levin_protobuf_SearchResponse_fieldAccessorTable;
private  static FileDescriptor descriptor;

protobuf中存在多种类型的元数据描述类:

1.     FileDescriptor:对一个proto文件的描述,它包含文件名、包名、选项(如java_packagejava_outer_classname等)、文件中定义的所有message、文件中定义的所有enum、文件中定义的所有service、文件中所有定义的extension、文件中定义的所有依赖文件(import)等。在FileDescriptor中还存在一个DescriptorPool实例,它保存了所有的dependencies(依赖文件的FileDescriptor)nameGenericDescriptor的映射、字段到FieldDescriptor的映射、枚举项到EnumValueDescriptor的映射,从而可以从该DescriptorPool中查找相关的信息,因而可以通过名字从FileDescriptor中查找MessageEnumServiceExtensions等。

2.   Descriptor:对一个message定义的描述,它包含该message定义的名字、所有字段、内嵌message、内嵌enum、关联的FileDescriptor等。可以使用字段名或字段号查找FieldDescriptor

3.   FieldDescriptor:对一个字段或扩展字段定义的描述,它包含字段名、字段号、字段类型、字段定义(required/optional/repeated/packed)、默认值、是否是扩展字段以及和它关联的Descriptor/FileDescriptor等。

4.   EnumDescriptor:对一个enum定义的描述,它包含enum名、全名、和它关联的FileDescriptor。可以使用枚举项或枚举值查找EnumValueDescriptor

5.   EnumValueDescriptor:对一个枚举项定义的描述,它包含枚举名、枚举值、关联的EnumDescriptor/FileDescriptor等。

6.   ServiceDescriptor:对一个service定义的描述,它包含service名、全名、关联的FileDescriptor等。

7.   MethodDescriptor:对一个在service中的method的描述,它包含method名、全名、参数类型、返回类型、关联的FileDescriptor/ServiceDescriptor等。

最后,protobuf编译生成的代码末尾还有一个descriptorData字符串数组,它是序列化后的FileDescriptorProto数据,在静态初始化块中可以调用FileDescriptor.internalBuildGeneratedFileFrom()方法构造整个FileDescriptor实例,在完成FileDescriptor的构造后,还会回调传入的InternalDescriptorAssigner实例以初始化其他的静态字段,如以上提到的所有的静态字段。

protobufDescriptor的类图:


Message、MessageLite框架

序列化和反序列化是protobuf最基础的框架,它使用MessageLite/Message接口来抽象一个可序列化的实例,并且使用Builder从字节数组或输入字节流中构建MessageLite/Message实例,MessageLiteMessage内部都定义了自己的Builder类,他们个字继承自MessageLiteOrBuilder以及MessageOrBuiler,它们定义了MessageLite/Message和它们各自Builder类的共同接口。

MessageLiteOrBuilder接口只定义了MessageLiteMessageLite.Builder两个接口共有的两个方法:getDefaultInstanceForType()方法获取一个当前还未初始化的当前Message实例(没有字段被赋值,因而所有字段返回默认值,对repeat字段返回空,在当前protobuf 2.5.0的实现中,它返回的是一个单例,和每个生成的静态方法getDefaultInstance()返回相同的实例)isInitialized()方法用来判断是否所有required字段已经被赋值。MessageLite接口中定义了两个writeTo()方法分别将当前实例序列化并写入输出字节流中,而另一个writeDelimitedTo()方法则在写入之前将当前实例的总长度写入输出字节流中(以可变长32Int编码方式),从而可以同时向一个输出字节流中写入多个Message实例;MessageLite中还定义了获取当前MessageLite在序列化成字节流后的总字节数的方法getSerializedSize(),两个直接返回字节数组的toByteArray()/toByteString()方法,以及获取它的Parser实例(getParserForType())和返回它的Builder实例(toBuilder()-创建一个新的Builder实例/newBuilderForType()-用当前MessageLite类初始化一个新的Builder实例并返回)方法。其中Builder接口用于从字节流或字节数组中解析并构造MessageLite对象(各种版本的mergeFrom()方法,如果发送端写入了MessageLite字节长度,则使用mergeDelimitedFrom()方法),最后Builder使用build()方法构造MessageLite对象,此时如果有required字段还未被设置,会抛出UninitializedMessageException,为了避免抛出异常,可以使用buildPartial()方法;另外Builder还定义了clone()clear()方法;在生成的每个Message对象中都定义了一个newBuilder()静态方法,一般使用该静态方法初始化一个Builder实例。Parser接口也定义了各个版本的parseFrom()/parsePartialFrom()/parseDelimitedFrom()/parsePartialDelimitedFrom()方法用来从字节数组或字节流中解析出Message实例,在生成的代码中,Builder的实现直接调用Parser实现类中的方法。

在大部分情况下,MessageLite已经能完成所有的序列化和反序列化操作了,特别是一些资源有限额手持设备,它如果运行整个protobuf库会显得太耗资源;可以在.proto文件中加入一下指令来告诉protobuf编译器只需要生成实现MessageLite的类:

option optimize_for = LITE_RUNTIME

然而对一般的Server程序来说,我们并不在乎这点资源的损耗,因而会选择实现Message接口,它相比MessageLite,添加了Descriptors相关的支持,即支持使用FieldDescriptor来构建Message.Builder实例并最终构建Message实例。

MessageOrBuilder接口继承自MessageLiteOrBuilder接口,它定义了MessageMessage.Builder共有的接口,即添加了DescriptorFieldDescriptor等相关的扩展。由于实现MessageMessage.Builder接口的类保存了所有Message定义时具有的信息(文件名、包名、字段列表等,使用各种Descriptor类来抽象),因而我们可以使用Message/Message.Builder类获取到更多的信息,如一个Message/Message.Builder没有赋值所有required的字段,可以使用findInitializationErrors()方法来获取所有未赋值的字段列表(字段的全路径名,getInitializationErrorString()是这个列表的字符串形式表达,为了提升性能,建议使用isInitialized()方法先做初步判断,因为它更快);另外在MessageOrBuilder中还定义了当前Message对应的Descriptor实例:getDescriptorForType()方法,获取所有已经赋值的FieldDescriptor到其值的一个MapgetAllFields(),通过FieldDescriptor取得其值:getField(),判断一个字段是否已经被赋值:hasField(),获取repeated字段的countgetRepeatedFieldCount(),通过FieldDescriptor以及index获取repeated字段在index处的值:getRepeatedField(),获取未知的字段:getUnknownFields()Message接口除了继承自MessageOrBuilder接口的方法,并没有定义多余的方法,只是添加了equalshashCodetoString方法的定义。而Message.Builder接口除了继承自MessageOrBuilder接口以外,它还定义了基于FieldDescriptor的方法,如通过FieldDescriptor创建/获取Builder实例:newBuilderForFileld()/getFieldBuilder(),通过FieldDescriptor设置/清除字段的值:setField()/clearField()/setRepeatedField()/addRepeatedField(),以及设置UnknownFieldssetUnknownFields()/mergeUnknownFields()

 

MessageLite/Message类图如下:



RPC框架

除了序列化框架,protobuf还定义了一套简单的RPC框架。之所以说简单是因为它定义的Service层接口的协议,而没有具体和传输相关的实现,而只是将传输相关的逻辑抽象成RpcChannelBlockingRpcChannel分别用于表示同步和一步方式的Service方法调用,而至于底层用什么样的协议和框架,由用户自己决定并实现。

所谓RPC框架,从用户角度上最基本的就是定义客户端和服务器端的协议,即服务器端暴露出什么样的接口供客户端调用,这个接口定义了服务器在一个Host的某个(些)端口上接收某些请求数据,并期望能返回的响应。其中服务器和端口号属于传输实现的范畴,protobuf只是用RpcChannel/BlockingRpcChannel的概念做了抽象,而没有给出具体实现;而接收某个请求数据以及期待的响应数据,在protobuf使用Service/BlockingService抽象来定义,并且这也是protobufRPC框架的定义部分,其中ServiceRpcChannel共同构成异步方式的RPC框架,而BlockingServiceBlockingRpcChannel共同构成了同步(阻塞)方式的RPC框架。

从底层实现的角度,一个RPC调用就是客户端发送一些请求数据给服务器,服务器解析并处理这些请求数据,然后将响应数据返回给客户端。为了隐藏内部实现细节,提升写代码的效率,RPC将这一过程封装成方法调用,即不同的请求用不同的方法表达,这就是protobufRPC的定义。在protobuf中,定义一个PRC接口比较简单:首先开启RPC功能,然后用service关键字定义一个接口,在接口中使用rpc关键字定义一个方法,方法包含方法名、方法参数、返回值,其中方法参数和返回值都必须是一个message类型,并且只能有一个:

option java_generic_services =  true;

service MyService {
    rpc request(SearchRequest) returns(SearchResponse);
}

protobuf编译生成的代码中,它会生成一个MyService抽象类实现了Service接口,一般它只是作为一个命名空间,它内部定义了两个接口:InterfaceBlockingInterface本别继承自Service接口和BlockingService接口,用于抽象异步和同步方式的RPC方法调用;这两个接口有两个实现类:StubBlockingStub,他们分别接收RpcChannelBlockingRpcChannel实例作为构造函数参数,可以使用MyService中的静态方法newStub()newBlockingStub()方法获取他们各自实例,他们主要用于客户端的调用。在生成的request方法中,除了request本身的参数,还有一个RpcController参数,它用于处理在RpcChannel/BlockingRpcChannel调用中的状态处理,如错误处理等,使用它可以获知此次调用是否出错,错误信息是什么等。在MyService中还定义了两个静态方法newReflectiveService/newReflectiveBlockingService,他们接收Interface/BlockingInterface实例,并返回Service/BlockingService的实现实例(暂时还没有想到使用他们的场景)。



MyServiceRPC框架实现中,在服务器端,实现MyService.Interface/MyService.BlockingInterface接口,然后将它注册到对RpcChannel/BlockingRpcChannel框架的实现中;在客户端则创建一个RpcChannel/BlockingRpcChannel实例,传入MyService.newStub()/MyService.newBlockingStub()方法获取对应的实例,然后使用这个Stub/BlockingStub实例调用相应的方法即可。


相关文章
|
7月前
|
负载均衡 Dubbo Java
Dubbo 3.x:探索阿里巴巴的开源RPC框架新技术
随着微服务架构的兴起,远程过程调用(RPC)框架成为了关键组件。Dubbo,作为阿里巴巴的开源RPC框架,已经演进到了3.x版本,带来了许多新特性和技术改进。本文将探讨Dubbo 3.x中的一些最新技术,包括服务注册与发现、负载均衡、服务治理等,并通过代码示例展示其使用方式。
392 9
|
7月前
|
XML 存储 JSON
从零开始学习 RPC 与 Protobuf
在数据密集型应用领域,Google 开发的 Protobuf 作为一种高效数据编码方式而广受欢迎。它胜任于 JSON 及 XML 对比,不仅在体积和速度上表现出色,而且其结构化方式优化了网络传输中的性能。简而言之,Protobuf 是将复杂数据结构编码成二进制流的手段,并能够轻松将这些流再还原回原始数据格式。
|
7月前
|
设计模式 负载均衡 网络协议
【分布式技术专题】「分布式技术架构」实践见真知,手把手教你如何实现一个属于自己的RPC框架(架构技术引导篇)
【分布式技术专题】「分布式技术架构」实践见真知,手把手教你如何实现一个属于自己的RPC框架(架构技术引导篇)
289 0
|
7月前
|
Dubbo Java 应用服务中间件
Rpc编程系列文章第三篇:Hessian RPC一个老的RPC框架
Rpc编程系列文章第三篇:Hessian RPC一个老的RPC框架
|
1月前
|
自然语言处理 负载均衡 API
gRPC 一种现代、开源、高性能的远程过程调用 (RPC) 可以在任何地方运行的框架
gRPC 是一种现代开源高性能远程过程调用(RPC)框架,支持多种编程语言,可在任何环境中运行。它通过高效的连接方式,支持负载平衡、跟踪、健康检查和身份验证,适用于微服务架构、移动设备和浏览器客户端连接后端服务等场景。gRPC 使用 Protocol Buffers 作为接口定义语言,支持四种服务方法:一元 RPC、服务器流式处理、客户端流式处理和双向流式处理。
|
4月前
|
Dubbo 网络协议 Java
RPC框架:一文带你搞懂RPC
这篇文章全面介绍了RPC(远程过程调用)的概念、原理和应用场景,解释了RPC如何工作以及为什么在分布式系统中广泛使用,并探讨了几种常用的RPC框架如Thrift、gRPC、Dubbo和Spring Cloud,同时详细阐述了RPC调用流程和实现透明化远程服务调用的关键技术,包括动态代理和消息的编码解码过程。
RPC框架:一文带你搞懂RPC
|
3月前
|
XML 负载均衡 监控
分布式-dubbo-简易版的RPC框架
分布式-dubbo-简易版的RPC框架
|
5月前
|
负载均衡 Java API
Feign 进行rpc 调用时使用ribbon负载均衡源码解析
Feign 进行rpc 调用时使用ribbon负载均衡源码解析
78 11
|
6月前
|
存储 缓存 Linux
【实战指南】嵌入式RPC框架设计实践:六大核心类构建高效RPC框架
在先前的文章基础上,本文讨论如何通过分层封装提升一个针对嵌入式Linux的RPC框架的易用性。设计包括自动服务注册、高性能通信、泛型序列化和简洁API。框架分为6个关键类:BindingHub、SharedRingBuffer、Parcel、Binder、IBinder和BindInterface。BindingHub负责服务注册,SharedRingBuffer实现高效数据传输,Parcel处理序列化,而Binder和IBinder分别用于服务端和客户端交互。BindInterface提供简单的初始化接口,简化应用集成。测试案例展示了客户端和服务端的交互,验证了RPC功能的有效性。
429 7
|
4月前
|
XML 存储 JSON
(十二)探索高性能通信与RPC框架基石:Json、ProtoBuf、Hessian序列化详解
如今这个分布式风靡的时代,网络通信技术,是每位技术人员必须掌握的技能,因为无论是哪种分布式技术,都离不开心跳、选举、节点感知、数据同步……等机制,而究其根本,这些技术的本质都是网络间的数据交互。正因如此,想要构建一个高性能的分布式组件/系统,不得不思考一个问题:怎么才能让数据传输的速度更快?
106 1