长文图解Google的protobuf思考、设计、应用

• 一、前言

• 二、RPC 基础概念

• 三、protobuf 基本使用

• 四、libevent

• 五、实现 RPC 框架

• 1. 基本框架构思

• 2. 元数据的设计

• 3. 分析：客户端发送请求

• 4. 分析：服务端接收请求

• 5. 分析：服务端发送响应

• 6. 分析：客户端接收响应
  

• 六、总结

• 1. protobuf 的核心

• 2. 未解决的问题
  

Warning: 文章有点长，我主要是想在一篇文章中把相关的重点内容都讲完、讲透彻，请见谅。

以后，我尽可能不写这么长的文章。

一、前言

在嵌入式系统中，很少需要使用到 RPC (Remote Procedure Call)远程方法调用，因为在大部分情况下，实现一个产品功能的所有进程、线程都是运行在同一个硬件设备中的。

但是在一些特殊的场景中，RPC 调用还是很有市场的，比如：

在计算密集型产品中，需要调用算力更强的中央服务器提供的算法函数；

因此，利用 RPC 来利用远程提供的服务，相对于其他的机制来说，有更多的优势。

这篇文章我们就来聊一聊 RPC 的相关内容，来看一下如何利用 Google 的开源序列化工具 protobuf，来实现一个我们自己的 RPC 框架。

序列化[1]：将结构数据或对象转换成能够被存储和传输（例如网络传输）的格式，同时应当要保证这个序列化结果在之后（可能在另一个计算环境中）能够被重建回原来的结构数据或对象。

我会以 protobuf 中的一些关键 C 类作为突破口，来描述从客户端发起调用，到服务端响应，这个完整执行序列。也就是下面这张图：

这张图大概画了 2 个小时(边看代码，边画图)，我已经尽力了，虽然看起来有点乱。

在下面的描述中，我会根据每一部分的主题，把这张图拆成不同的模块，从空间(文件和类的结构)和时间(函数的调用顺序、数据流向)这两个角度，来描述图中的每一个元素，我相信聪明的你一定会看明白的！

希望你看了这篇文章之后，对 RPC 框架的设计过程有一个基本的认识和理解，应对面试官的时候，关于 RPC 框架设计的问题应该绰绰有余了。

如果在项目中恰好选择了 protobuf，那么根据这张图中的模块结构和函数调用流程分析，可以协助你更好的完成每一个模块的开发。

注意：这篇文章不会聊什么内容：

1. protfobuf 的源码实现；
2. protfobuf 的编码算法；

二、RPC 基础概念

1. RPC 是什么？

RPC (Remote Procedure Call)从字面上理解，就是调用一个方法，但是这个方法不是运行在本地，而是运行在远端的服务器上。也就是说，客户端应用可以像调用本地函数一样，直接调用运行在远端服务器上的方法。

下面这张图描述了 RPC 调用的基本流程：

假如，我们的应用程序需要调用一个算法函数来获取运动轨迹:

int getMotionPath(float *input, int intputLen, float *output, int outputLen)
如果计算过程不复杂，可以把这个算法函数和应用程序放在本地的同一个进程中，以源代码或库的方式提供计算服务，如下图：

但是，如果这个计算过程比较复杂，需要耗费一定的资源(时间和空间)，本地的 CPU 计算能力根本无法支撑，那么就可以把这个函数放在 CPU 能力更强的服务器上。

此时，调用过程如下图这样：

从功能上来看，应用程序仍然是调用远程服务器上的一个方法，也就是虚线部分。但是由于他们运行在不同的实体设备上，更不是在同一个进程中，因此，如果想调用成功就一定需要利用网络来传输数据。

初步接触 RPC 的朋友可能会提出：

那我可以在应用程序中把算法需要的输入数据打包好，通过网络发送给算法服务器；服务器计算出结果后，再打包好返回给应用程序就可以了。

这句话说的非常对，从功能上来说，这个描述过程就是 RPC 所需要做的所有事情。

不过，在这个过程中，有很多问题需要我们来手动解决：

1. 如何处理通信问题？TCP or UDP or HTTP？或者利用其他的一些已有的网络协议？

2. 如何把数据进行打包？服务端接收到打包的数据之后，如何还原数据？

