微服務架構之「 容錯隔離 」

咱們知道，在單體應用的架構下一旦程序發生了故障，那麼整個應用可能就無法使用了，因此咱們要把單體應用拆分紅具備多個服務的微服務架構，來減小故障的影響範圍。可是在微服務架構下，有一個新的問題就是，因爲服務數變多了，假設單個服務的故障率是不變的，那麼總體微服務系統的故障率實際上是提升了的。

好比：假設單個服務的故障率是0.01%，也就是可用性是99.99%，若是咱們總共有10個微服務，那麼咱們總體的可用性就是99.99%的十次方，獲得的就是99.90%的可用性（也就是故障率爲0.1%）。可見，相對於以前的單體應用，整個系統可能發生故障的風險大幅提高。

那麼在這種狀況下，咱們應該怎麼去保證微服務架構的可用性呢？

其實咱們參考造船行業對船艙進水風險的隔離方法，如上圖。

造船行業有一個專業術語叫作「艙壁隔離」，利用艙壁將不一樣的船艙隔離起來，若是某一個船艙進了水，那麼就能夠當即封閉艙門，造成艙壁隔離，只損失那一個船艙，其餘船艙不受影響，整個船隻仍是能夠正常航行。

對應到微服務架構中，咱們要作的就是最大限度的隔離單個服務的風險，也就是「 容錯隔離 」的方法。

1、微服務架構中可用性風險有哪些？

在聊「容錯隔離」方法以前，咱們先來看一下微服務架構中，常見的可用性風險到底有哪些吧，知道了有哪些風險咱們才知道該如何去規避、去隔離風險。

咱們能夠從項目部署規模的角度去分析風險：

1. 單機可用性風險：

   這個很好理解，就是微服務部署所在的某一臺機器出現了故障，形成的可用性風險。這種風險發生率很高，由於單機器在運維中自己就容易發生各類故障，例如 硬盤壞了、機器電源故障等等，這些都是時有發生的事情。不過雖然這種風險發生率高，但危害有限，由於咱們大多數服務並不僅部署在一臺機器上，可能多臺都有，所以只須要作好監控，發現故障以後，及時的將這臺故障機器從服務集羣中剔除便可，等修復了再從新上線到集羣裏。

2. 單機房可用性風險：

   這種風險的機率比單機器的要低不少，可是也不是徹底不可能發生，在實際狀況中，仍是有必定機率的。好比最爲常見的就是通往機房的光纖被挖斷了，前段時間支付寶所在機房不是就發生過光纖被挖麼。

   我們全國大小城市都在瘋狂的進行基建，修橋修路修房子，GDP就這麼搞起來了，地下的光纖挖斷幾根不是再正常不過的事情了麼，哈哈。

   若是咱們的服務所有都部署在單個機房，而機房又出故障了，那就沒轍了。好在，如今大多數中大型項目都會採用多機房部署的方案，好比同城雙活、異地多活等。一旦某個機房出現了故障不可用了，我們當即採用切換路由的方式，把這個機房的流量切到其它機房裏。

3. 跨機房集羣可用性風險：

   既然都跨機房集羣了，可用性理論上應該沒啥問題啊。但要知道這是在物理層面沒有問題了，若是我們的代碼有坑，或者由於特殊緣由用戶流量激增，致使咱們的服務扛不住了，那在跨機房集羣的狀況下同樣會不可用。但若是咱們提早作好了「容錯隔離」的一些方案，好比 限流、熔斷 等等，用上這些方法仍是能夠保證一部分服務或者一部分用戶的訪問是正常。

2、「 容錯隔離 」的方法有哪些？

好了，上面講了微服務架構中可能遇到這麼多的可用性風險，而且也知道了「容錯隔離」的重要性，下面咱們再來看看常見的「容錯隔離」方法有哪些：

1. 超時：

   這也是簡單的容錯方式。就是指在服務之間調用時，設置一個 主動超時時間，超過了這個時間閾值後，若是「被依賴的服務」尚未返回數據的話，「調用者」就主動放棄，防止因「被依賴的服務」的故障所影響。

2. 限流

   顧名思義，就是限制最大流量。系統能提供的最大併發有限，同時來的請求又太多，服務不過來啊，就只好排隊限流了，就跟去景點排隊買票、去商場吃飯排隊等號的道理同樣同樣兒的。

