微服务场景下类 TCP 拥塞控制的自适应限流方案可行性讨论？

[fudali113]

类 TCP 拥塞控制的普适性自适应限流方案可行性讨论？

正如 https://github.com/alibaba/Sentinel/issues/1641 中那位兄弟说的一样，在微服务场景，服务多，拓扑复杂，且处理能力不总是稳定；这时候如果使用固定的限流规则会有以下难题：

1. 确定接口和服务的固定配置需要压测工作量(如果你服务接口多，那工作量不可小觑)，同时需要将压测融入到你的开发流程中;
2. 服务处理能力不总是稳定的，不同的服务可能对于同一个资源(比如数据库)有依赖且两者都是使用资源，此时这两个服务实际的处理能力可能是跟我们测试得到的固定值都是有差异的；

所以我也希望找到一种自适应的方式来实现限流，不过我思考的灵感是来自于 TCP 拥塞控制； 基于自适应限流的场景，我认为其实跟 TCP 拥塞控制是非常相似的，同样的对于处理能力未知，同样需要从未知的处理能力中尽可能的提高资源利用率，也同样处理能力不总是稳定(对于某一端)；既然他们有这么多的相似之处，且 TCP 能够利用堵塞控制算法很好的进行工作，那么我相信微服务自适应限流场景下也是可以的。

类 tcp reno 的自适应限流方案

假设我们使用 qps 来作为我们限流的标准；

慢启动

类似于目前 sentinel 提供的冷启动功能，在该阶段需要快速的提高 qps 限制值；这阶段应该可以配置一个范围[min, max]，min 避免最开始从 1 开始导致启动时拒绝大量请求，max 对应 tcp reno 中的慢启动阈值(min和max跟着大致感觉设置就好)；

拥塞避免

缓慢的增长，例如上一个时间窗口全部正确返回，那么我就将 qps + ${某个固定值}，亦或是基于当前 qps 的某种计算方式。

拥塞发送

是否可以自适应获取超时阈值？最小处理时间 + 一定的处理容忍时间(也可以是最小处理时间百分比)

发生了错误或者发生了超时，说明我们当前的 qps 值与下游服务当前能够提供的 qps 不匹配，此时我们应该根据时间窗口内(超时或者错误)的总量以及请求的总量进行一些处理；比如:

• 超时或者错误在我们上次增加的 qps 左右，且此时 qps 总量不跟增加的 qps 在一个数量级，这种情况应该是我们不应该再增加 qps 的信号（类似快速恢复？但是我想的是这里他不应该大幅度下降）
• 如果出现了较大规模(比如30%-10%)或者大规模(比如30%-100%)的超时或者错误，很有可能此时有其他服务在跟我们进行资源竞争(不然以我们的缓慢增长的qps，大规模的超时应该由小规模的超时引起，但根据我们的处理逻辑，小规模的超时发生时我们就会停止增长，不应该会引起大规模的超时；但如果请求处理需要的时间较长，可能我们需要较大我们的时间窗口)；那么此时我们可以根据百分比进行一定的使 qps 的下降逻辑；如果想最大化请求量，按错误百分比较少，由于都是根据返回配置限流，你需要你下游的服务不会被你的请求带崩(sentinel 的入口流量 cpuLoad自适应限流或者 cpuUsage 限流是个好选择)；如果你想保命要紧，那么这里可以直接熔断；

类 tcp bbr 的自适应限流方案

To be continued...

欢迎大家重锤我的观点😆😆😆