华为云服务治理—隔离仓的作用
服务治理通常是指通过限流、熔断等手段，保障微服务的可靠运行，即运行时治理。更加宽泛的服务治理还包括微服务持续集成（开源软件管理、自动化测试等），微服务部署最佳实践（滚动升级、灰度发布等），微服务可观测性能力（日志、监控、告警等）构建等。
微服务治理专题主要探讨运行时治理。隔离仓是适用于大部分故障模式，简单有效的治理策略，本章介绍隔离仓的原理和作用。
隔离仓的定义和作用 业务请求的处理都会占用系统资源，包括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/z100instancebulkhead:## 隔离仓限制正在处理的请求数为20个，新来的请求等待1000毫秒没有获取到## 许可，将被拒绝。alloperation: |maxconcurrentcalls: 20maxwaitduration: 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/z100bulkhead:## 隔离仓限制正在处理的请求数为20个，新来的请求等待1000毫秒没有获取到## 许可，将被拒绝。alloperation: |maxconcurrentcalls: 10maxwaitduration: 1000# 为了匹配测试用例，设置微服务b的线程池大小为20server:tomcat:threads:max: 20minspare: 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/z100bulkhead:## 隔离仓限制正在处理的请求数为20个，新来的请求等待1000毫秒没有获取到## 许可，将被拒绝。alloperation: |maxconcurrentcalls: 10maxwaitduration: 10# 为了匹配测试用例，设置微服务b的线程池大小为20server:tomcat:threads:max: 20minspare: 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等待比较长的情况下，系统的吞吐量和系统的可靠性是两个没法同时满足的目标，如果要保证成功率不降低，并且吞吐量增加，那么势必增加业务线程等系统资源占用，从而对系统整体的可靠性产生影响。对于耗时的请求，只能通过快速丢弃超过资源使用限制的部分，才能够保证系统吞吐量不下降，并且避免产生系统性的全局功能影响。因此，系统应该合理的设计部分耗时请求的最大并发，在超过这些指标的时候，快速丢弃多余的请求。过度追求耗时请求的吞吐量而扩大线程池、连接池等，是很多应用系统最常见的设计误区。
小米推出“小米有品·家” 加入了很多智能家居设备
场效应管厂商：深圳市晶导电子有限公司简介
研究发现：Win10 快捷方式一短字符串会损坏任何硬盘
以太坊智能合约中Merkle树的算法原型解析
securecrt和xshell的区别
华为云服务治理—隔离仓的作用
LED回收的重要性和必要性
20多年发展，物联网将是下一个风口！
最年轻的产品奥迪Q2L上市 奥迪进一步完善新能源产品布局
自动驾驶技术对应用在汽车上的连接器有哪些要求
新能源汽车电源之锂硫电池利弊谈
如何使用Arduino Processing和Wekinator按钮更改声音播放器的音高
内置T6963C液晶显示模块在MSP430中的控制技术
联发科获多家手机 / 平板 / 笔记本厂商 Wi-Fi 7订单
2022年有什么蓝牙耳机？2022年最好的蓝牙耳机排行榜
曼富图越野者登山套装评测 最适合爱好登山的摄影用户使用
LED灯盘的实际电路怎么看
高速PCB设计中详细布局的六大步骤解析
芯炽SC1269模数转换器概述及主要特点
GDDR6显存颗粒崭露头角 英伟达下一代显卡显存居然达到48G！
微服务治理专题主要探讨运行时治理。隔离仓是适用于大部分故障模式，简单有效的治理策略，本章介绍隔离仓的原理和作用。
隔离仓的定义和作用 业务请求的处理都会占用系统资源，包括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/z100instancebulkhead:## 隔离仓限制正在处理的请求数为20个，新来的请求等待1000毫秒没有获取到## 许可，将被拒绝。alloperation: |maxconcurrentcalls: 20maxwaitduration: 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/z100bulkhead:## 隔离仓限制正在处理的请求数为20个，新来的请求等待1000毫秒没有获取到## 许可，将被拒绝。alloperation: |maxconcurrentcalls: 10maxwaitduration: 1000# 为了匹配测试用例，设置微服务b的线程池大小为20server:tomcat:threads:max: 20minspare: 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/z100bulkhead:## 隔离仓限制正在处理的请求数为20个，新来的请求等待1000毫秒没有获取到## 许可，将被拒绝。alloperation: |maxconcurrentcalls: 10maxwaitduration: 10# 为了匹配测试用例，设置微服务b的线程池大小为20server:tomcat:threads:max: 20minspare: 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等待比较长的情况下，系统的吞吐量和系统的可靠性是两个没法同时满足的目标，如果要保证成功率不降低，并且吞吐量增加，那么势必增加业务线程等系统资源占用，从而对系统整体的可靠性产生影响。对于耗时的请求，只能通过快速丢弃超过资源使用限制的部分，才能够保证系统吞吐量不下降，并且避免产生系统性的全局功能影响。因此，系统应该合理的设计部分耗时请求的最大并发，在超过这些指标的时候，快速丢弃多余的请求。过度追求耗时请求的吞吐量而扩大线程池、连接池等，是很多应用系统最常见的设计误区。
小米推出“小米有品·家” 加入了很多智能家居设备
场效应管厂商：深圳市晶导电子有限公司简介
研究发现：Win10 快捷方式一短字符串会损坏任何硬盘
以太坊智能合约中Merkle树的算法原型解析
securecrt和xshell的区别
华为云服务治理—隔离仓的作用
LED回收的重要性和必要性
20多年发展，物联网将是下一个风口！
最年轻的产品奥迪Q2L上市 奥迪进一步完善新能源产品布局
自动驾驶技术对应用在汽车上的连接器有哪些要求
新能源汽车电源之锂硫电池利弊谈
如何使用Arduino Processing和Wekinator按钮更改声音播放器的音高
内置T6963C液晶显示模块在MSP430中的控制技术
联发科获多家手机 / 平板 / 笔记本厂商 Wi-Fi 7订单
2022年有什么蓝牙耳机？2022年最好的蓝牙耳机排行榜
曼富图越野者登山套装评测 最适合爱好登山的摄影用户使用
LED灯盘的实际电路怎么看
高速PCB设计中详细布局的六大步骤解析
芯炽SC1269模数转换器概述及主要特点
GDDR6显存颗粒崭露头角 英伟达下一代显卡显存居然达到48G！