在分布式系統中，由于網絡條件以及系統自身缺陷等問題，服務與服務的調用過程難免會出現失敗。為了把這種失敗的影響程度降到最小，目前，業界有兩種主流的最佳實踐方案，分別是集群容錯和服務隔離。這節課，我就帶你利用這兩種方案來解決服務雪崩效應，幫你提升分布式系統服務訪問的可靠性。

假如你正在設計和開發一個分布式服務系統，該系統中存在一批獨立運行的服務實例。圍繞某一個具體的業務場景，通常都會涉及多個服務之間的交互。

圖片

在這個典型場景中，存在一個從服務 E 到服務 A 的完整調用鏈路。如果其中有一個服務出現了宕機，那么整個調用鏈路中的其它服務因為資源的競爭也會處于不可用狀態，這種擴散效應就是所謂的服務雪崩效應。

我們該怎么應對這種服務雪崩效應呢？

集群容錯策略

目前主流的應對策略是提供服務訪問的容錯（Fault Tolerance）機制。想要實現容錯機制，集群就要做到冗余，也就是讓每個服務具備多個實例。這樣，當一個服務實例出現問題時，請求還可以嘗試訪問其它服務實例。

我們知道，集群的構建相當于已經具備了冗余的條件，而要想在訪問一個服務實例出現問題時確定下一個想要訪問的服務實例，就涉及具體的集群容錯策略了。

常見的集群容錯策略包括 Failover、Failback、Failsafe 和 Failfast 等。下面我們一一來了解。

Failover 是最常見、最實用的集群容錯策略。它又叫失效轉移策略，當發生服務調用異常時，可以重新在集群中查找下一個可用的服務實例。同時，為了防止無限重試，開發人員通常會對失敗重試最大次數進行限制，一般控制在 3 次之內。

圖片

對應的，Failback 可以理解為失效自動恢復。當請求失敗時，系統會把這個失敗請求記錄下來，并通過一定的定時機制進行重試。這種策略適用于那些對時效性要求不高的場景，例如消息通知。

而 Failsafe 代表失敗安全策略，當獲取服務調用異常時，直接忽略。它通常將異常寫入審計日志等媒介，確保后續可以根據日志記錄找到引起異常的原因并解決。

Failfast 也叫快速失敗策略，它在獲取服務調用異常時，立即報錯。顯然，Failfast 已經徹底放棄了重試機制，等同于沒有容錯，可以用于非冪等性的寫入操作，這是一種常見的應用場景。而在特定場景中也可以使用該策略確保非核心業務服務只調用一次，為重要的核心服務節約寶貴時間。

后三種集群容錯策略很容易混淆，它們之間的區別你可以參考這張圖：

圖片

除了這些最常見的集群容錯機制之外，在諸如 Dubbo 等主流分布式服務框架中，開發人員還實現了一些特殊的策略。比如 Forking 策略代表一種分支調用機制，在這種機制下請求會同時發送給集群中的多個服務實例，只要有一個服務實例響應成功就行。再比如 Broadcast 策略，代表的是一種廣播機制，這種機制同樣也會調用所有服務實例，但只有在所有調用都成功的情況下才會返回成功。從適用場景上講，Forking 機制適用于實時性要求較高的場景，而 Broadcast 機制通常用于實現消息通知，不是簡單的遠程調用。

服務隔離策略

除了集群容錯策略外，應對服務雪崩還有一種有效手段，就是服務隔離。

在架構設計領域存在一個艙壁隔離（Bulkhead Isolation）的架構模式，服務隔離的設計思想真是來自于此。那么，什么是艙壁隔離？你可以想象一艘船，這艘船有 8 個船艙，正常情況下，船艙壁是隔離海水或湖水的，如果一個船艙破了，進水了，那么只損失一個船艙，其它船艙可以不受影響。比如這張示意圖，2 號和 8 號船艙雖然已經出現問題，但不影響其它 6 個船艙。

圖片

結合分布式服務架構中的應用場景，艙壁隔離模式的具體體現就是各種服務隔離機制。

其實，隔離本質上是對系統中的服務進行分割，這樣當系統發生故障的時候，就能控制影響范圍。也就是說，隔離可以保證發生故障后只有出問題的服務不可用，其它服務仍然可用。

