RPC系列一、设计一个灵活的RPC框架

一、传输模块

RPC 本质上就是一个远程调用，那肯定就需要通过网络来传输数据。虽然传输协议可以有多种选择，但考虑到可靠性的话，一般默认采用 TCP 协议。为了屏蔽网络传输的复杂性，需要封装一个单独的数据传输模块用来收发二进制数据，这个单独模块可以叫做传输模块。

二、协议模块

1、序列化

用户请求的时候是基于方法调用，方法出入参数都是对象数据，对象是肯定没法直接在网络中传输的，需要提前把它转成可传输的二进制，这就是序列化过程。

2、协议封装

但只是把方法调用参数的二进制数据传输到服务提供方是不够的，需要在方法调用参数的二进制数据后面增加“断句”符号来分隔出不同的请求，在两个“断句”符号中间放的内容就是请求的二进制数据，这个过程叫做协议封装。

3、压缩

除此之外，还可以在协议模块中加入压缩功能，这是因为压缩过程也是对传输的二进制数据进行操作。在实际的网络传输过程中，请求数据包在数据链路层可能会因为太大而被拆分成多个数据包进行传输，为了减少被拆分的次数，从而导致整个传输过程时间太长的问题，可以在 RPC 调用的时候这样操作：在方法调用参数或者返回值的二进制数据大于某个阈值的情况下，可以通过压缩框架进行无损压缩，然后在另外一端也用同样的压缩算法进行解压，保证数据可还原。

三、服务发现

针对同一个接口有着多个服务提供者，但这多个服务提供者对于调用方来说是透明的，所以在 RPC 里面还需要给调用方找到所有的服务提供方，并需要在 RPC 里面维护好接口跟服务提供者地址的关系，这样调用方在发起请求的时候才能快速地找到对应的接收地址，这就是常说的“服务发现”。

四、连接管理器

但服务发现只是解决了接口和服务提供方地址映射关系的查找问题，这更多是一种“静态数据”。说它是静态数据是因为，对于RPC 来说，每次发送请求的时候都是需要用 TCP 连接的，相对服务提供方 IP 地址，TCP 连接状态是瞬息万变的，所以 RPC 框架里面要有连接管理器去维护 TCP 连接的状态。

五、服务治理

有了集群之后，提供方可能就需要管理好这些服务了，那 RPC 就需要内置一些服务治理的功能，比如服务提供方权重的设置、调用授权等一些常规治理手段。而服务调用方需要额外做哪些事情呢？每次调用前，都需要根据服务提供方设置的规则，从集群中选择可用的连接用于发送请求。

六、小结

那到这儿，一个比较完善的 RPC 框架基本就完成了，功能也差不多就是这些了。按照分层设计的原则，将这些功能模块分为了四层，具体内容见图示：

 七、可扩展的架构

不知道你有没有这样的经历，你设计的一个系统它看上去很完善，也能很好地运行，然后成功地把它交付给了业务方。有一天业务方有了新的需求，要加入很多新的功能，这时候你就会发现当前架构面临的可就是大挑战了，要修改很多地方才能实现。

其实，设计 RPC 框架不可能在开始时就面面俱到。那有没有更好的方式来解决这些问题呢？这就是我们接下来要讲的插件化架构。

 

这时，整个架构就变成了一个微内核架构，将每个功能点抽象成一个接口，将这个接口作为插件的契约，然后把这个功能的接口与功能的实现分离并提供接口的默认实现。这样的架构相比之前的架构，有很多优势。首先它的可扩展性很好，实现了开闭原则，用户可以非常方便地通过插件扩展实现自己的功能，而且不需要修改核心功能的本身；其次就是保持了核心包的精简，依赖外部包少，这样可以有效减少开发人员引入 RPC 导致的包版本冲突问题。