概念篇
RPC 是什么？
RPC 称远程过程调用（Remote Procedure Call），用于解决分布式系统中服务之间的调用问题。通俗地讲，就是开发者能够像调用本地方法一样调用远程的服务。所以，RPC的作用主要体现在这两个方面：
- 屏蔽远程调用跟本地调用的区别，让我们感觉就是调用项目内的方法；
- 隐藏底层网络通信的复杂性，让我们更专注于业务逻辑。
RPC 框架基本架构
下面我们通过一幅图来说说 RPC 框架的基本架构
RPC 框架包含三个最重要的组件，分别是客户端、服务端和注册中心。在一次 RPC 调用流程中，这三个组件是这样交互的：
- 服务端在启动后，会将它提供的服务列表发布到注册中心，客户端向注册中心订阅服务地址；
- 客户端会通过本地代理模块 Proxy 调用服务端，Proxy 模块收到负责将方法、参数等数据转化成网络字节流；
- 客户端从服务列表中选取其中一个的服务地址，并将数据通过网络发送给服务端；
- 服务端接收到数据后进行解码，得到请求信息；
- 服务端根据解码后的请求信息调用对应的服务，然后将调用结果返回给客户端。
RPC 框架通信流程以及涉及到的角色
从上面这张图中，可以看见 RPC 框架一般有这些组件：服务治理(注册发现)、负载均衡、容错、序列化/反序列化、编解码、网络传输、线程池、动态代理等角色，当然有的RPC框架还会有连接池、日志、安全等角色。
具体调用过程
- 服务消费方(client)以本地调用方式调用服务
- client stub 接收到调用后负责将方法、参数等封装成能够进行网络传输的消息体
- client stub 将消息进行编码并发送到服务端
- server stub 收到消息后进行解码
- server stub 根据解码结果调用本地的服务
- 本地服务执行并将结果返回给 server stub
- server stub 将返回导入结果进行编码并发送至消费方
- client stub 接收到消息并进行解码
- 服务消费方(client)得到结果
RPC 消息协议
RPC调用过程中需要将参数编组为消息进行发送，接收方需要解组消息为参数，过程处理结果同样需要经编组、解组。消息由哪些部分构成及消息的表示形式就构成了消息协议。
RPC调用过程中采用的消息协议称为RPC消息协议。
实战篇
从上面的概念我们知道一个RPC框架大概有哪些部分组成，所以在设计一个RPC框架也需要从这些组成部分考虑。从RPC的定义中可以知道，RPC框架需要屏蔽底层细节，让用户感觉调用远程服务像调用本地方法一样简单，所以需要考虑这些问题：
- 用户使用我们的RPC框架时如何尽量少的配置
- 如何将服务注册到ZK(这里注册中心选择ZK)上并且让用户无感知
- 如何调用透明(尽量用户无感知)的调用服务提供者
- 启用多个服务提供者如何做到动态负载均衡
- 框架如何做到能让用户自定义扩展组件(比如扩展自定义负载均衡策略)
- 如何定义消息协议，以及编解码
- ...等等
上面这些问题在设计这个RPC框架中都会给予解决。
技术选型
- 注册中心 目前成熟的注册中心有Zookeeper，Nacos，Consul，Eureka，这里使用ZK作为注册中心，没有提供切换以及用户自定义注册中心的功能。
- IO通信框架 本实现采用 Netty 作为底层通信框架，因为Netty 是一个高性能事件驱动型的非阻塞的IO(NIO)框架，没有提供别的实现，也不支持用户自定义通信框架
- 消息协议 本实现使用自定义消息协议，后面会具体说明
项目总体结构
从这个结构中可以知道，以rpc命名开头的是rpc框架的模块，也是本项目RPC框架的内容，而consumer是服务消费者，provider是服务提供者，provider-api是暴露的服务API。
整体依赖情况
项目实现介绍
要做到用户使用我们的RPC框架时尽量少的配置，所以把rpc框架设计成一个starter，用户只要依赖这个starter,基本那就可以了。
为什么要设计成两个 starter (client-starter/server-starter) ?
这个是为了更好的体现出客户端和服务端的概念，消费者依赖客户端，服务提供者依赖服务端，还有就是最小化依赖。
为什么要设计成 starter ?
基于spring boot自动装配机制，会加载starter中的 spring.factories 文件，在文件中配置以下代码，这里我们starter的配置类就生效了，在配置类里面配置一些需要的bean。
org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.rrtv.rpc.client.config.RpcClientAutoConfiguration
发布服务和消费服务
- 对于发布服务
服务提供者需要在暴露的服务上增加注解 @RpcService，这个自定义注解是基于 @service 的，是一个复合注解，具备@service注解的功能，在@RpcService注解中指明服务接口和服务版本，发布服务到ZK上，会根据这个两个元数据注册
- 发布服务原理：
服务提供者启动之后，根据spring boot自动装配机制，server-starter的配置类就生效了，在一个 bean 的后置处理器（RpcServerProvider）中获取被注解 @RpcService 修饰的bean，将注解的元数据注册到ZK上。
- 对于消费服务
消费服务需要使用自定义的 @RpcAutowired 注解标识，是一个复合注解，基于 @Autowired。
- 消费服务原理
要让客户端无感知的调用服务提供者，就需要使用动态代理，如上面所示， HelloWordService 没有实现类，需要给它赋值代理类，在代理类中发起请求调用。
基于spring boot自动装配，服务消费者启动，bean 后置处理器 RpcClientProcessor 开始工作，它主要是遍历所有的bean，判断每个bean中的属性是否有被 @RpcAutowired 注解修饰，有的话把该属性动态赋值代理类，这个再调用时会调用代理类的 invoke 方法。
代理类 invoke 方法通过服务发现获取服务端元数据，封装请求，通过netty发起调用。
注册中心
本项目注册中心使用ZK，由于注册中心被服务消费者和服务提供者都使用。所以把ZK放在rpc-core模块。
rpc-core 这个模块如上图所示，核心功能都在这个模块。服务注册在 register 包下。
服务注册接口，具体实现使用ZK实现。
负载均衡策略
负载均衡定义在rpc-core中，目前支持轮询（FullRoundBalance）和随机（RandomBalance），默认使用随机策略。由rpc-client-spring-boot-starter指定。
通过ZK服务发现时会找到多个实例，然后通过负载均衡策略获取其中一个实例
可以在消费者中配置 rpc.client.balance=fullRoundBalance 替换，也可以自定义负载均衡策略，通过实现接口 LoadBalance，并将创建的类加入IOC容器即可。由于我们配置 @ConditionalOnMissingBean，所以会优先加载用户自定义的 bean。
自定义消息协议、编解码
所谓协议，就是通信双方事先商量好规则，服务端知道发送过来的数据将如何解析。
- 自定义消息协议
- 魔数：魔数是通信双方协商的一个暗号，通常采用固定的几个字节表示。魔数的作用是防止任何人随便向服务器的端口上发送数据。例如 java Class 文件开头就存储了魔数 0xCAFEBABE，在加载 Class 文件时首先会验证魔数的正确性
- 协议版本号：随着业务需求的变化，协议可能需要对结构或字段进行改动，不同版本的协议对应的解析方法也是不同的。
- 序列化算法：序列化算法字段表示数据发送方应该采用何种方法将请求的对象转化为二进制，以及如何再将二进制转化为对象，如 JSON、Hessian、Java 自带序列化等。
- 报文类型：在不同的业务场景中，报文可能存在不同的类型。RPC 框架中有请求、响应、心跳等类型的报文。
- 状态：状态字段用于标识请求是否正常（SUCCESS、FAIL）。
- 消息ID：请求唯一ID，通过这个请求ID将响应关联起来，也可以通过请求ID做链路追踪。
- 数据长度：标明数据的长度，用于判断是否是一个完整的数据包
- 数据内容：请求体内容
编解码
编解码实现在 rpc-core 模块，在包 com.rrtv.rpc.core.codec下。
自定义编码器通过继承 netty 的 MessageToByteEncoder
如果您对该产品感兴趣，请填写办理（客服微信：xiaoxiongyidong）
发表评论
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。