3. 降級

   這個與限流相似，同樣是流量太多，系統服務不過來。這個時候能夠可將不是那麼重要的功能模塊進行降級處理，中止服務，這樣能夠釋放出更多的資源供給核心功能的去用。同時還能夠對用戶分層處理，優先處理重要用戶的請求，好比VIP收費用戶等。

4. 延遲處理

   這個方式是指設置一個流量緩衝池，全部的請求先進入這個緩衝池等待處理，真正的服務處理方按順序從這個緩衝池中取出請求依次處理，這種方式能夠減輕後端服務的壓力，可是對用戶來講體驗上有延遲。

5. 熔斷

   能夠理解成就像電閘的保險絲同樣，當流量過大或者錯誤率過大的時候，保險絲就熔斷了，鏈路就斷開了，不提供服務了。當流量恢復正常，或者後端服務穩定了，保險絲會自動街上（熔斷閉合），服務又能夠正常提供了。這是一種很好的保護後端微服務的一種方式。

   熔斷技術中有個很重要的概念就是：斷路器，能夠參考下圖：

   斷路器其實就是一個狀態機原理，有三種狀態：Closed（閉合狀態，也就是正常狀態）、Open（開啓狀態，也就是當後端服務出故障後鏈路斷開，不提供服務的狀態）、Half-Open(半閉合狀態，就是容許一小部分流量進行嘗試，嘗試後發現服務正常就轉爲Closed狀態，服務依舊不正常就轉爲Open狀態)。

3、「 容錯隔離 」的應用？

在容錯隔離或者說熔斷技術方面作得最出名的框架就是 Hystrix 了。Hystrix是由Netflix開源，在業內應用很是普遍。

下面是Hystrix的原理流程圖：

這是新版流程，比以前舊版本又複雜不少，若是不講解一下，估計不少人都不容易看懂。

圖中標註了數字1-9，能夠按照這個數字順序去理解這個流程。

當咱們使用了Hystrix以後，請求會被封裝到HystrixCommand中，這也就是第一步。而後第二步就是開始執行請求，Hystrix支持同步執行(圖中.execute方法)、異步執行(圖中.queue方法)和響應式執行(圖中.observer)。而後第三步判斷緩存，若是存在與緩存中，則直接返回緩存結果。若是不在緩存中，則走第四步，判斷 斷路器 的狀態是不是開啓的，若是是開啓狀態，也就是短路了，那就進行失敗返回，跳到第八步，第八步須要對失敗返回的處理也須要再作一次判斷，要麼正常失敗返回，返回相應信息，要麼根本沒有實現失敗返回的處理邏輯，就直接報錯。若是 斷路器 不是開啓狀態，那請求就繼續走，進行第五步，判斷線程/隊列是否滿了，若是滿了，那麼一樣跳到第八步，若是線程沒滿，則走到第六步，執行遠程調用邏輯，而後判斷遠程調用是否成功，調用發生異常了就挑到第八步，調用正常就挑到第九步正常返回信息。

圖中的第七步，很是牛逼的一個模塊，是來收集Hystrix流程中的各類信息來對系統作監控判斷的。

另外，Hystrix的斷路器實現原理也很關鍵，下面就是Hystrix斷路器的原理圖：

Hystrix經過滑動時間窗口算法來實現斷路器的，是以秒爲單位的滑桶式統計，它總共包含10個桶，每秒鐘一個生成一個新的桶，往前推移，舊的桶就廢棄掉。

每個桶中記錄了全部服務調用的狀態，調用次數、是否成功等信息，斷路器的開關就是把這10個桶進行聚合計算後，來判斷當前是應該開啓仍是閉合的。

以上，就是對微服務架構中「容錯隔離」的一些思考。

在微服務架構的系列文章中，前面已經經過文章介紹過了「服務註冊 」、「服務網關 」、「配置中心 」、「 監控系統 」、「調用鏈監控」，你們能夠翻閱歷史文章查看。

碼字不易啊，喜歡的話不妨轉發朋友，或點擊文章右下角的「在看」吧。😊

本文原創發佈於微信公衆號「 不止思考 」，歡迎關注。涉及 思惟認知、我的成長、架構、大數據、Web技術 等。