3. 对于特定领域的问题，可以专门写一套实现来解决，但是对于通用的远程调用，怎么做到更灵活、更方便？

为了解决以上这几个问题，于是 RPC 远程调用框架就诞生了！

图中的绿色背景部分，就是 RPC 框架需要做的事情。

对于应用程序来说，Client 端代理就相当于是算法服务的“本地代理人”，至于这个代理人是怎么来处理刚才提到的那几个问题、然后从真正的算法服务器上得到结果，这就不需要应用程序来关心了。

结合文章的第一张图中，从应用程序的角度看，它只是执行了一个函数调用(步骤1)，然后就立刻得到了结果(步骤10)，这中间的所有步骤(2-9)，全部是 RPC 框架来处理，而且能够灵活的处理各种不同的请求、响应数据。

铺垫到这里，我就可以更明确的再次重复一下了：这篇文章的目的，就是介绍如何利用 protobuf 来实现图中的绿色部分的功能。

最终的目的，将会输出一个 RPC 远程调用框架的库文件(动态库、静态库)：

1. 服务器端利用这个库，在网络上提供函数调用服务；

2. 客户端利用这个库，远程调用位于服务器上的函数；

2. 需要解决什么问题？

既然我们是介绍 RPC 框架，那么需要解决的问题就是一个典型的 RPC 框架所面对问题，如下：

1. 解决函数调用时，数据结构的约定问题；
2. 解决数据传输时，序列化和反序列化问题；
3. 解决网络通信问题；

这 3 个问题是所有的 RPC 框架都必须解决的，这是最基本的问题，其他的考量因素就是：速度更快、成本更低、使用更灵活、易扩展、向后兼容、占用更少的系统资源等等。

另外还有一个考量因素：跨语言。比如：客户端可以用 C 语言实现，服务端可以用 C/C 、Java或其他语言来实现，在技术选型时这也是非常重要的考虑因素。

3. 有哪些开源实现？

从上面的介绍中可以看出来，RPC 的最大优势就是降低了客户端的函数调用难度，调用远程的服务就好像在调用本地的一个函数一样。

因此，各种大厂都开发了自己的 RPC 框架，例如：

Google 的 gRPC;
Facebook 的 thrift;
腾讯的 Tars;
百度的 BRPC;

另外，还有很多小厂以及个人，也会发布一些 RPC 远程调用框架（tinyRPC，forestRPC，EasyRPC等等）。每一家 RPC 的特点，感兴趣的小伙伴可以自行去搜索比对，这里对 gRPC 多说几句，

我们刚才主要聊了 protobuf，其实它只是解决了序列化的问题，对于一个完整的 RPC 框架，还缺少网络通信这个步骤。

gRPC 就是利用了 protobuf，来实现了一个完整的 RPC 远程调用框架，其中的通信部分，使用的是 HTTP 协议。

三、protobuf 基本使用

1. 基本知识

Protobuf 是 Protocol Buffers 的简称, 它是 Google 开发的一种跨语言、跨平台、可扩展的用于序列化数据协议，

Protobuf 可以用于结构化数据序列化(串行化)，它序列化出来的数据量少，再加上以 K-V 的方式来存储数据，非常适用于在网络通讯中的数据载体。

只要遵守一些简单的使用规则，可以做到非常好的兼容性和扩展性，可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。

Protobuf 中最基本的数据单元是 message ，并且在 message 中可以多层嵌套 message 或其它的基础数据类型的成员。

Protobuf 是一种灵活，高效，自动化机制的结构数据序列化方法，可类比 XML，但是比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更简单，而且它支持 Java、C 、Python 等多种语言。

2. 使用步骤

Step1：创建 .proto 文件，定义数据结构

例如，定义文件 echo_service.proto, 其中的内容为：

message EchoRequest {
string message = 1;
}

message EchoResponse {
string message = 1;
}

message AddRequest {
int32 a = 1;
int32 b = 2;
}

message AddResponse {
int32 result = 1;
}

service EchoService {
rpc Echo(EchoRequest) returns(EchoResponse);
rpc Add(AddRequest) returns(AddResponse);
}

最后的 service EchoService，是让 protoc 生成接口类，其中包括 2 个方法 Echo 和 Add：

Echo 方法：客户端调用这个方法，请求的“数据结构” EchoRequest 中包含一个 string 类型，也就是一串字符；服务端返回的“数据结构” EchoResponse 中也是一个 string 字符串；

