设计一个灵活的RPC架构

RPC架构

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

网络数据传输是二进制数据，涉及对象的序列化与反序列化。数据拆分协议封装。

网络传输过程中，请求数据包在数据链路层可能会因为太大而被拆分成多个数据包进行传输，为了减少被拆分的次数，从而导致整个传输时间太长，在方法调用参数或者返回值的二进制数据大于某个阈值时，可以通过压缩框架进行无损压缩，然后在另外一端用同样的压缩算法进行解压，保证数据可还原。

当一个接口有着多个服务提供者时，服务对调用方是透明的。RPC需要提供“服务发现”机制，在RPC里面维护好接口跟服务提供者地址的关系，调用方可以快速找到调用地址。

对RPC来说，每次发送请求时都需要用TCP连接，相对服务提供方IP地址，TCP连接状态是瞬息万变的，因此RPC框架里面要有连接管理器去维护TCP连接的状态。

有了集群之后，提供方需要管理好这些服务。RPC就需要内置一些服务治理的功能，比如服务提供方权重的设置、调用授权等一些常规治理手段。

可扩展架构

RPC框架设计之初不可能面面俱到，如何应对技术迭代呢？

插件化架构

RPC框架中，将每个功能点抽象成一个接口，接口作为插件的契约，功能的接口与功能的实现分离，并提供接口的默认实现。

JDK自带的SPI（Service Provider Interface）服务发现机制，可以动态地为某个接口寻找服务实现。使用SPI机制需要在Classpath下的META-INF/services目录里创建一个以服务接口命名的文件，这个文件里的内容就是这个接口的具体实现类。如下，文件名和内容都是接口和实现类全包名。

然而，JDK自带的SPI机制使用比较少，不能按需加载，ServiceLoader加载某个接口实现类的时候，会遍历全部获取，接口的实现类全部载入并实例化一遍，会造成不必要的浪费，扩展性比较差。

功能点抽象成一个接口，将接口作为插件的契约，功能的接口与功能的实现分离并提供接口的默认实现。可扩展性很好，用户可以方便地通过插件扩展实现自己的功能。无需修改核心功能本身；保持了核心包的精简，依赖外部包少。