服務(wù)治理通常是指通過限流、熔斷等手段，保障微服務(wù)的可靠運(yùn)行，即運(yùn)行時(shí)治理。更加寬泛的服務(wù)治理還包括微服務(wù)持續(xù)集成（開源軟件管理、自動(dòng)化測(cè)試等），微服務(wù)部署最佳實(shí)踐（滾動(dòng)升級(jí)、灰度發(fā)布等），微服務(wù)可觀測(cè)性能力（日志、監(jiān)控、告警等）構(gòu)建等。

??微服務(wù)治理專題主要探討運(yùn)行時(shí)治理。隔離倉是適用于大部分故障模式，簡單有效的治理策略，本章介紹隔離倉的原理和作用。

隔離倉的定義和作用

??業(yè)務(wù)請(qǐng)求的處理都會(huì)占用系統(tǒng)資源，包括CPU、內(nèi)存、線程池、連接池等。隔離倉是一種限制業(yè)務(wù)請(qǐng)求對(duì)系統(tǒng)資源占用的服務(wù)治理策略，防止單個(gè)業(yè)務(wù)請(qǐng)求或者單個(gè)微服務(wù)實(shí)例過多的占用系統(tǒng)資源，對(duì)其他業(yè)務(wù)請(qǐng)求以及系統(tǒng)總體的性能產(chǎn)生嚴(yán)重影響。

??線程池是治理策略應(yīng)用最廣泛的系統(tǒng)資源，通常所有請(qǐng)求都在一個(gè)共享的線程池處理，常見的隔離倉實(shí)現(xiàn)，都是限制請(qǐng)求對(duì)線程池的過多占用。本文以 Spring Cloud Huawei 為例，演示其隔離倉在兩種故障場(chǎng)景下的作用。

• 場(chǎng)景一

??微服務(wù)A調(diào)用微服務(wù)B，A和B分別有M個(gè)實(shí)例，模擬N個(gè)并發(fā)客戶端連續(xù)不斷的請(qǐng)求A。然后給B擴(kuò)容1個(gè)實(shí)例。觀察應(yīng)用治理策略和不應(yīng)用策略的情況下，時(shí)延和TPS的變化情況。

• 場(chǎng)景二

??微服務(wù)A調(diào)用微服務(wù)B，A和B分別有M個(gè)實(shí)例，B有兩個(gè)接口 X 和 Y， 其中X處理100ms，Y處理500 ms，模擬N 個(gè)并發(fā)客戶端通過A連續(xù)請(qǐng)求X接口，N 個(gè)并發(fā)客戶端通過A連續(xù)請(qǐng)求Y接口。觀察應(yīng)用治理策略和不應(yīng)用策略的情況下，時(shí)延和TPS的變化情況。

Spring Cloud Huawei客戶端隔離倉的工作原理和效果

??Spring Cloud Huawei 客戶端隔離倉 的主要作用是限制一個(gè)實(shí)例、或者一個(gè)實(shí)例的某個(gè)接口最大并發(fā)數(shù)，當(dāng)一個(gè)實(shí)例的最大并發(fā)處理大于設(shè)置的閾值maxConcurrentCalls的時(shí)候，后續(xù)請(qǐng)求會(huì)在當(dāng)前線程等待maxWaitDuration時(shí)間，如果這段時(shí)間有請(qǐng)求處理完畢，那么后續(xù)請(qǐng)求會(huì)繼續(xù)處理，否則就會(huì)被丟棄，返回408錯(cuò)誤。

??Spring Cloud Huawei 服務(wù)端隔離倉 的主要作用是限制一個(gè)接口的最大并發(fā)數(shù)，當(dāng)一個(gè)接口的最大并發(fā)處理大于設(shè)置的閾值maxConcurrentCalls的時(shí)候，后續(xù)請(qǐng)求會(huì)在當(dāng)前線程等待maxWaitDuration時(shí)間，如果這段時(shí)間有請(qǐng)求處理完畢，那么后續(xù)請(qǐng)求會(huì)繼續(xù)處理，否則就會(huì)被丟棄，返回408錯(cuò)誤。

