先介紹幾個概念，同步一下認知：
容災：是指系統冗余部署，當一處由于意外停止工作，整個系統應用還可以正常工作。
容錯：是指在運行中出現錯誤（如上下游故障或概率性失敗）仍可正常提供服務。
可用性：描述的是系統可提供服務的時間長短。用公式來說就是A=MTBF/(MTBF+MTTR)，即正常工作時間/(正常工作時間+故障時間)。
可靠性：描述的是系統指定時間單位內無故障的次數。比如：一年365天，以天為單位來衡量。有天發生了故障，哪怕只有1秒，這天算不可靠。其他沒有故障的是可靠的。
穩定性：這個業界沒有明確的定義，我的理解是：在受到各種干擾時仍然能夠提供符合預期的服務的能力。
從要求的嚴格程度上：可用性<可靠性<穩定性。
可用性和可靠性更側重于容災，而對穩定性同時包含容災和容錯

容錯和容災
一、容災
增加冗余性，通過在相隔較遠的異地，建立兩套或多套功能相同的IT系統，互相之間可以進行健康狀態監視和功能切換，當一處系統因意外（如火災、地震等）停止工作時，整個應用系統可以切換到另一處，使得該系統功能可以繼續正常工作。

容災可分為三個層次：

1.數據容災： 就是數據遠程的備份，災難發生時，只保證數據不丟失，但是業務會中斷，慢慢恢復、重建。
2.應用容災： 在數據備份或同步的基礎上，還要建立一套相同的應用系統，除了涉及數據，還要涉及到主機、網絡、存儲、OS、軟件等等。災難發生時，業務能快速回復甚至不中斷
3.業務容災： 不僅包含了IT應用系統，還要包括辦公場地、電話通訊、后勤保障等等，跟業務相關的一切都要考慮。

二、容錯
容錯（fault tolerance）指的是， 發生故障時，系統還能繼續運行。

例如： 飛機有四個引擎，如果一個引擎壞了，剩下三個引擎，還能繼續飛，這就是"容錯"。同樣的，汽車的一個輪子扎破了，剩下三個輪子，也還是勉強能行駛。

容錯的目的是，發生故障時，系統的運行水平可能有所下降，但是依然可用，不會完全失敗。

雪崩效應
微服務架構的應用系統通常包含多個服務層。微服務之間通過網絡進行通信，從而支撐起整個應用系統，因此，微服務之間難免存在依賴關系。我們知道， 任何微服務并非100%可用，網絡往往也很脆弱，因此難免有些請求會失敗。

我們常把“基礎服務故障”導致“級聯故障”的現象稱為雪崩效應。雪崩效應描述的是提供者不可用導致消費者不可用，并將不可用逐漸放大的過程。

例如： 服務D是一個輔助類型服務，整個業務不依賴于D服務，某天D服務突然響應時間變長，導致了核心服務C響應時間變長，其上請求越積越多，C服務也出現了響應變慢的情況，由于A，B強依賴于服務C，故而一個無關緊要的服務卻影響了整個系統的可用。因此，當D不可用引起C不用，并將不可用像滾雪球一樣放大到A和B時，雪崩效應就形成了。

雪崩是系統中的蝴蝶效應導致其發生的原因多種多樣，有不合理的容量設計，或者是高并發下某一個方法響應變慢，亦或是某臺機器的資源耗盡。從源頭上我們無法完全杜絕雪崩源頭的發生，但是雪崩的根本原因來源于服務之間的強依賴，所以我們可以提前評估，做好熔斷，隔離，限流。

三、容錯隔離的方法有哪些
我們再來看看常見的「容錯隔離」方法有哪些：

