Envoy Adaptive-Concurrency Filter浅解

简介: 1. Why在通常情况下,我们希望服务在超出负载能力时能主动拒绝掉超额的请求,从而防止服务被击垮。达到这一目的传统手段是使用熔断能力,通过服务网格的DestinationRule可以配置基础的熔断能力,但这要求用户必须给出一个触发熔断的阈值,例如给出具体的pending requests数量,服务网格数据平面将在网络访问超出熔断配置时拒绝请求。这种做法对运维人员提出了要求:必须事先知道或估算出服务

1. Why

在通常情况下,我们希望服务在超出负载能力时能主动拒绝掉超额的请求,从而防止服务被击垮。达到这一目的传统手段是使用熔断能力,通过服务网格的DestinationRule可以配置基础的熔断能力,但这要求用户必须给出一个触发熔断的阈值,例如给出具体的pending requests数量,服务网格数据平面将在网络访问超出熔断配置时拒绝请求。这种做法对运维人员提出了要求:必须事先知道或估算出服务的负载能力,依此来做出熔断配置,但是在很多时候,想准确地估算服务的承受能力(特别是对于非开发者的运维人员来说)是较为困难的,这通常需要运维人员基于生产环境的运行状况进行多轮配置优化才能最终得到一个合理的设置,而一旦开发人员对组件进行了升级或变更,则之前测得的结果可能就立刻不作数了。为了解决这个问题,在一些语言框架中不乏有已经广为人知的方案,例如Netflix开源的concurrency-limits

2. What

作为时下云原生的明星项目--Envoy则通过Adaptive-Concurrency Filter提供了自适应并发限制能力, 其在运行期间会不断地对当前并发限制值之下的服务响应时间进行采样,同时定期将并发限制值缩小到一个较低值,再进行理想响应时间采样,然后再对二者进行对比得到当前并发限制设定下的实际响应时间与理想响应时间的差距,便可以通过该差值经一定算法判定出当前并发值是是否超过了服务的负载能力,超过了多少,进而动态地对并发限制进行调整,尽可能使得并发限制数量在服务可承受的范围附近,同时拒绝超出该限制的请求(返回HTTP 503及错误信息reached concurrency limit),实现保护服务的作用。

Envoy作为服务网格的Sidecar/网关时,则使得任意语言编写的应用在无需修改任何代码的情况下,就可以获得自适应并发限制的能力,极大地降低了运维工作的负担。

3. How

3.1 负载测定

接下来我们看看Adaptive-Concurrency Filter的算法,一窥其如何计算并发限制的核心机制。为了动态地计算并发值,我们在前文中提到,需要不停地测定实际延迟和理想延迟,并对二者做对比,为了表述方便,我们分别将其称为sampleRTT和minRTT,sampleRTT偏离minRTT越多,则说明服务超载越严重,我们可以用二者的比值来量化地反映这一程度,我们将其称为gradient(梯度或倾斜度),也即gradient越大,服务超载越严重,注意,sampleRTT比minRTT的比值只有大于1时表明服务超出负载,然而小于1时并不能理解为服务很空闲,这是因为minRTT已经是最小延迟了,如果测得的延迟比最小延迟还小,那只能说明是网络的正常波动导致,而不是服务负载变化导致。(除非测得的minRTT是不可信的,例如minRTT采样期间的并发值配置的太大,以至于超出了服务的负载)。为了容忍一定范围内的网络波动,我们在计算gradient时为sampleRTT加上一个小小的阈值,这个阈值应当是与合理地网络延迟波动范围相近的,这样一来,我们就可以尽量避免sampleRTT比minRTT<1的情况,我们称该值为B。这样一来我们就得到了如下公式:

基于gradient,我们便可以大致得到一个服务的超载情况了,如果gradient ≈ 1,则表明应用还尚未达到瓶颈,可以增加负载,直到计算出来的gradient大于1,我们再降低负载,如此往复,施加给应用的压力将始终被控制在瓶颈附近。

3.2 负载放大

如果测定的负载表明服务当前仍有余量,那么我们便需要对应用加压,也即放大并发限制,使其尽可能发挥性能。我们对这个增量值取名为headroom,headroom的计算Envoy使用了如下算法(limit(old)表示上一次计算得出的限制值):

