这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
课程概要
- RPC 相关的基本概念
- RPC 框架的分层设计
- 衡量 RPC 框架的一些核心指标
- 字节内部 RPC 框架 Kitex 实践分享
关键指标
稳定性
保障策略
-
熔断:
一个服务 A调用服务 B 时，服务 B 的业务又调用了服务C ，而这时服务C 响应超时了，由于服务 B 依赖服务 C, C 超时直接导致 B 的业务逻辑一直等持，而这个时候服务 A 继续频察地调用服务 B，服务 B 就可能会因为堆积大量的请求而导致服务宕机，由此就导致了服务雪崩的问题
-
限流: 当调用端发送请求过来时，服务端在执行业务逻援之前先执行检查限流逻辑，如果发现访问量过大并且超出了限流条件，就让服务端直接降级处理或者返回给调用方一个限流异常
-
超时: 当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不大重要的业务，释放出服务器资源，避免浪费资源
请求成功率
面对失败的请求，通过均衡负载进行重试，但重试有放大故障的风险：
重试会加大直接下游的负载，假设 A 服务调用 B 服务，重试次数设置为r(包括首次请求)，当B负载高的时很可能调用不成功，这时A调用失败重试B，B 服务的被调用量快速增大，最坏情况下可能放大到r倍，不仅不能清求成功，还可能导致 B 的负裁继续升高，甚至直接打挂。
为了防止重试风暴，限制单点重试和限制链路重试
长尾请求
- 长尾请求一般是明显高于均值的部分占比小的请求，业界关于过因有一个常用的P99标准，P99 单个请未响应耗时从小到大排列，顺序处于99%位置的值即为P9 值，那后面这 1%就可以为是长尾请求，在较复杂的系统中，长尾延时总是会存在。造成这个的原因非常多，常见的有网络抖动，GC，系统调度。
- 我们预先设定一个阈值t3（比超时时间小，通常建议是 RPC 请求延时的 pct99)当 Req1 发出去后超过 t3 都没有回，那我们直接发起重试请求 Req2，这样相当同时有两个请求在运行，然后等待请求返回，只要 Resp1或 Resp2 任意一个返回成功的结果，就可以立即结束这次清求，这样整体的转耗时就是 t4，它表示从第一个请求发出到第一个成功结果返回之间的时间，相比于等待超时后再发出请求，这种机制能大大减少整体延时。
注册中间件
Kitex Client和 Server 的创建接口均采用 Option 模式，提供了极大的灵活性，很方便就能注入这些稳定性策略
易用性
- 开箱即用：合理的默认参数选项，丰富的文档
- 周边工具：生成代码工具，脚手架工具
扩展性
提供丰富的扩展点，比如核心的传输层和协议层
- Middleware
- Option
- 编解码层
- 协议层
- 网络传输层
- 代码生成工具插件拓展
观测性
除了传统的Log、Metric和Tracing之外，内置状态暴露服务也很有必要
高性能
性能可以从多个层面去优化，例如选择高性能的编解码协议和网络库
分两个维度，高性能意味着高吞吐和低延迟，两者都很重要，甚至大部分场景下低延迟更重要.
- 多路复用可以大大减少了连接带来的资源消耗，并且提升了服务端性能，服务端吞吐可提升30%
- 调用端向服务端的一个节点发送请求，并发场景下，如果是非连接多路复用，每个请求都会持有一个连接，直到清大结束连接才会波关闭或者放连接池复用，并发量与连接数是对等的关系 而使用连接多路复用，所有请求都可以在一个连接上完成，可以明显看到连接资源利用上的差异