超時： 這也是簡單的容錯方式。就是指在服務之間調用時，設置一個 主動超時時間，超過了這個時間閾值后，如果“被依賴的服務”還沒有返回數據的話，“調用者”就主動放棄，防止因“被依賴的服務”的故障所影響。
限流： 顧名思義，就是限制最大流量。系統能提供的最大并發有限，同時來的請求又太多，服務不過來啊，就只好排隊限流了，就跟去景點排隊買票、去商場吃飯排隊等號的道理一樣一樣兒的。
降級： 這個與限流類似，一樣是流量太多，系統服務不過來。這個時候可以可將不是那么重要的功能模塊進行降級處理，停止服務，這樣可以釋放出更多的資源供給核心功能的去用。同時還可以對用戶分層處理，優先處理重要用戶的請求，比如VIP收費用戶等。
延遲處理： 這個方式是指設置一個流量緩沖池，所有的請求先進入這個緩沖池等待處理，真正的服務處理方按順序從這個緩沖池中取出請求依次處理，這種方式可以減輕后端服務的壓力，但是對用戶來說體驗上有延遲。
熔斷： 可以理解成就像電閘的保險絲一樣，當流量過大或者錯誤率過大的時候，保險絲就熔斷了，鏈路就斷開了，不提供服務了。當流量恢復正常，或者后端服務穩定了，保險絲會自動街上（熔斷閉合），服務又可以正常提供了。這是一種很好的保護后端微服務的一種方式。
熔斷技術中有個很重要的概念就是：斷路器，說到熔斷器，java技術棧的同學第一時間會想到Hystrix。熔斷器有三種狀態：

Closed（閉合狀態，也就是正常狀態）
Open（開啟狀態，也就是當后端服務出故障后鏈路斷開，不提供服務的狀態）
Half-Open(半閉合狀態，就是允許一小部分流量進行嘗試，嘗試后發現服務正常就轉為Closed狀態，服務依舊不正常就轉為Open狀態)。

五、微服務架構中可用性風險有哪些？
我們先來看一下微服務架構中，常見的可用性風險到底有哪些吧，知道了有哪些風險我們才知道該如何去規避、去隔離風險。

我們可以從項目部署規模的角度去分析風險：

單機可用性風險： 這個很好理解，就是微服務部署所在的某一臺機器出現了故障，造成的可用性風險。這種風險發生率很高，因為單機器在運維中本身就容易發生各種故障，例如 硬盤壞了、機器電源故障等等，這些都是時有發生的事情。不過雖然這種風險發生率高，但危害有限，因為我們大多數服務并不只部署在一臺機器上，可能多臺都有，因此只需要做好監控，發現故障之后，及時的將這臺故障機器從服務集群中剔除即可，等修復了再重新上線到集群里。

單機房可用性風險： 這種風險的概率比單機器的要低很多，但是也不是完全不可能發生，在實際情況中，還是有一定概率的。比如最為常見的就是通往機房的光纖被挖斷了，前段時間支付寶所在機房不是就發生過光纖被挖么。咱們全國大小城市都在瘋狂的進行基建，修橋修路修房子，GDP就這么搞起來了，地下的光纖挖斷幾根不是再正常不過的事情了么，哈哈。如果我們的服務全部都部署在單個機房，而機房又出故障了，那就沒轍了。好在，現在大多數中大型項目都會采用多機房部署的方案，比如同城雙活、異地多活等。一旦某個機房出現了故障不可用了，咱們立即采用切換路由的方式，把這個機房的流量切到其它機房里。

跨機房集群可用性風險： 既然都跨機房集群了，可用性理論上應該沒啥問題啊。但要知道這是在物理層面沒有問題了，如果咱們的代碼有坑，或者因為特殊原因用戶流量激增，導致我們的服務扛不住了，那在跨機房集群的情況下一樣會不可用。但如果我們提前做好了「容錯隔離」的一些方案，比如 限流、熔斷 等等，用上這些方法還是可以保證一部分服務或者一部分用戶的訪問是正常

原文鏈接：https://blog.csdn.net/u010979642/article/details/106948757

總結

以上是生活随笔為你收集整理的系统容错和容灾简要说明的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。