圖片

我們一起來看一下服務隔離的基本思路圖。圖中的隔離媒介是服務隔離實現的關鍵，針對它業界有一些成熟的實現方案，常見的包括線程隔離、進程隔離、集群隔離以及讀寫隔離等。

線程隔離

我們先來看看最常見的線程隔離。我們知道。系統執行一個請求的基本單位是線程，所以使用線程隔離就相當于對請求與請求之間的資源進行了隔離。在日常開發過程中，我們通常使用線程池來創建線程，因此線程隔離的主要實現手段就是借助于線程池。當把不同的請求分配到不同的線程池進行處理時，就算一個線程池出現了問題，也不會把問題擴散到其它線程池。各個線程池之間相互獨立，各自確保自身業務的處理過程和可用性。

線程隔離可以說是實現服務隔離的基礎，我們通過一個案例來進一步介紹它的工作場景和原理。假如系統存在服務 A、服務 B 和服務 C 這 3 個服務，我們通過設置運行時參數得到這 3 個服務一共使用 300 個線程，客戶端調用這 3 個服務會共享線程池。

圖片

你看這張示例圖，如果服務 A 出現了問題，那么所有訪問它的線程就會因為同步等待響應結果而不斷消耗線程資源，最終導致雪崩效應：

圖片

這里邊框為虛線的服務代表不可用，我們可以看到因為服務 A 不可用導致共享的 300 線程全部耗盡，從而影響了其它兩個服務。因此基于線程隔離機制，我們就可以為每個服務分別創建獨立的線程池，從而對資源進行隔離，這樣就能夠避免雪崩效應的產生。

下面，我們為三個服務都獨立分配 100 個線程再來看看：

圖片

調整之后，我們會發現就算服務 A 中的 100 個線程都已經被消耗殆盡，其它服務中的請求過程也不會受到影響，因為它們運行在獨立的線程池中。

進程隔離

講完線程隔離，我們再來看進程隔離。進程隔離把資源的隔離范圍從線程上升到進程，在 Java 世界中，相當于就是上升到了 JVM 級別。這樣，我們就可以把整個業務系統拆分為多個獨立的子系統，每個子系統完成自身的請求，而不依賴于其它子系統，目前主流的微服務架構就是這一隔離機制最好的實踐。

集群隔離

集群隔離是進程隔離的升級版，將某些服務單獨部署成集群，或對于某些服務可以進行分組集群管理，某一個集群出現問題之后就不會影響到其它集群，從而實現了故障隔離，效果圖如下所示：

圖片

讀寫隔離

讀寫隔離也是一種常見的隔離技術，當用于讀取操作的服務器出現故障時，寫服務器照常可以運作，反之也是一樣。對于離線分析類的應用場景而言，讀寫隔離可以很好地控制讀取操作瓶頸和對寫入操作的影響。

實際運用中，讀寫隔離可以有不同的表現形式。例如，當使用 MongoDB 進行海量數據存儲時，我們可以采用熱庫和存檔庫概念，將新寫入的數據同時存儲到熱庫和存檔庫。熱庫只存儲最近一個月的數據，而存檔庫則保存所有的歷史數據。當我們想對歷史數據進行讀取處理時，可以確保熱庫不受影響。

總結

總的來說，在日常開發過程中，你可以使用本文介紹的集群容錯和服務隔離機制來為分布式系統提升服務訪問的可靠性。我再給你梳理一下關鍵知識點。

在分布式系統中，錯誤總會發生，處理不好就會形成雪崩效應，我們應對雪崩效應的核心思想是努力控制它的影響范圍。一方面，我們可以借助于集群機制以及 Failover、Failback、Failsafe 和 Failfast 等機制來實現集群容錯；另一方面，我們可以使用線程隔離、進程隔離、集群隔離以及讀寫隔離等等策略來實現服務隔離。針對日常場景，集群容錯一般都是主流框架所默認提供的機制。而服務隔離方面，我建議你合理利用線程隔離和進程隔離來綜合使用不同粒度的隔離機制，確保服務的高可用。