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版本,文档也将于近期上线官网,欢迎试用。

目录
相关文章
|
API 容器 Kubernetes
当 K8s 集群达到万级规模,阿里巴巴如何解决系统各组件性能问题?
作者 | 阿里云容器平台高级技术专家 曾凡松(逐灵) 本文主要介绍阿里巴巴在大规模生产环境中落地 Kubernetes 的过程中,在集群规模上遇到的典型问题以及对应的解决方案,内容包含对 etcd、kube-apiserver、kube-controller 的若干性能及稳定性增强,这些关键的增强是阿里巴巴内部上万节点的 Kubernetes 集群能够平稳支撑 2019 年天猫 618 大促的关键所在。
|
10月前
|
人工智能 运维 Devops
CAP:Serverless + AI 让应用开发更简单
对于众多开发者而言,Serverless 架构的核心优势在于其能够无缝集成多种云产品与组件,从而使得开发者可以更加专注于核心业务逻辑和创新。此外,Serverless 架构还提供了按量付费的灵活计费模式,进一步降低了资源成本。使用云应用开发平台 CAP,在 AI 领域,企业就可以专注于模型训练、算法优化等关键任务,让 AI 应用的开发、部署以及全生命周期的管理更加简单。可以预见 Serverless 技术将催生一系列创新且有趣的应用,而这些应用将不断拓展 AI 技术的边界。
|
10月前
|
Kubernetes 测试技术 微服务
结合阿里云ASM泳道与Kruise Rollout进行全链路灰度发布
本文将介绍如何结合阿里云ASM泳道与Kruise Rollout进行低成本,自动化的全链路灰度发布。
|
11月前
|
机器学习/深度学习 人工智能 运维
智能运维:AI驱动的IT运维革命###
【10月更文挑战第21天】 随着数字化转型的深入,智能运维(AIOps)正逐步成为企业IT管理的核心。本文将探讨AI技术如何赋能运维领域,通过自动化、智能化手段提升系统稳定性和效率,降低运营成本,并分享实施智能运维的最佳实践与挑战应对策略。 ###
789 1
|
Java 开发工具 Android开发
OpenCV(一):Android studio jni配置OpenCV(亲测有效,保姆级)
OpenCV(一):Android studio jni配置OpenCV(亲测有效,保姆级)
1923 0
|
存储 负载均衡 监控
自适应负载均衡算法原理和实现
自适应负载均衡算法原理和实现
|
Kubernetes 程序员 API
k8s自定义controller三部曲之二:自动生成代码
本文是《k8s自定义controller三部曲》的第二篇,我们一起来实战如何将controller所需的informer、client等代码通过工具自动生成
762 0
k8s自定义controller三部曲之二:自动生成代码
|
缓存 NoSQL 数据库
Flink cdc到doris,starrocks,table store
Flink cdc到doris,starrocks,table store
|
存储 安全 Linux
Envoy源码分析之ThreadLocal机制
# ThreadLocal机制 ​ Envoy中的`ThreadLocal`机制其实就是我们经常说的线程本地存储简称TLS(Thread Local Storage),顾名思义通过TLS定义的变量会在每一个线程专有的存储区域存储一份,访问TLS的时候,其实访问的是当前线程占有存储区域中的副本,因此可以使得线程可以无锁的并发访问同一个变量。Linux上一般有三种方式来定义一个TLS变量。
2081 0
|
域名解析 弹性计算 运维
多账号共享一套ACR方案
一家多业务组织的客户来说往往会有多个云账号,分别部署各个业务线的容器服务。但集团可能想使用一套统一的容器镜像仓库(ACR),就会面临多账号内多个ACK共享一套ACR了。那如何合理规划好ACR实例上的命名空间,打通各个业务ACK集群与ACR的网络,包括如何精细化授权,都是客户需要考虑的。
356 3
多账号共享一套ACR方案