• 場(chǎng)景一

??微服務(wù)A的隔離倉配置：

servicecomb:

matchGroup:

allOperation: |

  matches:

    - apiPath:

        prefix: "/"

instanceBulkhead:

## 隔離倉限制正在處理的請(qǐng)求數(shù)為20個(gè)，新來的請(qǐng)求等待1000毫秒沒有獲取到

## 許可，將被拒絕。

allOperation: |

  maxConcurrentCalls: 20

  maxWaitDuration: 1000

為了匹配測(cè)試用例，設(shè)置微服務(wù)A的線程池大小為20

server:

tomcat:

threads:

  max: 20

  minSpare: 20

??微服務(wù)A調(diào)用微服務(wù)B，A和B分別有1個(gè)實(shí)例，模擬40個(gè)并發(fā)客戶端連續(xù)不斷的請(qǐng)求A。然后給B擴(kuò)容1個(gè)實(shí)例。觀察應(yīng)用治理策略和不應(yīng)用策略的情況下，時(shí)延和TPS的變化情況。

測(cè)試結(jié)果：

不使用隔離倉：

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)|

??從上述結(jié)果可以看出使用隔離倉的情況下，時(shí)延大于200ms的請(qǐng)求明顯減少。 這個(gè)結(jié)果說明隔離倉的使用并沒有降低系統(tǒng)的處理性能，甚至可能帶來一些性能的改善，減少時(shí)延偏差較大的請(qǐng)求數(shù)量。上述測(cè)試場(chǎng)景，并沒有演示新啟動(dòng)實(shí)例導(dǎo)致故障的場(chǎng)景。如果需要模擬這種場(chǎng)景，可以考慮微服務(wù)A部署10個(gè)實(shí)例，并且采用500個(gè)并發(fā)客戶端訪問。

• 場(chǎng)景二

微服務(wù)A的隔離倉配置：

servicecomb:

matchGroup:

allOperation: |

  matches:

    - apiPath:

        # 對(duì)耗時(shí)的接口配置隔離倉

        prefix: "/benchmark/delay/z100"

instanceBulkhead:

## 隔離倉限制正在處理的請(qǐng)求數(shù)為20個(gè)，新來的請(qǐng)求等待1000毫秒沒有獲取到

## 許可，將被拒絕。

allOperation: |

maxConcurrentCalls: 20

maxWaitDuration: 1000

# 為了匹配測(cè)試用例，設(shè)置微服務(wù)A的線程池大小為40
server:

tomcat:

threads:

  max: 40

  minSpare: 40

??微服務(wù)A調(diào)用微服務(wù)B，A和B分別有1個(gè)實(shí)例，B有兩個(gè)接口 X 和 Y， 其中X處理1ms，Y處理100 ms，模擬20 個(gè)并發(fā)客戶端通過A連續(xù)請(qǐng)求X接口，20 個(gè)并發(fā)客戶端通過A連續(xù)請(qǐng)求Y接口。觀察應(yīng)用治理策略和不應(yīng)用策略的情況下，時(shí)延和TPS的變化情況。

測(cè)試結(jié)果：

不使用隔離倉：

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)|

??從上述結(jié)果可以看出使用隔離倉的情況下，時(shí)延小于20ms的請(qǐng)求有所增加，但是時(shí)延超過500ms的請(qǐng)求增加更加明顯。這是因?yàn)闇y(cè)試場(chǎng)景屬于IO密集型場(chǎng)景，使用隔離倉，降低了Y接口的并發(fā)度，大量請(qǐng)求排隊(duì)，導(dǎo)致整體的時(shí)延大幅增長。下面把客戶端隔離倉去掉，改為服務(wù)端隔離倉，再看看效果。

微服務(wù)B的隔離倉配置：

servicecomb:

matchGroup:

allOperation: |