最终再将L + headroom得出新的并发限制

4. Result

在启用AdaptiveConcurrency的集群中进行测试,对应用施加远超其负载的压力。查看Dashboard,可以看到,ConcurrencyLimit被限制在400 - 600之间浮动,这说明应用的负载能力在400-600之间,RqBlocked面板展示了被拒绝的请求数量,曲线持续增长,符合我们的预期。

5. Summary

通过以上内容,本文粗浅地解析了Envoy中Adaptive-Concurrency Filter的原理,疏漏不周之处还望各位不吝指教。自适应限流极大地降低了运维负担,增加了运维信心,在很多场景下都是相当值得选用的方案。但由于Envoy的最主要使用场景Istio尚不支持对AdaptiveConcurrency进行配置,而通过Istio EnvoyFilter API自行配置EnovyFIlter又相对较为复杂,阿里云服务网格ASM提供了ASMAdaptiveConcurrency API,可以使得用户仅关心相关业务参数,不必学习EnvoyFilter的配置规则即可方便地一步到位配置出自适应并发限制能力,该功能已经上线Beta版本,文档也将于近期上线官网,欢迎试用。

目录
相关文章
|
存储 JSON 监控
可以通过配置Filebeat来将Higress日志持久化到磁盘
【2月更文挑战第10天】可以通过配置Filebeat来将Higress日志持久化到磁盘
454 4
|
负载均衡 应用服务中间件 nginx
5分钟搞懂Ingress / IngressController / IngressClass的区别
先来个一句话总结:Ingress由Ingress规则、IngressController、IngressClass这3部分组成。Ingress资源只是一系列路由转发配置,必须使用IngressController才能让路由规则生效,而IngressClass是IngressController的具体实现。使用原则:先部署IngressController → 再部署Ingress资源。
21979 0
5分钟搞懂Ingress / IngressController / IngressClass的区别
Istio中如何限流?
在 Istio 中,可以使用 Envoy 的内置限流机制来限制服务的流量。Envoy 是 Istio 中的数据平面代理,它可以在服务之间进行流量管理和控制。
809 0
|
机器学习/深度学习 人工智能 运维
智能运维:AI驱动的IT运维革命###
【10月更文挑战第21天】 随着数字化转型的深入,智能运维(AIOps)正逐步成为企业IT管理的核心。本文将探讨AI技术如何赋能运维领域,通过自动化、智能化手段提升系统稳定性和效率,降低运营成本,并分享实施智能运维的最佳实践与挑战应对策略。 ###
1108 1
|
存储 负载均衡 监控
自适应负载均衡算法原理和实现
自适应负载均衡算法原理和实现
|
Java 开发工具 Android开发
OpenCV(一):Android studio jni配置OpenCV(亲测有效,保姆级)
OpenCV(一):Android studio jni配置OpenCV(亲测有效,保姆级)
2563 0
|
运维 关系型数据库 Shell
运维自动化之 ansible
运维自动化之 ansible
|
Kubernetes 程序员 API
k8s自定义controller三部曲之二:自动生成代码
本文是《k8s自定义controller三部曲》的第二篇,我们一起来实战如何将controller所需的informer、client等代码通过工具自动生成
889 0
k8s自定义controller三部曲之二:自动生成代码
|
存储 安全 Linux
Envoy源码分析之ThreadLocal机制
# ThreadLocal机制 ​ Envoy中的`ThreadLocal`机制其实就是我们经常说的线程本地存储简称TLS(Thread Local Storage),顾名思义通过TLS定义的变量会在每一个线程专有的存储区域存储一份,访问TLS的时候,其实访问的是当前线程占有存储区域中的副本,因此可以使得线程可以无锁的并发访问同一个变量。Linux上一般有三种方式来定义一个TLS变量。
2204 0
|
存储 缓存 算法
比Bloom Filter节省25%空间!Ribbon Filter在Lindorm中的应用
本文研究了一种新的过滤器Ribbon Filter,并将其集成到Lindorm中
45844 11
比Bloom Filter节省25%空间!Ribbon Filter在Lindorm中的应用

热门文章

最新文章