服務治理治什麼，10 張圖告訴你答案

作者 | jinjunzhu       責編 | 歐陽姝黎

凌晨四點被公司的監控告警叫醒了，告警的原因是生產環境跑批任務發生故障。即刻起牀處理故障，但還是花了不少時間才解決。

這次故障是一次數據校驗的跑批任務，校驗前面跑批任務的數據是否正確。幸運的是，之前的核心任務已經完成，並沒有影響到生產上的交易系統工作。

爲什麼我這裏提到了交易工作呢？因爲交易系統是整個系統業務流量的入口，如果交易系統發生故障，那會給公司帶來直接的收入損失。

今天我們聊的話題是服務治理，服務治理最終達到的結果就是系統 「7 * 24」 小時不間斷服務。

監控告警

公司的這次生產告警很準確，找到系統的直接維護人，並且通知到是哪個跑批任務出了故障。這次告警是通過監控跑批任務中間件的任務執行結果來觸發的。

一般情況下，告警有哪些類型呢？我們看下圖：

1.1 批處理效率

❝

多數情況下批處理任務是不阻礙業務入口的，所以不需要監控。

❞

在阻礙業務入口的情況下，批處理任務必須要監控。我舉兩個業務場景：

這些場景下批處理效率是非常重要的一個監控指標，必須配置超時閾值並進行監控。

1.2 流量監控

常用的限流的指標如下圖:

流量監控我們需要注意幾點：

1.3 異常監控

異常監控對於系統來說非常重要。在生產環境中很難保證程序不發生異常，配置合理的異常報警對快速定位和解決問題至關重要。比如開篇提到的跑批告警，告警信息中帶着異常，讓我很快就定位到了問題。

異常監控需要注意下面幾個方面：

1.4 資源使用率

生產環境配置系統資源時，一般要對系統資源的使用率有一個預測。比如 redis 在當前的內存增長速率下，多久會耗盡內存，數據庫在當前的增長速率下多久會用光磁盤。

系統資源需要設置一個閾值，比如 70%，超過這個限制就要觸發告警。因爲資源使用快要飽和時，處理效率也會嚴重下降。

配置資源使用率的閾值時，一定要考慮突增流量和突發業務的情況，提前預留額外的資源來應對。

對核心服務要做好限流措施，防止突增流量把系統壓垮。

1.5 請求延遲

請求延遲並不是一個很容易統計的指標，下圖是一個電商購物系統：這個圖中，我們假設組合服務會併發地調用下面的訂單、庫存和賬戶服務。客戶端發出請求後，組合服務處理請求需要花費 2 秒的處理時間，賬戶服務需要花費 3 秒的處理時間，那客戶端配置的 read timeout 最小是 5 秒。

監控系統需要設置一個閾值來監控，比如 1 秒內如果有 100 個請求延遲都大於了 5 秒就觸發報警，讓系統維護人員去查找問題。

❝

客戶端設置的 read timeout 不能太大，如果因爲服務端故障導致延遲，要保證 fail-fast，防止因爲資源不能釋放造成系統性能大服務降低。

❞

1.6 監控注意事項

監控是爲了能讓系統維護人員快速發現生產問題並定位到原因，不過監控系統也有幾個指標需要考慮：

10 個請求，有 9 個延遲都是 1 秒，但有 1 個延遲是 10 秒，所以平均值參考意義並不大。

❝

可以採用按照區間分組的方式，比如延遲 1 秒以內的請求數量，1-2 秒的請求數量，2-3 秒的請求數量分組進行統計，按照指數級增長的方式來配置監控閾值。

❞

故障管理

2.1 常見故障原因

故障發生的原因五花八門，但常見的無非下面幾種：

2.2 應對策略

應對故障，我們分兩步走：

2.2.1 軟件升級故障

升級帶來的故障，有的是上線後能很快暴露的。有的是上線很長時間纔會暴露，比如有的業務代碼可能之前一直執行不到。

對於第一種情況，可以採用灰度發佈的方式進行驗證解決。

對於第二種情況，完全避免是很難的，我們只能最大限度的提高測試用例覆蓋率。

2.2.2 硬件資源故障

這類故障主要分爲兩類：

對於第一種故障一般用監控告警的方式來通知責任人處理，處理的方式主要是增加資源，找出消耗資源嚴重的程序進行優化。

對於第二種故障需要運維人員對硬件資源進行記錄和監控，對於老化的資源及時進行更換。

2.3 系統過載

系統過載可能是遇到秒殺之類的突增流量，也可能是隨着業務發展慢慢地超過系統承受能力，可以使用增加資源或者限流的方式來應對。

2.4 惡意攻擊

惡意攻擊的類型非常多，比如 DDOS 攻擊、惡意軟件、瀏覽器攻擊等。

針對惡意攻擊，防止手段也很多，比如對請求報文進行加密、引入專業的網絡安全防火牆、定期安全掃描、核心服務部署在非默認端口等。

