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

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

隔离仓的定义和作用

业务请求的处理都会占用系统资源，包括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

测试结果：

不使用隔离仓：

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

华为云服务治理 | 隔离仓的作用相关推荐

华为云数据治理生产线DataArts，让“数据‘慧’说话”
摘要:数据治理生产线DataArts改变了传统"人拉肩抗"的数据处理方式,帮助提升效率:降低技术门槛,让"人人都是分析师":让"数据'慧'说话&quo ...
华为云服务的购买和建站
1.购买华为云服务(选择centos7.6)其他设置默认 2.去控制台先关机然后重置密码 3.设置安全组(相当于门卫) 4.常见端口使用SSH SecureShell Client建站使用Xshe ...
cloud华为云服务登录(华为云服务平台登录入口)
想从荣耀6换到华为荣耀7,华为云服务需要重新登录吗?会自动同步吗? 有两种方法,其一是使用华为的一个APP叫手机克隆,一键迁移手机的所有数据,而且IOS和EMUI系统的手机也是无缝连接,其二是登陆华为 ...
android华为登录云服务,华为云服务登录网页版
华为云服务登录网页版是一款专为华为手机用户打造的相册管理安全储存软件,拥有一键快速恢复删除照片,安全下载查看图片,实时云端同步保存,赶紧下载体验一下吧. 华为云服务登录网页版特色 [轻松查找照片] 智 ...
一张图了解华为云服务
[摘要] 华为云迄今为止已经有14大类超过100种服务了,并且更多的新服务还在不断上线中. 摘要:华为云迄今为止已经有14大类超过100种服务了,并且更多的新服务还在不断上线中.众多的服务不仅让客户眼 ...
华为云服务部署Rstudio Server
0. 系统配置 linux版本ubuntu20.0.4LTS 华为云服务器HECS 2核4G 1M,带宽有点拉 1 下载,安装详见官网 Download RStudio Server for Debi ...
如何从华为云服务器上找回手机,华为云服务怎么样使用手机找回功能
电脑登录华为云服务网站点击"手机找回"选择设备点击"定位". 桌面找到手机找回图标,开启手机找回功能(此功能必须登录华为账号,部分机型版本该功能存在于华为云服务 ...
华为手机系统服务器在哪里,华为云服务这软件在哪？
1.在手机的全部设置中找到华为云服务图标,点击开始使用,然后开启华为云服务,输入账号登录. , 2.登录首页后可以看到同步联系人和云照片.手机找回.自动备份等按钮,开启对应按钮就可以实现相关操作. 同 ...
华为云NP考试题库_华为云服务考试华为云hcip认证试题
怎样找到华为手机云服务? 在华为手机云服务的手机设置菜单中,以华为G9手机为例.搜索方法如下:1.打开手机的设置页面,在设置页面的顶部有一个搜索框. 2.在搜索框中,输入云服务以开始搜索.搜索结束后, ...

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

隔离仓的定义和作用

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

隔离仓总结

华为云服务治理 | 隔离仓的作用相关推荐

最新文章

热门文章