Add 方法：客户端调用这个方法，请求的“数据结构” AddRequest 中包含 2 个整型数据，服务端返回的“数据结构” AddResponse 中包含一个整型数据(计算结果);

Step2: 使用 protoc 工具，来编译 .proto 文件，生成接口(类以及相应的方法)

protoc echo_service.proto -I./ --cpp_out=./
执行以上命令，即可生成两个文件：echo_service.pb.h, echo_service.pb.c，在这 2 个文件中，定义了 2 个重要的类，也就是下图中绿色部分：

EchoService 和 EchoService_Stub 这 2 个类就是接下来要介绍的重点。我把其中比较重要的内容摘抄如下(为减少干扰，把命名空间字符都去掉了)：

class EchoService : public ::PROTOBUF_NAMESPACE_ID::Service {
virtual void Echo(RpcController* controller,
EchoRequest* request,
EchoResponse* response,
Closure* done);

virtual void Add(RpcController* controller,
AddRequest* request,
AddResponse* response,
Closure* done);

void CallMethod(MethodDescriptor* method,
RpcController* controller,
Message* request,
Message* response,
Closure* done);
}
class EchoService_Stub : public EchoService {
public:
EchoService_Stub(RpcChannel* channel);

void Echo(RpcController* controller,
EchoRequest* request,
EchoResponse* response,
Closure* done);

void Add(RpcController* controller,
AddRequest* request,
AddResponse* response,
Closure* done);

private:
// 成员变量，比较关键
RpcChannel* channel_;
};
Step3：服务端程序实现接口中定义的方法，提供服务；客户端调用接口函数，调用远程的服务。

请关注上图中的绿色部分。

（1）服务端：EchoService

EchoService 类中的两个方法 Echo 和 Add 都是虚函数，我们需要继承这个类，定义一个业务层的服务类 EchoServiceImpl，然后实现这两个方法，以此来提供远程调用服务。

EchoService 类中也给出了这两个函数的默认实现，只不过是提示错误信息：

void EchoService::Echo() {
controller->SetFailed("Method Echo() not implemented.");
done->Run();
}
void EchoService::Add() {
controller->SetFailed("Method Add() not implemented.");
done->Run();
}
图中的 EchoServiceImpl 就是我们定义的类，其中实现了 Echo 和 Add 这两个虚函数：

void EchoServiceImpl::Echo(RpcController* controller,
EchoRequest* request,
EchoResponse* response,
Closure* done)
{
// 获取请求消息，然后在末尾加上信息：", welcome!"，返回给客户端
response->set_message(request->message() ", welcome!");
done->Run();
}

void EchoServiceImpl::Add(RpcController* controller,
AddRequest* request,
AddResponse* response,
Closure* done)
{
// 获取请求数据中的 2 个整型数据
int32_t a = request->a();
int32_t b = request->b();

// 计算结果，然后放入响应数据中
response->set_result(a b);

done->Run();
}
（2）客户端：EchoService_Stub

EchoService_Stub 就相当于是客户端的代理，应用程序只要把它"当做"远程服务的替身，直接调用其中的函数就可以了(图中左侧的步骤1)。

因此，EchoService_Stub 这个类中肯定要实现 Echo 和 Add 这 2 个方法，看一下 protobuf 自动生成的实现代码：

void EchoService_Stub::Echo(RpcController* controller,
EchoRequest* request,
EchoResponse* response,
Closure* done) {
channel_->CallMethod(descriptor()->method(0),
controller,
request,
response,
done);
}

void EchoService_Stub::Add(RpcController* controller,
AddRequest* request,
AddResponse* response,
Closure* done) {
channel_->CallMethod(descriptor()->method(1),
controller,
request,
response,
done);
}
看到没，每一个函数都调用了成员变量 channel_ 的 CallMethod 方法（图中左侧的步骤2），这个成员变量的类型是 google::protobuf:RpcChannel。

从字面上理解：channel 就像一个通道，是用来解决数据传输问题的。也就是说 channel_->CallMethod 方法会把所有的数据结构序列化之后，通过网络发送给服务器。

既然 RpcChannel 是用来解决网络通信问题的，因此客户端和服务端都需要它们来提供数据的接收和发送。

