写点什么

华为云服务治理 — 隔离仓的作用

  • 2023-01-18
    江苏
  • 本文字数:3576 字

    阅读完需:约 12 分钟

华为云服务治理 — 隔离仓的作用

服务治理通常是指通过限流、熔断等手段,保障微服务的可靠运行,即运行时治理。更加宽泛的服务治理还包括微服务持续集成(开源软件管理、自动化测试等),微服务部署最佳实践(滚动升级、灰度发布等),微服务可观测性能力(日志、监控、告警等)构建等。

微服务治理专题主要探讨运行时治理。隔离仓是适用于大部分故障模式,简单有效的治理策略,本章介绍隔离仓的原理和作用。

隔离仓的定义和作用

业务请求的处理都会占用系统资源,包括 CPU、内存、线程池、连接池等。隔离仓是一种限制业务请求对系统资源占用的服务治理策略,防止单个业务请求或者单个微服务实例过多的占用系统资源,对其他业务请求以及系统总体的性能产生严重影响。

线程池是治理策略应用最广泛的系统资源,通常所有请求都在一个共享的线程池处理,常见的隔离仓实现,都是限制请求对线程池的过多占用。本文以 Spring Cloud Huawei 为例,演示其隔离仓在两种故障场景下的作用。

·      场景一

微服务 A 调用微服务 B,A 和 B 分别有 M 个实例,模拟 N 个并发客户端连续不断的请求 A。然后给 B 扩容 1 个实例。观察应用治理策略和不应用策略的情况下,时延和 TPS 的变化情况。

·      场景二

微服务 A 调用微服务 B,A 和 B 分别有 M 个实例,B 有两个接口 X 和 Y, 其中 X 处理 100ms,Y 处理 500 ms,模拟 N 个并发客户端通过 A 连续请求 X 接口,N 个并发客户端通过 A 连续请求 Y 接口。观察应用治理策略和不应用策略的情况下,时延和 TPS 的变化情况。

Spring Cloud Huawei 客户端隔离仓的工作原理和效果

Spring Cloud Huawei 客户端隔离仓 的主要作用是限制一个实例、或者一个实例的某个接口最大并发数,当一个实例的最大并发处理大于设置的阈值 maxConcurrentCalls 的时候,后续请求会在当前线程等待 maxWaitDuration 时间,如果这段时间有请求处理完毕,那么后续请求会继续处理,否则就会被丢弃,返回 408 错误。Spring Cloud Huawei 服务端隔离仓 的主要作用是限制一个接口的最大并发数,当一个接口的最大并发处理大于设置的阈值 maxConcurrentCalls 的时候,后续请求会在当前线程等待 maxWaitDuration 时间,如果这段时间有请求处理完毕,那么后续请求会继续处理,否则就会被丢弃,返回 408 错误。

·      场景一

微服务 A 的隔离仓配置:

servicecomb:  matchGroup:    allOperation: |      matches:        - apiPath:            prefix: "/"  instanceBulkhead:    ## 隔离仓限制正在处理的请求数为20个,新来的请求等待1000毫秒没有获取到    ## 许可,将被拒绝。    allOperation: |      maxConcurrentCalls: 20      maxWaitDuration: 1000# 为了匹配测试用例,设置微服务A的线程池大小为20server:  tomcat:    threads:      max: 20      minSpare: 20
复制代码

微服务 A 调用微服务 B,A 和 B 分别有 1 个实例,模拟 40 个并发客户端连续不断的请求 A。然后给 B 扩容 1 个实例。观察应用治理策略和不应用策略的情况下,时延和 TPS 的变化情况。

测试结果:

不使用隔离仓:

Total time:121852Success count:200000Timeout count:0Error count:0Average Latency:24|(10,7942)||(20,90667)||(50,93017)||(100,7041)||(200,1151)||(500,173)||(1000,9)|使用隔离仓:Total time:112440Success count:200000Timeout count:0Error count:0Average Latency:22|(10,8683)||(20,100275)||(50,86137)||(100,4106)||(200,679)||(500,120)||(1000,0)|
复制代码

从上述结果可以看出使用隔离仓的情况下,时延大于 200ms 的请求明显减少。 这个结果说明隔离仓的使用并没有降低系统的处理性能,甚至可能带来一些性能的改善,减少时延偏差较大的请求数量。上述测试场景,并没有演示新启动实例导致故障的场景。如果需要模拟这种场景,可以考虑微服务 A 部署 10 个实例,并且采用 500 个并发客户端访问。

·      场景二

微服务 A 的隔离仓配置:

servicecomb:  matchGroup:    allOperation: |      matches:        - apiPath:            # 对耗时的接口配置隔离仓            prefix: "/benchmark/delay/z100"  instanceBulkhead:    ## 隔离仓限制正在处理的请求数为20个,新来的请求等待1000毫秒没有获取到    ## 许可,将被拒绝。    allOperation: |      maxConcurrentCalls: 20      maxWaitDuration: 1000
# 为了匹配测试用例,设置微服务A的线程池大小为40server: tomcat: threads: max: 40 minSpare: 40
复制代码

