華為云服務治理 | ** 服務治理的一般性原則**

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

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

故障識別

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

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

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

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

故障反饋

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

服務治理的一般原則

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

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

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

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

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

審核編輯 黃宇