图中的RpcChannelClient是客户端使用的 Channel, RpcChannelServer是服务端使用的 Channel，它俩都是继承自 protobuf 提供的 RpcChannel。

注意：这里的 RpcChannel，只是提供了网络通信的策略，至于通信的机制是什么(TCP? UDP? HTTP?)，protobuf 并不关心，这需要由 RPC 框架来决定和实现。

protobuf 提供了一个基类 RpcChannel，其中定义了CallMethod方法。我们的 RPC 框架中，客户端和服务端实现的 Channel 必须继承 protobuf 中的 RpcChannel，然后重载 CallMethod这个方法。

CallMethod 方法的几个参数特别重要，我们通过这些参数，来利用 protobuf 实现序列化、控制函数调用等操作，也就是说这些参数就是一个纽带，把我们写的代码与 protobuf 提供的功能，连接在一起。

我们这里选了libevent这个网络库来实现 TCP 通信。

四、libevent

实现 RPC 框架，需要解决 2 个问题：通信和序列化。protobuf 解决了序列化问题，那么还需要解决通信问题。

有下面几种通信方式备选：

1. TCP 通信；
2. UDP 通信；
3. HTTP 通信；

如何选择，那就是见仁见智的事情了，比如 gRPC 选择的就是 HTTP，也工作的很好，更多的实现选择的是 TCP 通信。

下面就是要决定：是从 socket 层次开始自己写？还是利用已有的一些开源网络库来实现通信？

既然标题已经是 libevent 了，那肯定选择的就是它！当然还有很多其他优秀的网络库可以利用，比如：libev, libuv 等等。

1. libevent 简介

Libevent 是一个用 C 语言编写的、轻量级、高性能、基于事件的网络库。

主要有以下几个亮点：

1. 事件驱动（ event-driven），高性能;
2. 轻量级，专注于网络；源代码相当精炼、易读；
3. 跨平台，支持 Windows、 Linux、*BSD 和 Mac Os；
4. 支持多种 I/O 多路复用技术， epoll、 poll、 dev/poll、 select 和 kqueue 等；
5. 支持 I/O，定时器和信号等事件；注册事件优先级。

从我们使用者的角度来看，libevent 库提供了以下功能：当一个文件描述符的特定事件（如可读，可写或出错）发生了，或一个定时事件发生了， libevent 就会自动执行用户注册的回调函数，来接收数据或者处理事件。

此外，libevent 还把 fd 读写、信号、DNS、定时器甚至idle（空闲） 都抽象化成了event（事件）。

总之一句话：使用很方便，功能很强大！

2. 基本使用

libevent 是基于事件的回调函数机制，因此在启动监听 socket 之前，只要设置好相应的回调函数，当有事件或者网络数据到来时，libevent 就会自动调用回调函数。

struct event_base *m_evBase = event_base_new();
struct bufferevent *m_evBufferEvent = bufferevent_socket_new(
m_evBase, [socket Id],
BEV_OPT_CLOSE_ON_FREE | BEV_OPT_THREADSAFE);
bufferevent_setcb(m_evBufferEvent,
[读取数据回调函数],
NULL,
[事件回调函数],
[回调函数传参]);

// 开始监听 socket
event_base_dispatch(m_evBase);
有一个问题需要注意：protobuf 序列化之后的数据，全部是二进制的。

libevent 只是一个网络通信的机制，如何处理接收到的二进制数据(粘包、分包的问题)，是我们需要解决的问题。

五、实现 RPC 框架

从刚才的第三部分: 自动生成的几个类EchoService, EchoService_Stub中，已经能够大概看到 RPC 框架的端倪了。这里我们再整合在一起，看一下更具体的细节部分。

1. 基本框架构思

我把图中的干扰细节全部去掉，得到下面这张图：

其中的绿色部分就是我们的 RPC 框架需要实现的部分，功能简述如下：

1. EchoService：服务端接口类，定义需要实现哪些方法；
2. EchoService_Stub: 继承自 EchoService，是客户端的本地代理；
3. RpcChannelClient: 用户处理客户端网络通信，继承自 RpcChannel；
4. RpcChannelServer: 用户处理服务端网络通信，继承自 RpcChannel；

应用程序：