2.5 基礎軟件故障

如下圖所示，除了業務服務外每個組件都是基礎軟件，都需要考慮高可用。

發佈管理

發佈通常指軟硬件的升級，包括業務系統版本升級、基礎軟件升級、硬件環境升級等。作爲程序員，本文講的升級是針對業務系統的升級。

3.1 發佈流程

一般情況下，業務系統升級流程如下：

發佈到生產環境，驗證沒有問題表示發佈成功。

3.2 發佈質量

在升級軟件的時候，發佈質量非常重要，爲保證發佈質量需要注意下面這些問題。

3.2.1 CheckList

爲了保證發佈質量，發佈前維護一份 CheckList，並且開發團隊對所有的問題進行確認。等這份清單都確認完成後進行構建發佈。下面是一些比較典型的問題：

3.2.2 灰度發佈

灰度發佈是指在黑與白之間，能夠平滑過渡的一種發佈方式。如下圖：升級時採用金絲雀部署的方式，先把其中一個 server 作爲金絲雀進行發佈升級，這個 server 在生產環境運行後沒有問題，再升級其他的 server。有問題則進行回滾。

3.2.2 藍綠部署

藍綠部署的方式如下圖：升級之前客戶端的請求發送到綠色服務上，升級發佈之後，通過負載均衡把請求轉到藍色系統，綠色系統暫時不下線，如果生產測試沒有問題，則下線綠色系統，否則切回綠色系統。

❝

藍綠部署跟金絲雀部署的區別是，金絲雀部署不用增加新的機器，而藍綠部署相當於是增加了一套新機器，需要額外的資源成本。

❞

3.2.4 ab 測試

ab 測試是指在生產環境發佈多個版本，主要目的是測試不同版本的不同效果。比如頁面樣式不一樣，操作流程不一樣，這樣可以讓用戶選擇一個最喜歡的版本作爲最終版本。如下圖：三個顏色的服務部署了，客戶端的請求分部發送到跟自己顏色一樣的服務上。

❝

ab 測試的版本都是已經是驗證沒有問題的，這點不同於灰度發佈。

❞

3.2.4 配置變更

好多時候我們把配置寫在代碼裏，比如 yaml 文件。這樣我們修改配置後就需要重新發布新版本。如果配置修改頻繁，可以考慮下面兩種方法：

容量管理

在 2.3 節中講到系統過載導致的系統故障。容量管理是保證系統上線後穩定運行的一個重要環節，主要是保證系統流量不超過系統能承受的閾值，防止系統奔潰。一般情況下，系統容量超載的原因如下：

4.1 重試

對於一些失敗的請求進行重試，能夠很好地增加系統的用戶體驗。重試一般分爲兩類，一類是對連接超時的請求，一類是對響應超時的請求。

對於連接超時的請求，可能是網絡瞬時故障造成的，這種情況下重試並不會對服務端造成壓力，因爲失敗的請求壓根就沒有到達服務端。

但是對於響應超時的請求，如果進行重試，可能會給服務端帶來額外的壓力。如下圖：正常情況下，客戶端先調用服務 A，服務 A 再調用服務 B，服務 B 只被調用了一次。

如果服務 B 響應慢導致超時，客戶端配置了失敗重試 2 次，服務 A 也配置了失敗重試 2 次，在服務 B 最終不能響應的情況下，服務 B 最終被調了 9 次。

在大型分佈式系統中，如果調用鏈很長，每個服務都配置了重試，那重試會給調用鏈下游服務造成巨大的壓力甚至讓系統奔潰。可見重試不是越多越好，合理的設置重試對系統有保護作用。

對於重試，有如下 3 個建議：

4.2 突增流量

對於突增流量，是很難提前規劃到的。

遇到突增的流量時，我們可以先考慮增加資源。以 K8S 爲例，如果原來有 2 個 pod，使用 deploy 編排擴容到 4 個 pod。命令如下：

kubectl scale deployment springboot-deployment --replicas=4

如果資源已經用完了，那就得考慮限流了。推薦幾個限流框架：

4.3 容量規劃

系統建設初期做好容量規劃是非常重要的。

可以根據業務量來估算系統的 QPS，基於 QPS 進行壓力測試。針對壓力測試的結果估算的容量，並不一定能應對生產環境的真實場景和突發情況，可以根據預估容量給出預留資源，比如 2 倍容量。

4.4 服務降級

服務降級對於服務端來說，可以有三種方式：

總結

微服務化的架構給系統帶來了很多好處，但同時也帶來了一些技術上的挑戰。這些挑戰包括服務註冊與發現、負載均衡、監控管理、發佈升級、訪問控制等。而服務治理就是對這些問題進行管理和預防，保證系統持續平穩地運行。

本文所講的服務治理方案，也算是傳統意義上的方案，有時會有一些代碼的侵入，而框架的選擇也會對編程語言有限制。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/1sFYTtruqd9Dcmw4s6IY8g

猜你喜歡