RPC 基本原理与 Apach Thrift 初体验

首先了解什么叫RPC，为什么要RPC，RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。比如说，一个方法可能是这样定义的：

Employee getEmployeeByName(String fullName)那么：

首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。

第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint

URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。

第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。

第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。

第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用

RPC 框架屏蔽了底层传输方式（TCP/UDP）、序列化和反序列化（XML/JSON/二进制）等内容，使用框架只需要知道被调用者的地址和接口就可以了，无须额外地为这些底层内部编程。 目前主流的 RPC 框架有如下几种

Thrift：Facebook 开源的跨语言框架

gRPC：Google 基于 HTTP/2 和 Protobuf 的能用框架

Avro：Hadoop 的子项目

本文讲述 RPC 的基本原理并以 Thrift 框架为例说明 RPC 的使用。

图1：客户端与服务器之间的 RPC 通信过程

图1描述了客户端与服务器 RPC 通信的基本过程，具体来说，包括几下步骤：

（1）客户过程以正常方式调用客户桩（client stub，一段代码）；

（2）客户桩生成一个消息，然后调用本地操作系统；

（3）客户端操作系统将消息发送给远程操作系统；

（4）远程操作系统将消息交给服务器桩（server stub，一段代码）；

（5）服务器桩将参数提取出来，然后调用服务器过程；

（6）服务器执行要求的操作，操作完成后将结果返回给服务器桩；

（7）服务器桩将结果打包成一个消息，然后调用本地操作系统；

（8）服务器操作系统将含有结果的消息发送回客户端操作系统；

（9）客户端操作系统将消息交给客户桩；

（10）客户桩将结果从从消息中提取出来，返回给调用它的客户过程。

所有这些步骤的效果是，将客户过程对客户桩发出的本地调用转换成对服务器过程的本地调用，而客户端和服务器都不会意识到有中间步骤的存在。

这个时候，你可能会想，既然是调用另一台机器的服务，使用 RESTful API 也可以实现啊，为什么要选择 RPC 呢？我们可以从两个方面对比：

资源粒度。RPC 就像本地方法调用，RESTful API 每一次添加接口都可能需要额外地组织开放接口的数据，这相当于在应用视图中再写了一次方法调用，而且它还需要维护开发接口的资源粒度、权限等。

流量消耗。RESTful API 在应用层使用 HTTP 协议，哪怕使用轻型、高效、传输效率高的 JSON 也会消耗较大的流量，而 RPC 传输既可以使用 TCP 也可以使用 UDP，而且协议一般使用二制度编码，大大降低了数据的大小，减少流量消耗。

对接异构第三方服务时，通常使用 HTTP/RESTful 等公有协议，对于内部的服务调用，应用选择性能更高的二进制私有协议。

Thrift

Thrift是一个跨语言的服务部署框架，最初由Facebook于2007年开发，2008年进入Apache开源项目。Thrift通过一个中间语言(IDL, 接口定义语言)来定义RPC的接口和数据类型，然后通过一个编译器生成不同语言的代码（目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk和OCaml）,并由生成的代码负责RPC协议层和传输层的实现。

Thrift实际上是实现了C/S模式，通过代码生成工具将接口定义文件生成服务器端和客户端代码（可以为不同语言），从而实现服务端和客户端跨语言的支持。用户在Thirft描述文件中声明自己的服务，这些服务经过编译后会生成相应语言的代码文件，然后用户实现服务（客户端调用服务，服务器端提服务）便可以了。其中protocol（协议层, 定义数据传输格式，可以为二进制或者XML等）和transport（传输层，定义数据传输方式，可以为TCP/IP传输，内存共享或者文件共享等）被用作运行时库。

Thrift的协议栈如下图所示：

在Client和Server的最顶层都是用户自定义的处理逻辑，也就是说用户只需要编写用户逻辑，就可以完成整套的RPC调用流程。用户逻辑的下一层是Thrift自动生成的代码，这些代码主要用于结构化数据的解析,发送和接收，同时服务器端的自动生成代码中还包含了RPC请求的转发（Client的A调用转发到Server A函数进行处理）。

协议栈的其他模块都是Thrift的运行时模块：

底层IO模块，负责实际的数据传输，包括Socket，文件，或者压缩数据流等。

TTransport负责以字节流方式发送和接收Message，是底层IO模块在Thrift框架中的实现，每一个底层IO模块都会有一个对应TTransport来负责Thrift的字节流(Byte Stream)数据在该IO模块上的传输。例如TSocket对应Socket传输，TFileTransport对应文件传输。

TProtocol主要负责结构化数据组装成Message，或者从Message结构中读出结构化数据。TProtocol将一个有类型的数据转化为字节流以交给TTransport进行传输，或者从TTransport中读取一定长度的字节数据转化为特定类型的数据。如int32会被TBinaryProtocol Encode为一个四字节的字节数据，或者TBinaryProtocol从TTransport中取出四个字节的数据Decode为int32。

TServer负责接收Client的请求，并将请求转发到Processor进行处理。TServer主要任务就是高效的接受Client的请求，特别是在高并发请求的情况下快速完成请求。

Processor(或者TProcessor)负责对Client的请求做出相应，包括RPC请求转发，调用参数解析和用户逻辑调用，返回值写回等处理步骤。Processor是服务器端从Thrift框架转入用户逻辑的关键流程。Processor同时也负责向Message结构中写入数据或者读出数据。

Thrift的模块设计非常好，在每一个层次都可以根据自己的需要选择合适的实现方式。同时也应该注意到Thrift目前的特性并不是在所有的程序语言中都支持。例如C++实现中有TDenseProtocol没有TTupleProtocol，而Java实现中有TTupleProtocol没有TDenseProtocol。

Thrift安装过程见https://www.jianshu.com/p/82a6bdaabcd3

python代码实现server端和client端

实现 server 端：

server.py：

实现 client 端：

client.py：

执行验证结果：

1、先启动 server，之后再执行 client

2、client 侧控制台如果打印的结果为： HELLO,WORLD! ，证明 Thrift 的 RPC 接口定义成功