中间件复习之-RPC框架

什么是RPC框架？

RPC(Remote Procedure Call):远程过程调用。当多个应用部署在多个服务器上时，由于他们不在一个内存空间上，因此需要网络来进行通信，而RPC允许它像调用本地方法一样调用远程服务。

RPC原理

服务消费方通过RPC客户端调用服务，服务接收方通过RPC服务端接收请求进行处理。
整体分四个模块：

远程代理
序列化
网络传输
反序列化

RPC核心功能实现

RPC服务消费方

连接管理
负载均衡
请求路由
超时处理
健康检查

连接管理

消费方需要保持与服务方的长链接，用于传输请求也用于返回结果。那该如何实现呢？
下面是连接管理在整个服务消费调用过程中的位置：
在这里插入图片描述

连接管理核心有以下3个需要思考的点：

连接初始化的时机：灵活根据业务场景选择策略
- 懒加载：服务刚启动的时候不初始化，等有请求调用时再初始化连接。建好后再次有请求就复用这个连接。（网关场景一般使用懒加载。因为网关业务是公司所有流量的入口，下游服务可能有n个服务*n个节点。一个网关服务启动后，如果要等全部连接建立完毕之后启动会很慢，并且如果有模块没什么流量还占用着连接会有资源的浪费。一般网关服务上线后先分配少点的流量然后再预热，预热完后开放。）
- 预加载：模块启动后先不接流量，把所有的连接、socket全部建好了然后再提供服务。（一般普通应用服务都是这种模式）
连接数的维护：多建几条连接防止单条连接失效。
心跳/重连：多条连接有探活机制，保证有多条连接可用。

负载均衡

负载均衡功能是确保多个服务提供方节点流量均匀/合理，支持节点扩容与灰度发布。
负载均衡在消费方rpc调用的位置：
在这里插入图片描述
负载均衡的一些方式：轮询、随机、取模、带权重、一致性Hash

请求路由

当业务方想按照某些请求标签来确定是不是要走该节点时，可以使用请求路由。通过一系列规则过滤出可以选择的服务提供方节点列表，在应用隔离,读写分离,灰度发布中都发挥作用。
请求路由在消费方调用过程中的位置：
在这里插入图片描述
请求路由功能的设计：

规则匹配：
- 待比较的属性(IP/流量标签)
- 运算符(等于、大于、不等于等等)
- 属性匹配值（跟哪个值进行匹配）
- 匹配完的结果（行为）
数据结构设计：因为是一系列规则，所以可以是链表结构

如按照IP分流规则举例：attribute=IP，operator=IN，value=IP1，IP2，Servers：Node1，Node2

超时处理

消费端对于长时间没有返回的请求，需要作出异常处理，及时释放资源。
超时处理在RPC调用链路中的位置：
在这里插入图片描述
超时处理的核心逻辑：

工作线程的阻塞位置
- 等待服务端回包通知（接收到请求了，判断是否超时）如下图：
超时逻辑
- 工作线程等待回包通知
- 如果数据在预期的时间内返回，则终止等待唤醒工作线程
- 如果超时则抛出异常
超时处理的核心数据结构
- Map：SessionID（请求级唯一）-WindowData（内部包含Event）

RPC服务提供方

队列/线程池
超时丢弃
优雅关闭
过载保护

队列/线程池

服务提供方可以将不同类型的请求，放入各自的队列，每个队列分配独立的线程池，做到资源隔离。
队列/线程池在服务提供方处理逻辑中的位置：
在这里插入图片描述
队列数/线程数的选择可以按照实际压测后的情况去调整。

超时丢弃

超时丢弃主要是将已经超时（超时的定义主要是调用方配置的超时时间）的请求快速失败，缓解队列堆积，防止服务持续不可用。
超时丢弃在服务提供方处理逻辑中的位置：
在这里插入图片描述
超时丢弃的处理逻辑：

io任务入队，任务包含3个字段，第一个是超时时间，第二个是处理请求的handler处理器，第三个是入队时间。
下面是出队以及判定超时的逻辑：