我們知道，在單體應用的架構下一旦程序發生了故障，那麼整個應用可能就沒法使用了，所以我們要把單體應用拆分成具有多個服務的微服務架構，來減少故障的影響範圍。但是在微服務架構下，有一個新的問題就是，由於服務數變多了，假設單個服務的故障率是不變的，那麼整體微服務系統的故障率其實是提高了的。
比如：假設單個服務的故障率是0.01%，也就是可用性是99.99%，如果我們總共有10個微服務，那麼我們整體的可用性就是99.99%的十次方，得到的就是99.90%的可用性（也就是故障率爲0.1%）。可見，相對於之前的單體應用，整個系統可能發生故障的風險大幅提升。
那麼在這種情況下，我們應該怎麼去保證微服務架構的可用性呢？
其實我們參考造船行業對船艙進水風險的隔離方法，如上圖。
造船行業有一個專業術語叫做「艙壁隔離」，利用艙壁將不同的船艙隔離起來，如果某一個船艙進了水，那麼就可以立即封閉艙門，形成艙壁隔離，只損失那一個船艙，其他船艙不受影響，整個船隻還是可以正常航行。
對應到微服務架構中，我們要做的就是最大限度的隔離單個服務的風險，也就是「 容錯隔離 」的方法。
微服務架構中可用性風險有哪些？
在聊「容錯隔離」方法之前，我們先來看一下微服務架構中，常見的可用性風險到底有哪些吧，知道了有哪些風險我們才知道該如何去規避、去隔離風險。
我們可以從項目部署規模的角度去分析風險：
-
單機可用性風險： 這個很好理解，就是微服務部署所在的某一臺機器出現了故障，造成的可用性風險。這種風險發生率很高，因爲單機器在運維中本身就容易發生各種故障，例如 硬盤壞了、機器電源故障等等，這些都是時有發生的事情。不過雖然這種風險發生率高，但危害有限，因爲我們大多數服務並不只部署在一臺機器上，可能多臺都有，因此只需要做好監控，發現故障之後，及時的將這臺故障機器從服務集羣中剔除即可，等修復了再重新上線到集羣裏。
-
單機房可用性風險： 這種風險的概率比單機器的要低很多，但是也不是完全不可能發生，在實際情況中，還是有一定概率的。比如最爲常見的就是通往機房的光纖被挖斷了，前段時間支付寶所在機房不是就發生過光纖被挖麼。咱們全國大小城市都在瘋狂的進行基建，修橋修路修房子，GDP就這麼搞起來了，地下的光纖挖斷幾根不是再正常不過的事情了麼，哈哈。如果我們的服務全部都部署在單個機房，而機房又出故障了，那就沒轍了。好在，現在大多數中大型項目都會採用多機房部署的方案，比如同城雙活、異地多活等。一旦某個機房出現了故障不可用了，咱們立即採用切換路由的方式，把這個機房的流量切到其它機房裏。
-
跨機房集羣可用性風險： 既然都跨機房集羣了，可用性理論上應該沒啥問題啊。但要知道這是在物理層面沒有問題了，如果咱們的代碼有坑，或者因爲特殊原因用戶流量激增，導致我們的服務扛不住了，那在跨機房集羣的情況下一樣會不可用。但如果我們提前做好了「容錯隔離」的一些方案，比如 限流、熔斷 等等，用上這些方法還是可以保證一部分服務或者一部分用戶的訪問是正常。
容錯隔離的方法有哪些
好了，上面講了微服務架構中可能遇到這麼多的可用性風險，並且也知道了「容錯隔離」的重要性，下面我們再來看看常見的「容錯隔離」方法有哪些：
- 超時： 這也是簡單的容錯方式。就是指在服務之間調用時，設置一個 主動超時時間，超過了這個時間閾值後，如果“被依賴的服務”還沒有返回數據的話，“調用者”就主動放棄，防止因“被依賴的服務”的故障所影響。
- 限流： 顧名思義，就是限制最大流量。系統能提供的最大併發有限，同時來的請求又太多，服務不過來啊，就只好排隊限流了，就跟去景點排隊買票、去商場喫飯排隊等號的道理一樣一樣兒的。
- 降級： 這個與限流類似，一樣是流量太多，系統服務不過來。這個時候可以可將不是那麼重要的功能模塊進行降級處理，停止服務，這樣可以釋放出更多的資源供給核心功能的去用。同時還可以對用戶分層處理，優先處理重要用戶的請求，比如VIP收費用戶等。
- 延遲處理： 這個方式是指設置一個流量緩衝池，所有的請求先進入這個緩衝池等待處理，真正的服務處理方按順序從這個緩衝池中取出請求依次處理，這種方式可以減輕後端服務的壓力，但是對用戶來說體驗上有延遲。
- 熔斷： 可以理解成就像電閘的保險絲一樣，當流量過大或者錯誤率過大的時候，保險絲就熔斷了，鏈路就斷開了，不提供服務了。當流量恢復正常，或者後端服務穩定了，保險絲會自動街上（熔斷閉合），服務又可以正常提供了。這是一種很好的保護後端微服務的一種方式。
熔斷技術中有個很重要的概念就是：斷路器，說到熔斷器，java技術棧的同學第一時間會想到Hystrix。熔斷器有三種狀態：
- Closed（閉合狀態，也就是正常狀態）
- Open（開啓狀態，也就是當後端服務出故障後鏈路斷開，不提供服務的狀態）
- Half-Open(半閉合狀態，就是允許一小部分流量進行嘗試，嘗試後發現服務正常就轉爲Closed狀態，服務依舊不正常就轉爲Open狀態)。
容錯和容災
容災
通過在相隔較遠的異地，建立兩套或多套功能相同的IT系統，互相之間可以進行健康狀態監視和功能切換，當一處系統因意外（如火災、地震等）停止工作時，整個應用系統可以切換到另一處，使得該系統功能可以繼續正常工作。
容災可分爲三個層次：
- 數據容災： 就是數據遠程的備份，災難發生時，只保證數據不丟失，但是業務會中斷，慢慢恢復、重建。
- 應用容災： 在數據備份或同步的基礎上，還要建立一套相同的應用系統，除了涉及數據，還要涉及到主機、網絡、存儲、OS、軟件等等。災難發生時，業務能快速回復甚至不中斷
- 業務容災： 不僅包含了IT應用系統，還要包括辦公場地、電話通訊、後勤保障等等，跟業務相關的一切都要考慮。
容錯
容錯（fault tolerance）指的是， 發生故障時，系統還能繼續運行。
例如： 飛機有四個引擎，如果一個引擎壞了，剩下三個引擎，還能繼續飛，這就是"容錯"。同樣的，汽車的一個輪子扎破了，剩下三個輪子，也還是勉強能行駛。
容錯的目的是，發生故障時，系統的運行水平可能有所下降，但是依然可用，不會完全失敗。
雪崩效應
微服務架構的應用系統通常包含多個服務層。微服務之間通過網絡進行通信，從而支撐起整個應用系統，因此，微服務之間難免存在依賴關係。我們知道， 任何微服務並非100%可用，網絡往往也很脆弱，因此難免有些請求會失敗。
我們常把“基礎服務故障”導致“級聯故障”的現象稱爲雪崩效應。雪崩效應描述的是提供者不可用導致消費者不可用，並將不可用逐漸放大的過程。
例如： 服務D是一個輔助類型服務，整個業務不依賴於D服務，某天D服務突然響應時間變長，導致了核心服務C響應時間變長，其上請求越積越多，C服務也出現了響應變慢的情況，由於A，B強依賴於服務C，故而一個無關緊要的服務卻影響了整個系統的可用。因此，當D不可用引起C不用，並將不可用像滾雪球一樣放大到A和B時，雪崩效應就形成了。
雪崩是系統中的蝴蝶效應導致其發生的原因多種多樣，有不合理的容量設計，或者是高併發下某一個方法響應變慢，亦或是某臺機器的資源耗盡。從源頭上我們無法完全杜絕雪崩源頭的發生，但是雪崩的根本原因來源於服務之間的強依賴，所以我們可以提前評估，做好熔斷，隔離，限流。