微服務(wù)架構(gòu)的容錯(cuò)隔離方法是什么

一、微服務(wù)架構(gòu)中可用性風(fēng)險(xiǎn)有哪些？

在聊「容錯(cuò)隔離」方法之前，我們先來看一下微服務(wù)架構(gòu)中，常見的可用性風(fēng)險(xiǎn)到底有哪些吧，知道了有哪些風(fēng)險(xiǎn)我們才知道該如何去規(guī)避、去隔離風(fēng)險(xiǎn)。

我們可以從項(xiàng)目部署規(guī)模的角度去分析風(fēng)險(xiǎn)：

1. 單機(jī)可用性風(fēng)險(xiǎn)：

   這個(gè)很好理解，就是微服務(wù)部署所在的某一臺(tái)機(jī)器出現(xiàn)了故障，造成的可用性風(fēng)險(xiǎn)。這種風(fēng)險(xiǎn)發(fā)生率很高，因?yàn)閱螜C(jī)器在運(yùn)維中本身就容易發(fā)生各種故障，例如 硬盤壞了、機(jī)器電源故障等等，這些都是時(shí)有發(fā)生的事情。不過雖然這種風(fēng)險(xiǎn)發(fā)生率高，但危害有限，因?yàn)槲覀兇蠖鄶?shù)服務(wù)并不只部署在一臺(tái)機(jī)器上，可能多臺(tái)都有，因此只需要做好監(jiān)控，發(fā)現(xiàn)故障之后，及時(shí)的將這臺(tái)故障機(jī)器從服務(wù)集群中剔除即可，等修復(fù)了再重新上線到集群里。

2. 單機(jī)房可用性風(fēng)險(xiǎn)：

   這種風(fēng)險(xiǎn)的概率比單機(jī)器的要低很多，但是也不是完全不可能發(fā)生，在實(shí)際情況中，還是有一定概率的。比如最為常見的就是通往機(jī)房的光纖被挖斷了，前段時(shí)間支付寶所在機(jī)房不是就發(fā)生過光纖被挖么。

   咱們?nèi)珖笮〕鞘卸荚诏偪竦倪M(jìn)行基建，修橋修路修房子，GDP就這么搞起來了，地下的光纖挖斷幾根不是再正常不過的事情了么，哈哈。

   如果我們的服務(wù)全部都部署在單個(gè)機(jī)房，而機(jī)房又出故障了，那就沒轍了。好在，現(xiàn)在大多數(shù)中大型項(xiàng)目都會(huì)采用多機(jī)房部署的方案，比如同城雙活、異地多活等。一旦某個(gè)機(jī)房出現(xiàn)了故障不可用了，咱們立即采用切換路由的方式，把這個(gè)機(jī)房的流量切到其它機(jī)房里。

3. 跨機(jī)房集群可用性風(fēng)險(xiǎn)：

   既然都跨機(jī)房集群了，可用性理論上應(yīng)該沒啥問題啊。但要知道這是在物理層面沒有問題了，如果咱們的代碼有坑，或者因?yàn)樘厥庠蛴脩袅髁考ぴ?，?dǎo)致我們的服務(wù)扛不住了，那在跨機(jī)房集群的情況下一樣會(huì)不可用。但如果我們提前做好了「容錯(cuò)隔離」的一些方案，比如 限流、熔斷 等等，用上這些方法還是可以保證一部分服務(wù)或者一部分用戶的訪問是正常。

二、「 容錯(cuò)隔離 」的方法有哪些？

好了，上面講了微服務(wù)架構(gòu)中可能遇到這么多的可用性風(fēng)險(xiǎn)，并且也知道了「容錯(cuò)隔離」的重要性，下面我們?cè)賮砜纯闯Ｒ姷摹溉蒎e(cuò)隔離」方法有哪些：

1. 超時(shí)：

   這也是簡單的容錯(cuò)方式。就是指在服務(wù)之間調(diào)用時(shí)，設(shè)置一個(gè) 主動(dòng)超時(shí)時(shí)間，超過了這個(gè)時(shí)間閾值后，如果“被依賴的服務(wù)”還沒有返回?cái)?shù)據(jù)的話，“調(diào)用者”就主動(dòng)放棄，防止因“被依賴的服務(wù)”的故障所影響。

2. 限流

   顧名思義，就是限制最大流量。系統(tǒng)能提供的最大并發(fā)有限，同時(shí)來的請(qǐng)求又太多，服務(wù)不過來啊，就只好排隊(duì)限流了，就跟去景點(diǎn)排隊(duì)買票、去商場(chǎng)吃飯排隊(duì)等號(hào)的道理一樣一樣兒的。

3. 降級(jí)

   這個(gè)與限流類似，一樣是流量太多，系統(tǒng)服務(wù)不過來。這個(gè)時(shí)候可以可將不是那么重要的功能模塊進(jìn)行降級(jí)處理，停止服務(wù)，這樣可以釋放出更多的資源供給核心功能的去用。同時(shí)還可以對(duì)用戶分層處理，優(yōu)先處理重要用戶的請(qǐng)求，比如VIP收費(fèi)用戶等。

