利用protobuf实现RPC框架之RPC简介

一、前言

今天聊一聊 RPC 的相关内容，来看一下如何利用 Google 的开源序列化工具protobuf，来实现一个我们自己的 RPC 框架。文章比较长，但是值得想了解RPC的小伙伴阅读参考。整个系列内容分为四个部分：

• RPC介绍
• protobuf 基本使用
• 网络通信框架libevent介绍
• 实现 RPC 框架

二、RPC 基础概念

1. RPC 是什么？

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

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

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

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

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

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

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

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

初步接触 RPC 的朋友可能会提出：
那我可以在应用程序中把算法需要的输入数据打包好，通过网络发送给算法服务器;服务器计算出结果后，再打包好返回给应用程序就可以了。
这句话说的非常对，从功能上来说，这个描述过程就是RPC 所需要做的所有事情。

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

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

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

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

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

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

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

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

服务器端利用这个库，在网络上提供函数调用服务; 客户端利用这个库，远程调用位于服务器上的函数;

2. 需要解决什么问题？

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

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

3. 有哪些开源实现？

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

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

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

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

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

gRPC 就是利用了 protobuf，来实现了一个完整的 RPC 远程调用框架，其中的通讯部分，使用的是http协议。如下图所示：

小结

本篇文章对RPC框架做了一个简单的介绍，下一篇文章我们将介绍著名的网络库libevent是如何实现数据通信的。

原文链接