网易数帆改造dpvs之基于vs级别的qos

背景

DPVS 原生的 QoS 是一个独立的模块（TC），和 ipvs 负载均衡的功能没有任何联系，需要单独配置报文匹配规则（qos classify）、带宽限速参数和算法（qos sched）。这倒还不是问题的关键，问题的关键在于 DPVS 原生 QoS cls 在数据面进行保文规则匹配时，效率非常低下：它是一条一条规则进行顺序比较，直到完全匹配到规则，就用匹配规则里设置的对应配置对报文进行 QoS schedule 操作。而且由于匹配效率低下，也设置了最大 reclassify 的值，进行 8 次比较还没完全匹配上的话，就直接 drop 这个包了。所以对于新四层负载均衡的 vip 级别的限速需求，由于匹配规则条目非常多，规则匹配效率很低下，非常影响性能，是不能满足 vip 级别的众多 VIP 时的限速需求的。

需求

功能需求

需要自己重新开发了一套适合网易数帆云计算业务的 VIP 级的 QoS 服务，提供：

• VIP 级别的 inbound、outbond 两个方向的 bps 限速；
• VIP 级别的 inbound、outbond 两个方向的 pps 限速；
• VIP 级别的新建连接限速cps；
• VIP 级别的最大并发连接数限制max_conn；

VIP QoS 服务是嵌入进 ipvs 负载均衡处理流程的，每种限速都独立;

性能需求

单机最大限速误差控制在5%左右；

限速对于单机性能影响控制在5%以内；

难点

VIP 级别 QoS 服务开发中的最大难点就在于

1）QoS 多核处理:

如果是单纯的单核 qos 限速，其实普通令牌桶限速算法就已经足够。但由于 VIP 级别 QoS 的每个 VIP 中的各连接流量是在多核上同时运行的，所有业务流量的每个包都进行限速操作，对令牌桶操作的 cache 一致性或者加锁都将严重消耗 cpu 性能，多核大流量下性能惨不忍睹。

2）平滑丢包，而非集中丢包

基于以上令牌桶算法的缺点，因此又开发了增量限速算法，此算法比较简单粗暴，但破除了令牌桶的多核限制，使其性能损耗大大降低，达到了业务的需求。但是此算法精确度差得有点多，并且其原理决定了要丢包时就会一个时间计算间隔的后段集中丢包，对业务连接的损伤比较大，所以使用一段时间后效果也不是很好，只能达到勉强可用的程度。

解决方法

基于以上增量限速算法的缺点，因此最终开发了带 cache 的令牌桶限速算法，稍微牺牲了一点点精确度，但是带来了性能损耗的大幅降低，且比增量限速算法还是精确度高不少，同时其原理的实时计算决定了对业务丢包的友好，不会存在一个时间计算间隔的后段集中丢包的缺点，终于解决了 VIP 级别 QoS 服务多核处理的难题。

参考

https://cloud.tencent.com/developer/news/726716