4. 延遲處理

   這個(gè)方式是指設(shè)置一個(gè)流量緩沖池，所有的請(qǐng)求先進(jìn)入這個(gè)緩沖池等待處理，真正的服務(wù)處理方按順序從這個(gè)緩沖池中取出請(qǐng)求依次處理，這種方式可以減輕后端服務(wù)的壓力，但是對(duì)用戶來說體驗(yàn)上有延遲。

5. 熔斷

   可以理解成就像電閘的保險(xiǎn)絲一樣，當(dāng)流量過大或者錯(cuò)誤率過大的時(shí)候，保險(xiǎn)絲就熔斷了，鏈路就斷開了，不提供服務(wù)了。當(dāng)流量恢復(fù)正常，或者后端服務(wù)穩(wěn)定了，保險(xiǎn)絲會(huì)自動(dòng)街上（熔斷閉合），服務(wù)又可以正常提供了。這是一種很好的保護(hù)后端微服務(wù)的一種方式。

   熔斷技術(shù)中有個(gè)很重要的概念就是：斷路器，可以參考下圖：

   

6. 斷路器其實(shí)就是一個(gè)狀態(tài)機(jī)原理，有三種狀態(tài)：Closed（閉合狀態(tài)，也就是正常狀態(tài)）、Open（開啟狀態(tài)，也就是當(dāng)后端服務(wù)出故障后鏈路斷開，不提供服務(wù)的狀態(tài)）、Half-Open(半閉合狀態(tài)，就是允許一小部分流量進(jìn)行嘗試，嘗試后發(fā)現(xiàn)服務(wù)正常就轉(zhuǎn)為Closed狀態(tài)，服務(wù)依舊不正常就轉(zhuǎn)為Open狀態(tài))。

三、「 容錯(cuò)隔離 」的應(yīng)用？

在容錯(cuò)隔離或者說熔斷技術(shù)方面做得最出名的框架就是 Hystrix 了。Hystrix是由Netflix開源，在業(yè)內(nèi)應(yīng)用非常廣泛。

下面是Hystrix的原理流程圖：

這是新版流程，比之前舊版本又復(fù)雜很多，如果不講解一下，估計(jì)很多人都不容易看懂。

圖中標(biāo)注了數(shù)字1-9，可以按照這個(gè)數(shù)字順序去理解這個(gè)流程。

當(dāng)我們使用了Hystrix之后，請(qǐng)求會(huì)被封裝到HystrixCommand中，這也就是第一步。然后第二步就是開始執(zhí)行請(qǐng)求，Hystrix支持同步執(zhí)行(圖中.execute方法)、異步執(zhí)行(圖中.queue方法)和響應(yīng)式執(zhí)行(圖中.observer)。然后第三步判斷緩存，如果存在與緩存中，則直接返回緩存結(jié)果。如果不在緩存中，則走第四步，判斷 斷路器 的狀態(tài)是否是開啟的，如果是開啟狀態(tài)，也就是短路了，那就進(jìn)行失敗返回，跳到第八步，第八步需要對(duì)失敗返回的處理也需要再做一次判斷，要么正常失敗返回，返回相應(yīng)信息，要么根本沒有實(shí)現(xiàn)失敗返回的處理邏輯，就直接報(bào)錯(cuò)。如果 斷路器 不是開啟狀態(tài)，那請(qǐng)求就繼續(xù)走，進(jìn)行第五步，判斷線程/隊(duì)列是否滿了，如果滿了，那么同樣跳到第八步，如果線程沒滿，則走到第六步，執(zhí)行遠(yuǎn)程調(diào)用邏輯，然后判斷遠(yuǎn)程調(diào)用是否成功，調(diào)用發(fā)生異常了就挑到第八步，調(diào)用正常就挑到第九步正常返回信息。

圖中的第七步，非常牛逼的一個(gè)模塊，是來收集Hystrix流程中的各種信息來對(duì)系統(tǒng)做監(jiān)控判斷的。

另外，Hystrix的斷路器實(shí)現(xiàn)原理也很關(guān)鍵，下面就是Hystrix斷路器的原理圖：

Hystrix通過滑動(dòng)時(shí)間窗口算法來實(shí)現(xiàn)斷路器的，是以秒為單位的滑桶式統(tǒng)計(jì)，它總共包含10個(gè)桶，每秒鐘一個(gè)生成一個(gè)新的桶，往前推移，舊的桶就廢棄掉。

每一個(gè)桶中記錄了所有服務(wù)調(diào)用的狀態(tài)，調(diào)用次數(shù)、是否成功等信息，斷路器的開關(guān)就是把這10個(gè)桶進(jìn)行聚合計(jì)算后，來判斷當(dāng)前是應(yīng)該開啟還是閉合的。