微服务 A 调用微服务 B,A 和 B 分别有 1 个实例,B 有两个接口 X 和 Y, 其中 X 处理 1ms,Y 处理 100 ms,模拟 20 个并发客户端通过 A 连续请求 X 接口,20 个并发客户端通过 A 连续请求 Y 接口。观察应用治理策略和不应用策略的情况下,时延和 TPS 的变化情况。

测试结果:

不使用隔离仓:

Total time:69029Success count:40000Timeout count:0Error count:0Average Latency:68|(10,2175)||(20,12078)||(50,5727)||(100,17)||(200,20003)||(500,0)||(1000,0)||(10000,0)|
复制代码

使用隔离仓:

Total time:107354Success count:40000Timeout count:0Error count:0Average Latency:106|(10,2217)||(20,14264)||(50,3506)||(100,7)||(200,15738)||(500,4268)||(1000,0)||(10000,0)|
复制代码

从上述结果可以看出使用隔离仓的情况下,时延小于 20ms 的请求有所增加,但是时延超过 500ms 的请求增加更加明显。这是因为测试场景属于 IO 密集型场景,使用隔离仓,降低了 Y 接口的并发度,大量请求排队,导致整体的时延大幅增长。下面把客户端隔离仓去掉,改为服务端隔离仓,再看看效果。

微服务 B 的隔离仓配置:

servicecomb:  matchGroup:    allOperation: |      matches:        - apiPath:            # 对耗时的接口配置隔离仓            prefix: "/benchmark/delay/z100"  bulkhead:    ## 隔离仓限制正在处理的请求数为20个,新来的请求等待1000毫秒没有获取到    ## 许可,将被拒绝。    allOperation: |      maxConcurrentCalls: 10      maxWaitDuration: 1000
# 为了匹配测试用例,设置微服务B的线程池大小为20server: tomcat: threads: max: 20 minSpare: 20
复制代码

微服务 A 调用微服务 B,A 和 B 分别有 1 个实例,B 有两个接口 X 和 Y, 其中 X 处理 1ms,Y 处理 100 ms,模拟 20 个并发客户端通过 A 连续请求 X 接口,20 个并发客户端通过 A 连续请求 Y 接口。观察应用治理策略和不应用策略的情况下,时延和 TPS 的变化情况。

测试结果:

不使用隔离仓:

Total time:110685Success count:40000Timeout count:0Error count:0Average Latency:109|(10,160)||(20,1207)||(50,4378)||(100,14091)||(200,19906)||(500,258)||(1000,0)||(10000,0)|
复制代码

使用隔离仓:

Total time:214565Success count:40000Timeout count:0Error count:0Average Latency:213|(10,46)||(20,734)||(50,279)||(100,3941)||(200,14972)||(500,19995)||(1000,33)||(10000,0)|
复制代码

从上述结果可以看出使用隔离仓的情况下,平均时延和性能同样会下降。我们适当调整下隔离仓的限制,快速丢弃一些请求:

servicecomb:  matchGroup:    allOperation: |      matches:        - apiPath:            # 对耗时的接口配置隔离仓            prefix: "/benchmark/delay/z100"  bulkhead:    ## 隔离仓限制正在处理的请求数为20个,新来的请求等待1000毫秒没有获取到    ## 许可,将被拒绝。    allOperation: |      maxConcurrentCalls: 10      maxWaitDuration: 10
# 为了匹配测试用例,设置微服务B的线程池大小为20server: tomcat: threads: max: 20 minSpare: 20
复制代码

使用隔离仓的测试结果:

Total time:68189Success count:22733Timeout count:1Error count:17266Average Latency:115|(10,53)||(20,2096)||(50,19470)||(100,13025)||(200,3885)||(500,1361)||(1000,109)||(10000,1)|
复制代码

上述结果可以看出,快速丢弃请求的情况下,时延小于 50ms 的请求大于 20000 个。隔离仓保证了处理很快的接口能够得到快速成功执行,前提条件是处理很慢的接口不占用资源,快速失败。

隔离仓总结

隔离仓的使用,在计算密集型场景下,对系统的性能影响很小,甚至可以起到一定的性能改善作用。在 IO 密集型场景下,由于隔离仓降低了请求的并发执行线程,会导致吞吐量降低和时延增加。


也可以看出,在 IO 等待比较长的情况下,系统的吞吐量和系统的可靠性是两个没法同时满足的目标,如果要保证成功率不降低,并且吞吐量增加,那么势必增加业务线程等系统资源占用,从而对系统整体的可靠性产生影响。对于耗时的请求,只能通过快速丢弃超过资源使用限制的部分,才能够保证系统吞吐量不下降,并且避免产生系统性的全局功能影响。因此,系统应该合理的设计部分耗时请求的最大并发,在超过这些指标的时候,快速丢弃多余的请求。过度追求耗时请求的吞吐量而扩大线程池、连接池等,是很多应用系统最常见的设计误区。

用户头像

还未添加个人签名 2022-09-25 加入

还未添加个人简介

评论

发布
暂无评论
华为云服务治理 — 隔离仓的作用_秃头也爱科技_InfoQ写作社区