返回

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架

发布时间:2023-12-05 23:58:45 89


文章目录

  • ​​一、前言​​
  • ​​二、RPC 基础概念​​
  • ​​1. RPC 是什么?​​
  • ​​2. 需要解决什么问题?​​
  • ​​3. 有哪些开源实现?​​
  • ​​三、protobuf 基本使用​​
  • ​​1. 基本知识​​
  • ​​2. 使用步骤​​
  • ​​四、libevent​​
  • ​​1. libevent 简介​​
  • ​​2. 基本使用​​
  • ​​五、实现 RPC 框架​​
  • ​​1. 基本框架构思​​
  • ​​2. 元数据的设计​​
  • ​​3. 客户端发送请求数据​​
  • ​​4. 服务端接收请求数据​​
  • ​​5. 服务端发送响应数据​​
  • ​​6. 客户端接收响应数据​​
  • ​​六、总结​​
  • ​​1. protobuf 的核心​​
  • ​​2. 未解决的问题​​

一、前言

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

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

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

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

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

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z1ISDGmj-1619310739209)(http://iottown.sewain100.cn/iot0418_0.png)]

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

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

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

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

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

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

二、RPC 基础概念

1. RPC 是什么?

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

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

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_客户端

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

int getMotionPath(float *input, int intputLen, float *output, int outputLen)

如果计算过程不复杂,可以把这个算法函数和应用程序放在本地的同一个进程中,以源代码或库的方式提供计算服务,如下图:

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_数据_02

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

此时,调用过程如下图这样:

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_客户端_03

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

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

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

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

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

  1. 如何处理通信问题?TCP or UDP or HTTP?或者利用其他的一些已有的网络协议?
  2. 如何把数据进行打包?服务端接收到打包的数据之后,如何还原数据?
  3. 对于特定领域的问题,可以专门写一套实现来解决,但是对于通用的远程调用,怎么做到更灵活、更方便?

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

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_RPC_04

图中的绿色背景部分,就是 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 框架,例如:

  1. Google 的 gRPC;
  2. Facebook 的 thrift;
  3. 腾讯的 Tars;
  4. 百度的 BRPC;

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

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

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

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_应用程序设计_05

三、protobuf 基本使用

1. 基本知识

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

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

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

Protobuf 中最基本的数据单元是 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 个重要的类,也就是下图中绿色部分:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pDjt78iu-1619310739226)(http://iottown.sewain100.cn/iot0418_6.png)]

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:服务端程序实现接口中定义的方法,提供服务;客户端调用接口函数,调用远程的服务。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eT3DpwxR-1619310739227)(http://iottown.sewain100.cn/iot0418_7.png)]

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

(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​​。

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_RPC_06

注意:这里的​​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 语言编写的、轻量级、高性能、基于事件的网络库。

主要有以下几个亮点:

事件驱动( event-driven),高性能;
轻量级,专注于网络;源代码相当精炼、易读;
跨平台,支持 Windows、 Linux、*BSD 和 Mac Os;
支持多种 I/O 多路复用技术, epoll、 poll、 dev/poll、 select 和 kqueue 等;
支持 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. 基本框架构思

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FdJM8kIh-1619310739229)(http://iottown.sewain100.cn/iot0418_9.png)]

其中的绿色部分就是我们的 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,可以看作是“数据结构”:

Echo 方法相关的“数据结构”:EchoRequest, EchoResponse。
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 发送出去。

如下图:

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_protobuf_07

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

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

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

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

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

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_客户端_08

3. 客户端发送请求数据

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CnozKsTq-1619310739233)(http://iottown.sewain100.cn/iot0418_12.png)]

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(&message_str);

Step3: 通过 libevent 接口函数发送 TCP 数据

bufferevent_write(m_evBufferEvent, [二进制数据]);

4. 服务端接收请求数据

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-11vpkYy5-1619310739234)(http://iottown.sewain100.cn/iot0418_13.png)]

Step4: 第一次反序列化数据

RpcChannelServer 是负责处理服务端的网络数据,当它接收到 TCP 数据之后,首先进行第一次反序列化,得到 RpcMessage 变量,这样就获得了 RPC 元数据,包括:消息类型(请求RPC_TYPE_REQUEST)、消息 Id、Service 名称(“EchoServcie”)、Method 名称(“Echo”)。

RpcMessage rpcMsg;

// 第一次反序列化
rpcMsg.ParseFromString(tcpData);

// 创建请求和响应实例
auto *serviceDesc = service->GetDescriptor();
auto *methodDesc = serviceDesc->FindMethodByName(rpcMsg.method());

从请求数据中获取到请求服务的 Service 名称(serviceDesc)之后,就可以查找到服务对象 EchoService 了,因为我们也拿到了请求方法的名称(methodDesc),此时利用 C++ 中的原型模式,构造出这个方法所需要的请求对象和响应对象,如下:

// 构造 request & response 对象
auto *echoRequest = service->GetRequestPrototype(methodDesc).New();
auto *echoResponse = service->GetResponsePrototype(methodDesc).New();

构造出请求对象 echoRequest 之后,就可以用 TCP 数据中的请求字段(即: rpcMsg.request)来第二次反序列化了,此时就还原出了这次方法调用中的 参数,如下:

// 第二次反序列化:
request->ParseFromString(rpcMsg.request());

这里有一个内容需要补充一下: EchoService 服务是如何被查找到的?

在服务端可能同时运行了 很多个

一般的做法是:在服务端有一个 Service 服务对象池,当 RpcChannelServer 接收到调用请求后,到这个池子中 查找相应的 Service 对象,对于我们的示例来说,就是要查找 EchoServcie 对象,例如:

std::map m_spServiceMap;

// 在服务端启动的时候,把一个 EchoServcie 实例注册到池子中
EchoService *echoService = new EchoServiceImpl();
m_spServiceMap->insert("EchoService", echoService);

由于​​EchoService​​示例已经提前创建好,并 注册到 Service 对象池中(以 名称字符串作为关键字),因此当需要的时候,就可以通过 服务名称来查找相应的服务对象了。

Step5: 调用 EchoServiceImpl 中的 Echo() 方法

查找到​​EchoService​​​服务对象之后,就可以调用其中的 Echo() 这个方法了,但 不是直接调用,而是用一个中间函数​​CallMethod​​来进行过渡。

// 查找到 EchoService 对象
service->CallMethod(...)

在 echo_servcie.pb.cc 中,这个 CallMethod() 方法的实现为:

void EchoService::CallMethod(...)
{
switch(method->index())
{
case 0:
Echo(...);
break;

case 1:
Add(...);
break;
}
}

可以看到:protobuf 是利用固定(写死)的 索引,来定位一个 Service 服务中所有的 method 的,也就是说 顺序很重要!

Step6: 调用 EchoServiceImpl 中的 Echo 方法

​EchoServiceImpl​​​类继承自​​EchoService​​,并实现了其中的虚函数 Echo 和 Add,因此 Step5 中在调用 Echo 方法时,根据 C++ 的多态,就进入了业务层中实现的 Echo 方法。

再补充另一个知识点:我们这里的示例代码中,客户端是预先知道服务端的 IP 地址和端口号的,所以就直接建立到服务器的 TCP 连接了。
在一些分步式应用场景中,可能会有一个服务发现流程。也就是说:每一个服务都注册到“服务发现服务器”上,然后客户端在调用远程服务的之前,并不知道服务提供者在什么位置。客户端首先到服务发现服务器中查询,拿到了某个服务提供者的网络地址之后,再向该服务提供者发送远程调用请求。

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_protobuf_09

当查找到 EchoServcie 服务对象之后,就可以调用其中的指定方法了。

5. 服务端发送响应数据

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I6xFRUr7-1619310739236)(http://iottown.sewain100.cn/iot0418_15.png)]

Step7: 业务层处理完毕,回调 RpcChannelServer 中的回调对象

在上面的 Step4 中,我们通过原型模式构造了 2 个对象:请求对象(echoRequest)和响应对象(echoResponse),代码重贴一下:

// 构造 request & response 对象
auto *echoRequest = service->GetRequestPrototype(methodDesc).New();
auto *echoResponse = service->GetResponsePrototype(methodDesc).New();

构造 echoRequest 对象比较好理解,因为我们要从 TCP 二进制数据中反序列化,得到 Echo 方法的请求参数。

那么 echoResponse 这个对象为什么需要构造出来?这个对象的目的肯定是为了存放处理结果。

在 Step5 中,调用 ​​service->CallMethod(...)​​ 的时候,传递参数如下:

service->CallMethod([参数1:先不管], [参数2:先不管], echoRequest, echoResponse, respDone);

// this position

按照一般的函数调用流程,在​​CallMethod​​​中调用 Echo() 函数,业务层处理完之后,会回到上面 ​​this position​​ 这个位置。然后再把 echoResponse 响应数据序列化,最后通过 TCP 发送出去。

但是 protobuf 的设计并不是如此,这里利用了 C++ 中的闭包的可调用特性,构造了 respDone 这个变量,这个变量会一直作为参数传递到业务层的 Echo() 方法中。

这个​​respDone​​对象是这样创建出来的:

auto respDone = google::protobuf::NewCallback(this, &RpcChannelServer::onResponseDoneCB, echoResponse);

这里的​​NewCallback​​,是由 protobuf 提供的,在 protobuf 源码中,有这么一段:

template 
inline Closure* NewPermanentCallback(Class* object,
void (Class::*method)(Arg1),
Arg1 arg1) {
return new internal::MethodClosure1(object, method, false, arg1);
}


// 只贴出关键代码
class MethodClosure1 : public Closure
{
void Run() override
{
(object_->*method_)(arg1_);
}
}

因此,通过 NewCallBack 这个模板方法,就可以创建一个可调用对象 respDone,并且这个对象中保存了传入的参数:一个函数,这个函数接收的参数。

当在以后某个时候,调用 respDone 这个对象的 Run 方法时,这个方法就会调用它保存的那个函数,并且传入保存的参数。

有了这部分知识,再来看一下业务层的 Echo() 代码:

void EchoServiceImpl::Echo(protobuf::RpcController* controller,
EchoRequest* request,
EchoResponse* response,
protobuf::Closure* done)
{
response->set_message(request->message() + ", welcome!");
done->Run();
}

可以看到,在 Echo() 方法处理完毕之后,只调用了 ​​done->Run()​​​ 方法,这个方法会调用之前作为参数注册进去的 ​​RpcChannelServer::onResponseDoneCB​​​方法,并且把响应对象​​echoResponse​​作为参数传递进去。

这这里就比较好理解了,可以预见到:​​RpcChannelServer::onResponseDoneCB​​方法中一定是进行了 2 个操作:

  1. 反序列化数据;
  2. 发送 TCP 数据;

Step8: 序列化得到二进制字节码,发送 TCP 数据

首先,构造 RPC 元数据,把响应对象序列化之后,设置到 response 字段。

void RpcChannelImpl::onResponseDoneCB(Message *response)
{
// 构造外层的 RPC 元数据
RpcMessage rpcMsg;
rpcMsg.set_type(RPC_TYPE_RESPONSE);
rpcMsg.set_id([消息 Id]]);
rpcMsg.set_error(RPC_ERR_SUCCESS);

// 把响应对象序列化,设置到 response 字段。
rpcMsg.set_response(response->SerializeAsString());
}

然后,序列化数据,通过 libevent 发送 TCP 数据。

std::string message_str;
rpcMsg.SerializeToString(&message_str);
bufferevent_write(m_evBufferEvent, message_str.c_str(), message_str.size());

6. 客户端接收响应数据

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RqChlMhB-1619310739237)(http://iottown.sewain100.cn/iot0418_16.png)]

Step9: 反序列化接收到的 TCP 数据

​RpcChannelClient​​是负责客户端的网络通信,因此当它接收到 TCP 数据之后,首先进行第一次反序列化,构造出 RpcMessage 变量,其中的 response 字段就存放着服务端的函数处理结果,只不过此时它是二进制数据。

RpcMessage rpcMsg;
rpcMsg.ParseFromString(tcpData);

// 此时,rpcMsg.reponse 中存储的就是 Echo() 函数处理结果的二进制数据。

Step10: 调用业务层客户端的函数来处理 RPC 结果

那么应该把这个二进制响应数据序列化到哪一个 response 对象上呢?

在前面的主题【客户端发送请求数据】,也就是 Step1 中,业务层客户端在调用 ​​serviceStub->Echo(...)​​ 方法的时候,我没有列出传递的参数,这里把它补全:

// 定义请求对象
EchoRequest request;
request.set_message("hello, I am client");

// 定义响应对象
EchoResponse *response = new EchoResponse;


auto doneClosure = protobuf::NewCallback(
&doneEchoResponseCB,
response
);

// 第一个参数先不用关心
serviceStub->Echo(rpcController, &request, response, doneClosure);

可以看到,这里同样利用了 protobuf 提供的 NewCallback 模板方法,来创建一个可调用对象(闭包doneClosure),并且让这个闭包保存了 2 个参数:一个回调函数(doneEchoResponseCB) 和 response 对象(应该说是指针更准确)。

当回调函数 doneEchoResponseCB 被调用的时候,会自动把 response 对象作为参数传递进去。

这个可调用对象(doneClosure闭包) 和 response 对象,被作为参数 一路传递到 EchoService_Stub --> RpcChannelClient,如下图所示:

全图文分析:如何利用Google的protobuf,来思考、设计、实现自己的RPC框架_客户端_10

因此当 RpcChannelClient 接收到 RPC 远程调用结果时,就把二进制的 TCP 数据,反序列化到 response 对象上,然后再调用 doneClosure->Run() 方法,Run() 方法中执行 ​​(object_->*method_)(arg1_)​​,就调用了业务层中的回调函数,也把参数传递进去了。

业务层的回调函数 doneEchoResponseCB()

void doneEchoResponseCB(EchoResponse *response)
{
cout << "response.message = " << response->message() << endl;
delete response;
}

至此,整个 RPC 调用流程结束。

六、总结

1. protobuf 的核心

通过以上的分析,可以看出 protobuf 主要是为我们解决了序列化和反序列化的问题。

然后又通过 RpcChannel 这个类,来完成业务层的用户代码与 protobuf 代码的整合问题。

利用这两个神器,我们来实现自己的 RPC 框架,思路就非常的清晰了。

2. 未解决的问题

这篇文章仅仅是分析了利用 protobuf 工具,来实现一个 RPC 远程调用框架中的几个关键的类,以及函数的调用顺序。

按照文中的描述,可以实现出一个满足基本功能的 RPC 框架,但是还不足以在产品中使用,因为还有下面几个问题需要解决:

  1. 同步调用和异步调用问题;
  2. 并发问题(多个客户端的并发连接,同一个客户端的并发调用);
  3. 调用超时控制;

以后有机会的话,再和大家一起继续深入的讨论这些话题,祝您好运!


让知识流动起来,越分享,越幸运! 星标公众号,能更快找到我!

Hi~你好,我是道哥,一枚嵌入式开发老兵。



特别声明:以上内容(图片及文字)均为互联网收集或者用户上传发布,本站仅提供信息存储服务!如有侵权或有涉及法律问题请联系我们。
举报
评论区(0)
按点赞数排序
用户头像
精选文章
thumb 中国研究员首次曝光美国国安局顶级后门—“方程式组织”
thumb 俄乌线上战争,网络攻击弥漫着数字硝烟
thumb 从网络安全角度了解俄罗斯入侵乌克兰的相关事件时间线
下一篇
【夜读】坚持,让好事发生 2023-12-05 21:10:09