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

Descriptor框架

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

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

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实例以初始化其他的静态字段，如以上提到的所有的静态字段。

在protobuf中Descriptor的类图：

Message、MessageLite框架

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

MessageLiteOrBuilder接口只定义了MessageLite和MessageLite.Builder两个接口共有的两个方法：getDefaultInstanceForType()方法获取一个当前还未初始化的当前Message实例(没有字段被赋值，因而所有字段返回默认值，对repeat字段返回空，在当前protobuf 2.5.0的实现中，它返回的是一个单例，和每个生成的静态方法getDefaultInstance()返回相同的实例)；isInitialized()方法用来判断是否所有required字段已经被赋值。MessageLite接口中定义了两个writeTo()方法分别将当前实例序列化并写入输出字节流中，而另一个writeDelimitedTo()方法则在写入之前将当前实例的总长度写入输出字节流中（以可变长32位Int编码方式），从而可以同时向一个输出字节流中写入多个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接口，它定义了Message和Message.Builder共有的接口，即添加了Descriptor、FieldDescriptor等相关的扩展。由于实现Message和Message.Builder接口的类保存了所有Message定义时具有的信息(文件名、包名、字段列表等，使用各种Descriptor类来抽象)，因而我们可以使用Message/Message.Builder类获取到更多的信息，如一个Message/Message.Builder没有赋值所有required的字段，可以使用findInitializationErrors()方法来获取所有未赋值的字段列表(字段的全路径名，getInitializationErrorString()是这个列表的字符串形式表达，为了提升性能，建议使用isInitialized()方法先做初步判断，因为它更快)；另外在MessageOrBuilder中还定义了当前Message对应的Descriptor实例：getDescriptorForType()方法，获取所有已经赋值的FieldDescriptor到其值的一个Map：getAllFields()，通过FieldDescriptor取得其值：getField()，判断一个字段是否已经被赋值：hasField()，获取repeated字段的count：getRepeatedFieldCount()，通过FieldDescriptor以及index获取repeated字段在index处的值：getRepeatedField()，获取未知的字段：getUnknownFields()。Message接口除了继承自MessageOrBuilder接口的方法，并没有定义多余的方法，只是添加了equals、hashCode、toString方法的定义。而Message.Builder接口除了继承自MessageOrBuilder接口以外，它还定义了基于FieldDescriptor的方法，如通过FieldDescriptor创建/获取Builder实例：newBuilderForFileld()/getFieldBuilder()，通过FieldDescriptor设置/清除字段的值：setField()/clearField()/setRepeatedField()/addRepeatedField()，以及设置UnknownFields：setUnknownFields()/mergeUnknownFields()。

MessageLite/Message类图如下：

RPC框架

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

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

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

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

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