華為云服務(wù)治理 | ** 服務(wù)治理的一般性原則**

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

華為云微服務(wù)治理專題主要探討運(yùn)行時治理。接下來我們探討故障處理的一般性原則。

故障識別

在用戶看來，故障場景和正常場景是非常容易區(qū)分的。在服務(wù)治理的角度，識別故障則非常困難。

以調(diào)用超時為例，產(chǎn)生調(diào)用超時的原因非常多，包括：（1）服務(wù)端部分接口處理慢，導(dǎo)致超時，而其他接口處理正常；（2）服務(wù)端故障，網(wǎng)絡(luò)不可達(dá)，可能是短暫的，也可能是持續(xù)的；（3）服務(wù)端內(nèi)存、CPU高，導(dǎo)致處理變慢；（4）大量并發(fā)請求在服務(wù)端排隊，當(dāng)請求被處理的時候，已經(jīng)超過了很長的時間；（5）客戶端并發(fā)建立連接，內(nèi)存、CPU增高，導(dǎo)致請求握手超時等。這些不同類型的錯誤，從調(diào)用者看起來，都體現(xiàn)為一樣的行為。

以錯誤碼為例，服務(wù)端返回503錯誤，也可能包含很多不一樣的原因。比如系統(tǒng)未就緒，正在啟動過程中，下次重試就可以訪問；或者服務(wù)出現(xiàn)內(nèi)存泄漏等原因，導(dǎo)致無法進(jìn)行響應(yīng)；當(dāng)服務(wù)內(nèi)部的一些部件不可用的時候，也可能返回503錯誤碼。

基于上述原因，服務(wù)治理能夠識別少量的故障類型，而無法識別更細(xì)維度的故障原因。

故障反饋

高并發(fā)場景下，相對于單個請求處理的時延，故障反饋過程非常緩慢。比如單個請求處理只需要幾個毫秒，但是檢測到請求超時，至少需要幾秒時間。如果減少超時時間，檢測就會變得很不準(zhǔn)確，通常會由于系統(tǒng)調(diào)度延遲，讓超時時間出現(xiàn)大范圍的波動。而且請求超時會觸發(fā)一些系統(tǒng)資源，比如HTTP連接的關(guān)閉和重建，引起更大范圍的超時。再比如依賴于CPU、內(nèi)存或者請求TPS的監(jiān)控數(shù)據(jù)，一般是通過異步線程在后臺周期性進(jìn)行統(tǒng)計實現(xiàn)的，當(dāng)統(tǒng)計數(shù)據(jù)反饋到服務(wù)治理策略的時候，相比較請求時延，已經(jīng)過去很長時間了，這個時候再去實施治理策略，得到的反饋數(shù)據(jù)已經(jīng)不足以支持治理策略的實施。

服務(wù)治理的一般原則

故障識別困難、故障反饋緩慢導(dǎo)致了在故障場景下，不能像處理正常功能邏輯一樣，通過復(fù)雜的邏輯，比如轉(zhuǎn)移故障、采集更多歷史數(shù)據(jù)計算最優(yōu)解等保障本次請求盡可能成功。也不能假設(shè)一個實際無法模擬驗證的故障，然后針對這個故障進(jìn)行保護(hù)。

服務(wù)治理策略需要結(jié)合大量的實踐來進(jìn)行驗證，總結(jié)起來有幾個非常核心的原則：

· 快速失敗優(yōu)先于保障本次請求成功。通過快速失敗降低故障的影響時間，減少故障對于系統(tǒng)資源的占用，讓系統(tǒng)能夠快速恢復(fù)到正常的處理水平。

· 治理策略的邏輯應(yīng)該采用無狀態(tài)算法，不依賴于其他微服務(wù)或者中間件，只依賴于本服務(wù)的內(nèi)部狀態(tài)就能夠?qū)嵤苊庖蕾囉趶?fù)雜的錯誤檢測機(jī)制。這個原則使得服務(wù)治理的策略依賴于相對實時的故障數(shù)據(jù)，減少治理策略本身的處理時間，讓治理策略的前提和結(jié)果變得更好預(yù)測。

· 治理策略的實施條件和結(jié)果必須可以通過模擬的方式進(jìn)行驗證。雖然故障識別是非常困難的，但是任何治理策略都需要假設(shè)他出現(xiàn)的場景是什么，這個場景發(fā)生的時候，故障表現(xiàn)是什么，依賴于故障場景、故障表現(xiàn)來執(zhí)行治理策略，并且可以評估不同治理策略對同樣的故障場景和故障表現(xiàn)得出的保護(hù)效果。

審核編輯 黃宇