微服務架構下服務故障處了解決方案（上）

微服務優勢之一是可縮小故障影響範圍，局限在某個服務中。那一個服務出現故障該如何處理？

1 叢集故障

可能整個叢集都會故障，無法再對外提供服務。

1.1 故障原因

代碼bug

比如OOM

突發的流量沖擊，超出了系統的最大承載能力

比如秒殺，會在某個時刻瞬間湧入大量流量，超出系統承載能力

1.2 解決方案

1.2.1 限流

系統所能承載流量根據叢集規模是固定的，稱為系統最大容量。當真實流量超過系統最大容量，系統響應就會變慢，服務調用出現大量逾時，使用者就會感覺卡頓、無響應。是以，應根據系統最大容量，給系統設定門檻值，超過門檻值的請求會被自動丢棄，便可保證系統服務正常。

通常一個微服務系統會同時提供多個服務，每個服務在同一時刻的請求量也不同，很可能系統中某服務的請求量激增，占用系統大部分資源，導緻其他服務無資源可用。

是以，要針對系統中每個服務的請求量設定門檻值，超過門檻值的請求也要丢棄，不至于因為一個服務影響其他服務。

可用如下名額衡量服務的請求量：

QPS

工作線程數

QPS因不同服務的響應快慢不同，是以系統能承載QPS相差大，是以一般選擇工作線程數作為限流名額，給系統設定

總的最大工作線程數

單個服務的最大工作線程數

如此，無論是系統總請求量過大導緻整體工作線程數量達到最大工作線程數，還是某服務的請求量超過單個服務的最大工作線程數，都會被限流。

1.2.2 降級

通過停止系統中的某些功能，保證系統整體的可用性，屬一種被動防禦方案，因為一般是系統已故障後所采取的一種止損操作。

如何實作

通過開關，在系統運作的記憶體中開辟一塊區域，專門用于存儲開關狀态：開啟還是關閉。并且需監聽某端口，通過該端口可向系統下發指令以改變記憶體中開關狀态。當開關開啟時，業務的某段邏輯就不再執行，而正常情況下，開關是關閉的狀态。

适用場景

新增的業務邏輯

因為新增的業務邏輯相對來說不成熟，充滿風險，需加開關控制新業務邏輯是否執行

依賴的服務或資源

因依賴的服務或資源不總是可靠，最好有開關控制是否對依賴服務或資源發起調用，以保證即使依賴出現問題，也能降級避免影響

分級

一級降級，對業務影響最小的

故障時，先執行一級降級，是以一級降級也可設定成自動降級而無需人工

二級降級，對業務有一定影響

故障時，若一級降級起不了啥作用，可采取人工

三級降級，對業務較大影響

這種降級要麼對重大影響金錢交易，要麼嚴重影響使用者體驗