Envoy熔断限流实践(一)基于Rainbond插件实现熔断
Envoy 可以作为 Sevice Mesh 微服务框架中的代理实现方案,Rainbond 内置的微服务框架同样基于 Envoy 实现。本文所描述的熔断实践基于 Rainbond 特有的插件机制实现。Envoy 熔断机制介绍 熔断是分布式系统的重要组成部分。快速失败并尽快给下游施加压力,可以防止整个微服务系统进入糟糕的级联雪崩状态。这是Envoy 网格的主要优点之一,Envoy 在网络级别实现强制断路限制,而不必独立配置和编写每个应用程序。Envoy 支持各种类型的完全分布(不协调)的熔断:
- 集群最大连接数(MaxConnections):Envoy将为上游群集中的所有主机建立的最大连接数。实际上,这仅适用于HTTP/1.1群集,因为HTTP/2使用到每个主机的单个连接。
- 集群最大挂起请求数(MaxPendingRequests):在等待就绪连接池连接时将排队的最大请求数。实际上,这仅适用于HTTP/1.1群集,因为HTTP/2连接池不会排队请求。HTTP/2请求立即复用。如果这个断路器溢出,集群的
upstream_rq_pending_overflow
计数器将增加。 - 集群最大请求数(MaxRequests):在任何给定时间,群集中所有主机可以处理的最大请求数。实际上,这适用于HTTP/2群集,因为HTTP/1.1群集由最大连接断路器控制。如果这个断路器溢出,集群的
upstream_rq_pending_overflow
计数器将增加。 - 集群最大活动重试次数(MaxRetries):在任何给定时间,集群中所有主机可以执行的最大重试次数。一般来说,我们建议积极进行断路重试,以便允许零星故障重试,但整体重试量不能爆炸并导致大规模级联故障。如果这个断路器溢出,集群的
upstream_rq_retry_overflow
计数器将递增。
文章图片
基于插件机制实现的熔断
Rainbond 云原生应用管理平台通过自有的插件机制实现指定的微服务面向下游组件的熔断。
默认安装的 Rainbond 中已经集成了
出口网络治理插件
以及 综合网络治理插件
,二者都基于 Envoy
实现,可以对安装了插件的微服务的网络出口方向进行较为全面的网络治理。其中就包括对熔断机制的实现。为了更好的描述这个过程,特意准备了一个示例。
基于 Locust 实现的压力生成器作为客户端,安装
综合网络治理插件
,Java-maven 组件作为服务端。压力生成器可以根据图形化界面设置并发用户数量,对 Java-maven 的服务地址进行压力测试,在此期间,我们可以收集到触发熔断机制时的各种现象。文章图片
综合网络治理插件
的安装很简单,在请求发起的客户端(示例中的压力生成器)服务组件的插件页面中点击安装指定的插件即可。设定熔断阈值
Java-maven 组件基于 Http/1.1 版本协议实现,根据首节对 Envoy 熔断机制的解释,我们可以通过限制 集群最大连接数(MaxConnections) 和 集群最大挂起请求数(MaxPendingRequests) 来设定熔断条件。
点击压力生成器组件的插件,查看
出口网络治理插件
配置,就可以进入其配置页面。综合网络治理插件
分为入站网络治理配置和出站网络治理配置两个配置区域,熔断阈值的设定位于出站网络治理配置区域。为了突出实验的效果,我将
MaxConnections
和 MaxPendingRequests
两项均设定为较小的值。文章图片
图中的配置,意味着集群最大连接数为 6 ,最大等待的请求数为 1 (这二者的默认值均为 1024)。这一配置,相当于为 Envoy 生成了以下配置:
"circuit_breakers": {
"default": {
"max_connections": 6,
"max_pending_requests": 1
}
}
为下游应用 Java-maven 的 5000 端口设定的
Domains
也很重要,压力生成器可以通过访问 java-maven
这一域名,将压力施加于 Java-maven 的 5000 端口。触发熔断
基于 Locust 的 Web 页面可以设定并发条件,在这个实验中,我为域名
http://java-maven
设定了 97 个用户的并发请求。 Locust 的页面中会体现出发起请求的总数,以及处于失败状态的请求数。文章图片
所有的错误请求,都获得了由熔断机制返回的 503 状态码。
文章图片
为了确认压力生成器与 Java-maven 组件间的 Tcp 连接数量的确得到了限制,可以进入 Java
-maven 的 Web终端用命令查看。
文章图片
命令中的
172.20.1.74
是压力生成器组件的 Pod IP 地址。这里需要注意,不要去压力生成器中查询 Tcp 连接的生成数量,这个数量会多于 6 个,实际上应该是 97,因为发起请求的 Locust 进程会根据并发用户数量来生成 Tcp 连接,这个过程不受熔断机制限制,然而请求经过 Envoy 时,向 Java-maven 这一服务端,最终只会成功建立并保持 6 个连接。
提升熔断阈值
接下来,通过调整
综合网络治理插件
的配置,调整熔断的阈值,将 MaxConnections
提升至 66。文章图片
点击更新配置后,改动将会直接生效,而不需要重启组件。
在压力生成器中适当提升并发用户数到 250,重新开始发起压力测试,可以发现,不再生成错误请求。
文章图片
重新在 Java-maven 的环境中查询建立的 tcp 连接数量,发现已经不再是 6 ,而是有所上升,但并未到达阈值66。
文章图片
持续提升并发用户数量,则可以再次触发熔断。
总结
熔断是微服务网络治理体系中非常重要的一环。Rainbond 结合 Envoy 实现的 ServiceMesh 微服务框架中,通过插件实现的熔断机制易于上手,且支持动态生效,对操作人员非常友好。
【Envoy熔断限流实践(一)基于Rainbond插件实现熔断】下一篇,我们将介绍全局限流的实现,敬请期待。
推荐阅读
- 无限流量限速怎么排除
- 深入学习springCloud——Hystrix服务熔断/降级
- 面试官(RabbitMQ怎么实现消费端限流)
- 基于kubernetes的分布式限流
- go-zero源码阅读-限流器#第四期
- SpringCloud中使用Sentinel实现限流的实战
- sentinel|sentinel 整合spring cloud限流的过程解析
- golang|golang 熔断器的实现过程
- Redigo:|Redigo: Envoy代理Redis场景下的错误提示
- 4种典型限流实践保障应用高可用 | 云效工程师指北