总纲

上一章我们已经讲解了为什么我们需要RPC这项技术。如下如所示，RPC（Remote Procedure Call Protocol，远程过程调用协议）的功能是在两个服务器之间进行通信和服务（方法）调用的。那么本节我们就来分析一下一个RPC框架需要哪些部分和功能。

分析一下RPC调用的整体流程

如下图所示。
– 调用方（Caller）需要知道什么？首先服务调用方（caller）需要确定自己需要调用的服务是什么，然后确定调用的服务需要什么参数、返回值是什么。
– 服务方（Callee）需要知道什么？服务方需要知道自己需要提供什么服务，自己需要哪些参数，返回值是什么。
– 中间的部分——RPC需要知道什么？中间的部分需要将调用方的参数进行打包然后寻找所要调用的方法在哪个服务器，确认后发给相应的服务器，在发送到对应的服务器上之后，我们需要对参数进行拆包，然后调用对应的方法，将返回值进行打包并发送回调用方所在的服务器。调用方收到打包后的结果之后进行拆包返回结果。

通过上面的讲解，你应该清楚了RPC框架所要完成的工作就是三方面：
– 对参数和返回值的打包和拆包。—— Protobuf
– 将打包后的内容通过网络进行发送。 —— Muduo
– 确定所要调用的方法在哪台服务器上。—— Zookeeper

Protocol Buffer

Google Protocol Buffer( 简称 Protobuf) 是 Google 公司内部的混合语言数据标准，目前已经正在使用的有超过 48,162 种报文格式定义和超过 12,183 个 .proto 文件。他们用于 RPC 系统和持续数据存储系统。
Protocol Buffers 是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化、或者说序列化。它很适合做数据存储或RPC数据交换格式。可以用于即时通讯、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式
Google的Protobuf了，相比于它的前辈xml、json，它的体量更小，解析速度更快，所以在 IM 这种通信应用中，非常适合将 Protobuf 作为数据传输格式。
protobuf的核心内容包括：
定义消息：消息的结构体，以message标识。
定义接口：接口路径和参数，以service标识。
通过protobuf提供的机制，服务端与服务端之间只需要关注接口方法名（service）和参数（message）即可通信，而不需关注繁琐的链路协议和字段解析，极大降低了服务端的设计开发成本。
关于protobuf的使用，我会专门写一篇文章来介绍。

Muduo

我们使用muduo网络库来进行数据的网络发送，muduo网络库是一个高性能的c++网络库（只在Linux下）。关于muduo网络库的使用我会专门写一篇文章来介绍。

Zookeeper

Zookeeper扫盲
Zookeeper是在分布式环境中应用非常广泛，它的优秀功能很多，比如分布式环境中全局命名服务，服务注册中心，全局分布式锁等等。
在本项目中，zookeeper提供服务注册的功能：因为rpc调用的服务可能分布在不同的服务器上，我们需要知道所要调用的服务在哪个服务器上，zookeeper可以将每台服务器上的服务进行注册记录，当调用发生时找到对应的服务器去调用相应方法。

以上就是本文的全部内容了，之后的两篇会专门讲一下protobuf的简单使用，和muduo库的使用，之后再从用户使用方（Caller）和服务提供方（Callee）两者使用的角度来分析一下rpc框架需要哪些细节功能和实现。