1.?前言

RPC全称为Remote?Procedure?Call，即远过程调用。如果没有RPC，那么跨机器间的进程通讯通常得采用消息（网络通信tcp或者udp），这会降低开发效率，也会增加网络层和上层的耦合度，RPC可以帮助我们解决这些问题。

其实就是他封装了这个网络通信的实现细节，与具体的通信不耦合，不用写网络通信的代码，自然就会提高开发效率。我在工作中用到的主要两种rpc就是? ?Zeroc? 的ice,以及google的grpc.

2.?基本概念

在正式讲解之前，先介绍一下与RPC有关的基本概念：

2.1.?IDL

IDL的全称是Interface?Definition?Language，即接口定义语言（有时也叫作接口描述语言）。因为RPC通常是跨进程、跨机器、跨系统和跨语言的，IDL是用来解决这个问题的，它与语言无关，借助编译器将它翻译成不同的编程语言。

Google开源的ProtoBuf中的“.proto”文件就是一种IDL文件：

message?Person?{
??required?int32?id?=?1;
??required?string?name?=?2;
??optional?string?email?=?3;
}

在.proto文件中message类似于C语言中的struct的，转换成C++语言后，它对应于C++中的一个类。有关ProtoBuf的更多信息，可参考：。

请注意，IDL中的数据类型（如ProtoBuf中的int32）是独立于任何语言的，但它通常会和目标语言中的数据类型有着映射关系，否则将无法把IDL文件编译成目标语言文件。

2.2.?代理（Proxy）

代理（Proxy）是RPC的客户端实现，客户端代码总是通过代理来与RPC服务端通讯。Proxy的代码完全由IDL编译器生成。

2.3.?存根（Stub）

存根（Stub）是RPC的服务端实现。在服务端，需要实现IDL文件中定义的接口；而在客户端直接使用。代理和存根的关系如下图所示：

?这里我稍微解释下，Proxy,代理一般是我们所说的正向代理，它代理的是服务器。而那个存根Stub,一般都是指留的底稿，底稿肯定是在服务器放着，然后我们在服务器端要实现Stub里的方法，因为Stub也是框架根据你写的IDL语言生成的，而使用者要实现 Implement这个类，一般我们用的时候都是用这个? Implement的指针形式，因为我们可能并不一定会实现 Stub的所有接口，所以可能我们实例化不了对象的是。然后不管是哪一个框架，我们都要把我们的? Implement的指针注册给这个? Stub或者是说底层，因为底层如果收到数据，肯定得通过指针来触发多态来调用你实现的方法。

3.?三要素

要实现一个完整的RPC，需要完成以下三件事，在这里我们把这三件事称作三要素：

3.1.?网络通讯

负责将客户端的请求发送到服务端，和将服务端的响应回送给客户端。这是大家都熟悉的一块，主要就是高性能网络程序的实现。

3.2.?消息编解码

IDL中定义接口、函数和数据等，需要在发送前编码成字节流，在收到后进行解码。比如将函数名、参数类型和参数值等编码成字节流，然后发送给对端，然后对端进行解码，还原成函数调用。ProtoBuf就是一个非常好的编解码工具。

请注意IDL支持的所有数据类型要求是可编解码的，IDL编译器需要知道如何将它编码到字节流，和从字节流里解码还原出来。

3.3.?IDL编译器

对大多数人来说，这块的工作是陌生的，因为日常开发接触不多。也因为如此，一般人都会觉得这块很难高深。其实只要克服心理障碍，学习它比想象中的要容易许多。总而言之，上手并不难，特别是在阅读了本文之后。但是如果需要实现一个类似于Hive或GCC东东，那是有相当大的难度的，其中对优化语法树就是一个非常大的挑战。

为了能够使用RPC，需要将IDL文件编译成指定的语言代码。ProtoBuf实际上已经实现了这个功能。如果基于ProtoBuf实现一个RPC，则这IDL编译这一步可以跳过，将只需要实现网络通讯，以及实现google::protobuf::RpcController和google::protobuf::RpcChannel两个接口即可。

本文是为了介绍RPC的实现，目标是让读者能够自己实现一套RPC，而对于三要素中的网络通讯和消息编解码，一般人都容易理解和上手，但对于IDL编译这块相对会陌生许多。为此，本文余下部分将着重介绍IDL编译的实现，所有的实现都将基于Flex和Bison两个开源的工具，当然也可使用JavaCC、SableCC和Antlr（ANother?Tool?for?Language?Recognition）等。