我們知道，在單體應(yīng)用的架構(gòu)下一旦程序發(fā)生了故障，那么整個(gè)應(yīng)用可能就沒(méi)法使用了，所以我們要把單體應(yīng)用拆分成具有多個(gè)服務(wù)的微服務(wù)架構(gòu)，來(lái)減少故障的影響范圍。但是在微服務(wù)架構(gòu)下，有一個(gè)新的問(wèn)題就是，由于服務(wù)數(shù)變多了，假設(shè)單個(gè)服務(wù)的故障率是不變的，那么整體微服務(wù)系統(tǒng)的故障率其實(shí)是提高了的。

比如：假設(shè)單個(gè)服務(wù)的故障率是0.01%，也就是可用性是99.99%，如果我們總共有10個(gè)微服務(wù)，那么我們整體的可用性就是99.99%的十次方，得到的就是99.90%的可用性（也就是故障率為0.1%）?？梢?jiàn)，相對(duì)于之前的單體應(yīng)用，整個(gè)系統(tǒng)可能發(fā)生故障的風(fēng)險(xiǎn)大幅提升。

那么在這種情況下，我們應(yīng)該怎么去保證微服務(wù)架構(gòu)的可用性呢？

其實(shí)我們參考造船行業(yè)對(duì)船艙進(jìn)水風(fēng)險(xiǎn)的隔離方法，如上圖。

造船行業(yè)有一個(gè)專(zhuān)業(yè)術(shù)語(yǔ)叫做「艙壁隔離」，利用艙壁將不同的船艙隔離起來(lái)，如果某一個(gè)船艙進(jìn)了水，那么就可以立即封閉艙門(mén)，形成艙壁隔離，只損失那一個(gè)船艙，其他船艙不受影響，整個(gè)船只還是可以正常航行。

對(duì)應(yīng)到微服務(wù)架構(gòu)中，我們要做的就是最大限度的隔離單個(gè)服務(wù)的風(fēng)險(xiǎn)，也就是「 容錯(cuò)隔離 」的方法。

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

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

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

單機(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ā)生各種故障，例如 硬盤(pán)壞了、機(jī)器電源故障等等，這些都是時(shí)有發(fā)生的事情。不過(guò)雖然這種風(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ù)了再重新上線到集群里。

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

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

咱們?nèi)珖?guó)大小城市都在瘋狂的進(jìn)行基建，修橋修路修房子，GDP就這么搞起來(lái)了，地下的光纖挖斷幾根不是再正常不過(guò)的事情了么，哈哈。

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

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

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

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

好了，上面講了微服務(wù)架構(gòu)中可能遇到這么多的可用性風(fēng)險(xiǎn)，并且也知道了「容錯(cuò)隔離」的重要性，下面我們?cè)賮?lái)看看常見(jiàn)的「容錯(cuò)隔離」方法有哪些：

超時(shí)：

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

限流

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

降級(jí)

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

延遲處理

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

熔斷

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

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

斷路器其實(shí)就是一個(gè)狀態(tài)機(jī)原理，有三種狀態(tài)：Closed（閉合狀態(tài)，也就是正常狀態(tài)）、Open（開(kāi)啟狀態(tài)，也就是當(dāng)后端服務(wù)出故障后鏈路斷開(kāi)，不提供服務(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ò)隔離或者說(shuō)熔斷技術(shù)方面做得最出名的框架就是 Hystrix 了。Hystrix是由Netflix開(kāi)源，在業(yè)內(nèi)應(yīng)用非常廣泛。

下面是Hystrix的原理流程圖：

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

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

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

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

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

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

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

以上，就是對(duì)微服務(wù)架構(gòu)中「容錯(cuò)隔離」的一些思考。