RPC 框架

这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天

3 关键指标

3.1 稳定性 — 保障策略

• 熔断：保护调用方，防止被调用的服务出现问题而影响到整个链路

  一个服务A调用服务B时，服务B的业务逻辑又调用了服务C，而这时服务C响应超时了，由于服务B依赖服务C，C超时直接导致B的业务逻辑一直等待，而这个时候服务A继续频繁地调用服务B，服务B就可能会因为堆积大量的请求而导致服务宕机，由此就导致了服务雪崩的问题。

• 限流：保护被调用方，防止大流量把服务压垮

  当调用端发送请求过来时，服务端在执行业务逻辑之前先执行检查限流逻辑，如果发现访问量过大并且超出了限流条件，就让服务端直接降级处理或者返回给调用方一个限流异常

• 超时控制：避免浪费资源在不可用节点上

  当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，避免浪费资源

3.2 稳定性 — 请求成功率

注意，因为重试有放大故障的风险，首先，重试会加大直接下游的负载。如下图，假设A服务调用B服务，重试次数设置为r（包括首次请求），当B高负载时很可能调用不成功，这时A调用失败重试 B，B服务的被调用量快速增大，最坏情况下可能放大到r倍，不仅不能请求成功，还可能导致 B的负载继续升高，甚至直接打挂。防止重试风暴，限制单点重试和限制链路重试

3.3 稳定性 — 长尾请求

长尾请求一般是指明显高于均值的那部分占比较小的请求。 业界关于延迟有一个常用的P99标准，P99 单个请求响应耗时从小到大排列，顺序处于99%位置的值即为P99 值， 那后面这1%就可以认为是长尾请求。 在较复杂的系统中，长尾延时总是会存在。 造成这个的原因非常多，常见的有网络抖动，GC， 系统调度。 我们预先设定一个阈值 t3（比超时时间小， 通常建议是RPC 请求延时的 pct99），当 Req1 发出去后超过 t3 时间都没有返回， 那我们直接发起重试请求 Req2， 这样相当于同时有两个请求运行。 然后等待请求返回，只要Resp1或者Resp2 任意一个返回成功的结果，就可以立即结束这次请求， 这样整体的耗时就是 t4， 它表示从第一个请求发出到第一个成功结果返回之间的时间，相比于等待超时后再发出请求， 这种机制能大大减少整体延时。

3.4 稳定性 — 注册中间件

3.5 易用性

• 开箱即用

• 合理的默认参数选项、丰富的文档

• 周边工具

  生成代码工具、脚手架工具

3.6 拓展性

• Middleware
• Option
• 编解码层
• 协议层
• 网络传输层
• 代码生成工具插件扩展

3.7 高性能

场景

• 单机多机
• 单连接多连接
• 单/多client单/多server
• 不同大小的请求包
• 不同请求类型：例如pingpong、streaming等

目标

• 高吞吐
• 低延迟

手段

• 连接池
• 多路复用
• 高性能编解码协议
• 高性能网络库