0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

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

秃头也爱科技 来源:秃头也爱科技 作者:秃头也爱科技 2023-01-18 19:41 次阅读

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

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

隔离仓的定义和作用

  业务请求的处理都会占用系统资源,包括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的线程池大小为20

server:

tomcat:

threads:

  max: 20

  minSpare: 20

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

测试结果:

不使用隔离仓:

Total time:121852

Success count:200000

Timeout count:0

Error count:0

Average Latency:24

|(10,7942)||(20,90667)||(50,93017)||(100,7041)||(200,1151)||(500,173)||(1000,9)|

使用隔离仓:

Total time:112440

Success count:200000

Timeout count:0

Error count:0

Average 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的线程池大小为40
server:

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:69029

Success count:40000

Timeout count:0

Error count:0

Average Latency:68

|(10,2175)||(20,12078)||(50,5727)||(100,17)||(200,20003)||(500,0)||(1000,0)||(10000,0)|

使用隔离仓:

Total time:107354

Success count:40000

Timeout count:0

Error count:0

Average 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的线程池大小为20

server:

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:110685

Success count:40000

Timeout count:0

Error count:0

Average Latency:109

|(10,160)||(20,1207)||(50,4378)||(100,14091)||(200,19906)||(500,258)||(1000,0)||(10000,0)|

使用隔离仓:

Total time:214565

Success count:40000

Timeout count:0

Error count:0

Average 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的线程池大小为20

server:

tomcat:


threads:

max: 20

minSpare: 20

使用隔离仓的测试结果:

Total time:68189

Success count:22733

Timeout count:1

Error count:17266

Average Latency:115

|(10,53)||(20,2096)||(50,19470)||(100,13025)||(200,3885)||(500,1361)||(1000,109)||(10000,1)|

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

隔离仓总结

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

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

审核编辑 黄宇

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • IO
    IO
    +关注

    关注

    0

    文章

    448

    浏览量

    39134
  • 华为云
    +关注

    关注

    3

    文章

    2445

    浏览量

    17410
收藏 人收藏

    评论

    相关推荐

      华为深度学习服务,让企业智能从此不求人

      近日,华为发布了深度学习服务,要让企业智能从此不求人。那么企业的深度学习服务有哪些能力,为什么能够做到让企业智能从此不求人呢。   
    发表于 08-02 20:44

     华为ServiceStage完美支持多个主流源码托管仓库

    随着“微服务架构”的快速发展,传统应用向微服务转移已成为行业趋势,越来越多的公司及开发者从免费服务器的发展中受益。   华为
    发表于 08-03 13:58

    求助!关于华为平台对numa的要求

    最近有客户想在AMD双路服务器上装华为平台,但是总无法安装,问了华为工程师,他说华为平台的
    发表于 07-11 10:29

    华为FPGA加速服务器如何加速让硬件应用高效上

    华为FPGA加速服务器让“硬用”上成为新增长点随着通信和互联网产业的快速发展,FPGA作为高性能计算加速器在大数据、深度学习、图像视频处理、基因计算、金融分析和加解密等众多领域得到
    发表于 10-22 07:12

    华为弹性服务器上远程编译RK3568的相关资料介绍

    1、在华为弹性服务器上远程编译rk3568配置华为弹性服务器首先注册并登陆
    发表于 09-08 17:06

    华为服务是什么_怎么使用

    华为成立于2011年,隶属于华为公司,在北京、深圳、南京、美国等多地设立有研发和运营机构,贯彻华为公司“、管、端”的战略方针,汇集海内外
    发表于 12-25 15:12 1.9w次阅读

    华为国内首发Istio服务网格

    华为国内首家推出了Istio服务网格产品,该产品与CCE容器引擎深度整合,提供非侵入、智能流量治理的应用全生命周期管理方案,增强了华为
    的头像 发表于 09-08 09:36 3766次阅读

    华为ECS,最专业的服务专家

    随着互联网大数据技术的飞速发展,越来越多的企业也纷纷开始搭建自己的服务架构,并迫切地希望将自身的传统业务上,以此加快企业数字化转型的步伐。华为
    的头像 发表于 12-31 19:21 1320次阅读
    <b class='flag-5'>华为</b><b class='flag-5'>云</b>ECS,最专业的<b class='flag-5'>云</b><b class='flag-5'>服务</b>专家

    华为服务治理 | 微服务常见故障模式

    ),微服务可观测性能力(日志、监控、告警等)构建等。 华为服务治理专题主要探讨运行时治理。我
    的头像 发表于 01-18 17:44 770次阅读

    华为服务治理 | 服务治理的一般性原则

    华为 服务治理 | ** 服务治理的一般性原则** 服务
    的头像 发表于 01-18 18:19 527次阅读

    智领睿变,共建绿色数智金融 -- 华为3.0发布

    华为GaussDB(DWS)作为新一代全场景云数据仓库,提供批量数、实时数以及IoT数三种服务
    的头像 发表于 06-08 21:58 524次阅读
    智领睿变,共建绿色数智金融 -- <b class='flag-5'>华为</b><b class='flag-5'>云</b>数<b class='flag-5'>仓</b>3.0发布

    华为发布 CodeArts Governance 开源治理服务,开源使用更安心

    2023 年 9 月 14 日,华为正式发布 CodeArts Governance 开源治理服务。这是一款针对软件研发提供的一站式开源软件治理
    的头像 发表于 10-12 15:41 435次阅读
    <b class='flag-5'>华为</b><b class='flag-5'>云</b>发布 CodeArts Governance 开源<b class='flag-5'>治理</b><b class='flag-5'>服务</b>,开源使用更安心

    华为 CodeArts 开源治理服务,解锁软件安全新标准

    在数字化时代,软件的安全性日益受到关注,而开源软件的快速发展也带来了新的挑战。再次背景下,华为开源治理服务华为
    的头像 发表于 12-10 21:00 972次阅读
    <b class='flag-5'>华为</b><b class='flag-5'>云</b> CodeArts 开源<b class='flag-5'>治理</b><b class='flag-5'>服务</b>,解锁软件安全新标准

    中软国际数据治理专业服务解决方案获得华为联合基线解决方案认证

    近日,中软国际联合华为生态及技术团队共同设计的数据治理专业服务解决方案成功通过华为基线解决方
    的头像 发表于 12-20 20:25 873次阅读
    中软国际数据<b class='flag-5'>治理</b>专业<b class='flag-5'>服务</b>解决方案获得<b class='flag-5'>华为</b><b class='flag-5'>云</b>联合基线解决方案认证

    软通动力成为华为联合基线解决方案TOP1服务

    近日,软通动力与华为长期以来的深入合作、深度协作再结硕果,双方共同设计的企业上服务解决方案、数据中台及数据治理
    的头像 发表于 01-09 10:59 802次阅读
    软通动力成为<b class='flag-5'>华为</b><b class='flag-5'>云</b>联合基线解决方案TOP1<b class='flag-5'>服务</b>商