matches:
- apiPath:
# 對(duì)耗時(shí)的接口配置隔離倉

prefix: "/benchmark/delay/z100"

bulkhead:

## 隔離倉限制正在處理的請(qǐng)求數(shù)為20個(gè)，新來的請(qǐng)求等待1000毫秒沒有獲取到

## 許可，將被拒絕。

allOperation: |

maxConcurrentCalls: 10

maxWaitDuration: 1000
# 為了匹配測(cè)試用例，設(shè)置微服務(wù)B的線程池大小為20

server:

tomcat:

threads:

max: 20

minSpare: 20

??微服務(wù)A調(diào)用微服務(wù)B，A和B分別有1個(gè)實(shí)例，B有兩個(gè)接口 X 和 Y， 其中X處理1ms，Y處理100 ms，模擬20 個(gè)并發(fā)客戶端通過A連續(xù)請(qǐng)求X接口，20 個(gè)并發(fā)客戶端通過A連續(xù)請(qǐng)求Y接口。觀察應(yīng)用治理策略和不應(yīng)用策略的情況下，時(shí)延和TPS的變化情況。

測(cè)試結(jié)果：

不使用隔離倉：

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)|

??從上述結(jié)果可以看出使用隔離倉的情況下，平均時(shí)延和性能同樣會(huì)下降。我們適當(dāng)調(diào)整下隔離倉的限制，快速丟棄一些請(qǐng)求：

servicecomb:

matchGroup:

allOperation: |

matches:

- apiPath:
  
  # 對(duì)耗時(shí)的接口配置隔離倉

prefix: "/benchmark/delay/z100"


bulkhead:

## 隔離倉限制正在處理的請(qǐng)求數(shù)為20個(gè)，新來的請(qǐng)求等待1000毫秒沒有獲取到

## 許可，將被拒絕。

allOperation: |

maxConcurrentCalls: 10

maxWaitDuration: 10
# 為了匹配測(cè)試用例，設(shè)置微服務(wù)B的線程池大小為20

server:

tomcat:


threads:

max: 20

minSpare: 20

使用隔離倉的測(cè)試結(jié)果：

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)|

??上述結(jié)果可以看出，快速丟棄請(qǐng)求的情況下，時(shí)延小于50ms的請(qǐng)求大于20000個(gè)。隔離倉保證了處理很快的接口能夠得到快速成功執(zhí)行，前提條件是處理很慢的接口不占用資源，快速失敗。

隔離倉總結(jié)

??隔離倉的使用，在計(jì)算密集型場(chǎng)景下，對(duì)系統(tǒng)的性能影響很小，甚至可以起到一定的性能改善作用。在IO密集型場(chǎng)景下，由于隔離倉降低了請(qǐng)求的并發(fā)執(zhí)行線程，會(huì)導(dǎo)致吞吐量降低和時(shí)延增加。

??也可以看出，在IO等待比較長的情況下，系統(tǒng)的吞吐量和系統(tǒng)的可靠性是兩個(gè)沒法同時(shí)滿足的目標(biāo)，如果要保證成功率不降低，并且吞吐量增加，那么勢(shì)必增加業(yè)務(wù)線程等系統(tǒng)資源占用，從而對(duì)系統(tǒng)整體的可靠性產(chǎn)生影響。對(duì)于耗時(shí)的請(qǐng)求，只能通過快速丟棄超過資源使用限制的部分，才能夠保證系統(tǒng)吞吐量不下降，并且避免產(chǎn)生系統(tǒng)性的全局功能影響。因此，系統(tǒng)應(yīng)該合理的設(shè)計(jì)部分耗時(shí)請(qǐng)求的最大并發(fā)，在超過這些指標(biāo)的時(shí)候，快速丟棄多余的請(qǐng)求。過度追求耗時(shí)請(qǐng)求的吞吐量而擴(kuò)大線程池、連接池等，是很多應(yīng)用系統(tǒng)最常見的設(shè)計(jì)誤區(qū)。

審核編輯 黃宇