1. EchoServiceImpl：服务端应用层需要实现的类，继承自 EchoService；
2. ClientApp: 客户端应用程序，调用 EchoService_Stub 中的方法；

2. 元数据的设计

在 echo_servcie.proto 文件中，我们按照 protobuf 的语法规则，定义了几个 Message，可以看作是“数据结构”：

1. Echo 方法相关的“数据结构”：EchoRequest， EchoResponse。
2. Add 方法相关的“数据结构”：AddRequest， AddResponse。

这几个数据结构是直接与业务层相关的，是我们的客户端和服务端来处理请求和响应数据的一种约定。

为了实现一个基本完善的数据 RPC 框架，我们还需要其他的一些“数据结构”来完成必要的功能，例如：

1. 消息 Id 管理；
2. 错误处理；
3. 同步调用和异步调用；
4. 超时控制；

另外，在调用函数时，请求和响应的“数据结构”是不同的数据类型。为了便于统一处理，我们把请求数据和响应数据都包装在一个统一的 RPC “数据结构”中，并用一个类型字段(type)来区分：某个 RPC 消息是请求数据，还是响应数据。

根据以上这些想法，我们设计出下面这样的元数据：

// 消息类型
enum MessageType
{
RPC_TYPE_UNKNOWN = 0;
RPC_TYPE_REQUEST = 1;
RPC_TYPE_RESPONSE = 2;
RPC_TYPE_ERROR = 3;
}

// 错误代码
enum ErrorCode
{
RPC_ERR_OK = 0;
RPC_ERR_NO_SERVICE = 1;
RPC_ERR_NO_METHOD = 2;
RPC_ERR_INVALID_REQUEST = 3;
RPC_ERR_INVALID_RESPONSE = 4
}

message RpcMessage
{
MessageType type = 1; // 消息类型
uint64 id = 2; // 消息id
string service = 3; // 服务名称
string method = 4; // 方法名称
ErrorCode error = 5; // 错误代码

bytes request = 100; // 请求数据
bytes response = 101; // 响应数据
}

注意: 这里的 request 和 response，它们的类型都是 byte。

客户端在发送数据时：

首先，构造一个 RpcMessage 变量，填入各种元数据(type, id, service, method, error);

然后，序列化客户端传入的请求对象（EchoRequest）, 得到请求数据的字节码；

再然后，把请求数据的字节码插入到 RpcMessage 中的 request 字段；

最后，把 RpcMessage 变量序列化之后，通过 TCP 发送出去。

如下图:

服务端在接收到 TCP 数据时，执行相反的操作：

首先，把接收到的 TCP 数据反序列化，得到一个 RpcMessage 变量；

然后，根据其中的 type 字段，得知这是一个调用请求，于是根据 service 和 method 字段，构造出两个类实例：EchoRequest 和 EchoResponse(利用了 C 中的原型模式)；

最后，从 RpcMessage 消息中的 request 字段反序列化，来填充 EchoRequest 实例；

这样就得到了这次调用请求的所有数据。如下图：

3. 客户端发送请求数据

这部分主要描述下图中绿色部分的内容：

Step1: 业务层客户端调用 Echo() 函数

// ip, port 是服务端网络地址
RpcChannel *rpcChannel = new RpcChannelClient(ip, port);
EchoService_Stub *serviceStub = new EchoService_Stub(rpcChannel);
serviceStub->Echo(...);
上文已经说过，EchoService_Stub 中的 Echo 方法，会调用其成员变量 channel_ 的 CallMethod 方法，因此，需要提前把实现好的 RpcChannelClient 实例，作为构造函数的参数，注册到 EchoService_Stub 中。

Step2: EchoService_Stub 调用 channel_.CallMethod() 方法

这个方法在 RpcChannelClient (继承自 protobuf 中的 RpcChannel 类)中实现，它主要的任务就是：把 EchoRequest 请求数据，包装在 RPC 元数据中，然后序列化得到二进制数据。

// 创建 RpcMessage
RpcMessage message;

// 填充元数据
message.set_type(RPC_TYPE_REQUEST);
message.set_id(1);
message.set_service("EchoService");
message.set_method("Echo");

// 序列化请求变量，填充 request 字段
// (这里的 request 变量，是客户端程序传进来的)
message.set_request(request->SerializeAsString());

// 把 RpcMessage 序列化
std::string message_str;
message.SerializeToString(