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

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

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

故障識別

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

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

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

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

故障反饋

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

服務治理的一般原則

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

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

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

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

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

審核編輯 黃宇