背景

隨著業(yè)務(wù)的快速變化和技術(shù)的不斷發(fā)展，系統(tǒng)面臨著諸多挑戰(zhàn)，例如流量峰值、依賴服務(wù)故障、硬件故障、網(wǎng)絡(luò)中斷、軟件缺陷等，這些因素都可能影響到系統(tǒng)的正常運(yùn)行。在這種背景下，彈性設(shè)計（Resilience Design）應(yīng)運(yùn)而生。彈性設(shè)計是一種系統(tǒng)的設(shè)計和構(gòu)建方法，系統(tǒng)的設(shè)計原則應(yīng)該本著不信任外部資源（外部API服務(wù)、網(wǎng)絡(luò)設(shè)備、存儲、消息等）100%可用的原則，在關(guān)鍵處理路徑上針對上述可能發(fā)生故障的點(diǎn)進(jìn)行容錯加固設(shè)計，保護(hù)系統(tǒng)自身的可用性。它的目標(biāo)是使系統(tǒng)能夠在面臨壓力和不確定性時，保持服務(wù)可用性和性能，而不是簡單地在問題出現(xiàn)后進(jìn)行修復(fù)。彈性設(shè)計考慮到了系統(tǒng)可能會遭受的各種攻擊，包括物理攻擊、網(wǎng)絡(luò)攻擊、軟件錯誤等，并采取了相應(yīng)的預(yù)防措施。

彈性設(shè)計的核心思想是預(yù)見并應(yīng)對系統(tǒng)可能面臨的風(fēng)險和挑戰(zhàn)，這需要對系統(tǒng)的需求、架構(gòu)、組件和服務(wù)進(jìn)行深入的理解和管理。彈性設(shè)計還強(qiáng)調(diào)了自動化和快速響應(yīng)的重要性，以便在問題發(fā)生時，能夠迅速地檢測到問題并采取相應(yīng)的措施。

總的來說，彈性設(shè)計為系統(tǒng)穩(wěn)定性建設(shè)提供了一種新的視角和方法，它有助于提高系統(tǒng)的可用性、性能和安全性，同時也降低了維護(hù)和修復(fù)的成本和風(fēng)險。

一、故障隔離標(biāo)準(zhǔn)

1、故障隔離概念

故障隔離是指當(dāng)系統(tǒng)中某些模塊或者組件出現(xiàn)異常故障時，把這些故障通過某種方式隔離起來，讓其不和其他的系統(tǒng)產(chǎn)生聯(lián)系，即使這個被隔離的應(yīng)用或者系統(tǒng)出現(xiàn)了問題，也不會波及其他的應(yīng)用。故障隔離方案是一個應(yīng)用系統(tǒng)實現(xiàn)高可用的重要組成部分。

2、故障隔離原因

系統(tǒng)必須具備防止故障從一個系統(tǒng)/組件傳播到另一個系統(tǒng)/組件的能力。故障從一個系統(tǒng)/組件傳播到另一個系統(tǒng)/組件通常有以下兩種原因。

1.系統(tǒng)/組件間強(qiáng)依賴：如果系統(tǒng)/組件間存在強(qiáng)依賴，當(dāng)一個系統(tǒng)/組件發(fā)生故障時，強(qiáng)依賴它的組件將無法正常工作。防止強(qiáng)依賴引發(fā)的故障傳播，通常的手段是將強(qiáng)依賴轉(zhuǎn)化為弱依賴或最弱依賴，比如設(shè)置合適的超時、捕獲異常、同步依賴轉(zhuǎn)異步依賴、提供備份組件等。

2.系統(tǒng)/組件間共享資源：如果系統(tǒng)/組件間存在共享的資源（如線程池、數(shù)據(jù)庫連接池、網(wǎng)絡(luò)連接池、內(nèi)存區(qū)等），當(dāng)一個系統(tǒng)/組件因為故障耗盡了共享的資源后，所有依賴該資源的系統(tǒng)/組件也都會發(fā)生故障。防止共享資源引發(fā)的故障傳播，通常的手段是對組件的資源使用建立配額體系，或者為重要組件提供專用資源。

二、訪問量控制標(biāo)準(zhǔn)

訪問量控制是指服務(wù)提供者或者服務(wù)使用者對服務(wù)資源有效的SLA控制，在做訪問量控制設(shè)計時，需要關(guān)注以下幾方面：

1.服務(wù)提供者必須給出本服務(wù)（包括系統(tǒng)調(diào)用服務(wù)、頁面服務(wù)等）的訪問策略，包括最大的訪問能力、其它訪問約束（如參數(shù)約束、單賬戶訪問約束等），說明違反服務(wù)訪問策略的后果。

2.服務(wù)提供者需要對違反服務(wù)訪問策略的情況，實施管控措施。我們要求所有對外提供服務(wù)的系統(tǒng)（如對外服務(wù)的網(wǎng)關(guān)系統(tǒng)、對外服務(wù)的web系統(tǒng)等）必須具有防止外部訪問過載的能力（即具備限流能力）。

3.渠道入口系統(tǒng)需要具備能夠降級入口服務(wù)的能力，確保入口功能服務(wù)在出現(xiàn)異常時，在交易鏈路的最前段截斷異常，防止影響擴(kuò)大。

4.服務(wù)調(diào)用方需要對關(guān)鍵場景下的非關(guān)鍵服務(wù)訪問進(jìn)行容錯設(shè)計，常用的手段包括（熔斷、降級），確保在非關(guān)鍵服務(wù)訪問出現(xiàn)異常的情況下，迅速切斷該服務(wù)訪問，保證關(guān)鍵交易成功率。

5.服務(wù)調(diào)用方在調(diào)用第三方服務(wù)時，需要明確外部服務(wù)能力，并具備相應(yīng)手段可以進(jìn)行訪問控制。

6.原則上所有控制訪問量的手段（如限流、熔斷、降級）均應(yīng)具備實時調(diào)整的能力，以保證在異常訪問下系統(tǒng)的動態(tài)性能余量充足。

三、服務(wù)降級、限流、熔斷

熔斷和限流都可以認(rèn)為是降級的一種方式

1、服務(wù)降級

服務(wù)降級是當(dāng)出現(xiàn)系統(tǒng)/組件故障后，以犧牲某些業(yè)務(wù)功能或者犧牲某些客戶群體為代價，保障更關(guān)鍵的業(yè)務(wù)、客戶群體服務(wù)質(zhì)量的應(yīng)急措施。服務(wù)降級可以是人工觸發(fā)的，也可以是系統(tǒng)自動執(zhí)行的。所有核心交易場景下的非關(guān)鍵服務(wù)訪問均應(yīng)進(jìn)行服務(wù)降級設(shè)計，以保證核心交易成功率。在有限的資源情況下，對系統(tǒng)做出一些犧牲，有點(diǎn)“棄卒保帥”的意思。放棄一些功能，保證整個系統(tǒng)能平穩(wěn)運(yùn)行。

降級的注意點(diǎn)

1.每個服務(wù)都需要制定自己的降級策略，根據(jù)服務(wù)不同的優(yōu)先級來設(shè)定降級方案，緊急情況下可以通過啟用降級開關(guān)關(guān)閉非核心功能，損失一定的客戶體驗，以確保核心關(guān)鍵業(yè)務(wù)的服務(wù)可用性。

2.對業(yè)務(wù)進(jìn)行仔細(xì)的梳理和分析，哪些是核心流程必須保證的，哪些是可以犧牲的，干掉一些次要功能。比如電商功能大促期間可以把評論關(guān)閉或者簡化評論流程

3.什么指標(biāo)下能進(jìn)行降級：吞吐量、響應(yīng)時間、失敗次數(shù)等達(dá)到一個閾值才進(jìn)行降級處理

4.降級最簡單的就是在業(yè)務(wù)代碼中配置一個開關(guān)或者做成配置中心模式，直接在配置中心上更改配置，推送到相應(yīng)的服務(wù)。比如DUCC開關(guān)技術(shù)。

2、服務(wù)限流

服務(wù)限流是分布式系統(tǒng)中一種常見的保護(hù)機(jī)制。當(dāng)負(fù)載超出系統(tǒng)/組件的處理能力上限時，可能會造成系統(tǒng)響應(yīng)時間增加或部分業(yè)務(wù)失敗，需要通過業(yè)務(wù)限流來防止系統(tǒng)響應(yīng)進(jìn)一步嚴(yán)重惡化。例如，在一個分布式系統(tǒng)中，最大tps為2000。這意味著每秒最多只能處理2000個請求。為了防止系統(tǒng)過載，可以設(shè)置規(guī)則限制上游服務(wù)每秒調(diào)用的tps。當(dāng)請求量超過2000tps時，可以通過隨機(jī)或選擇性拋棄一些請求來實現(xiàn)限流。

具體實現(xiàn)方式可以有很多種，比如：

• 隨機(jī)拋棄一部分請求：當(dāng)請求量超過2000tps時，從所有請求中隨機(jī)選擇一部分進(jìn)行拒絕處理。這樣可以確保每個請求都有平等的機(jī)會被處理，同時也可以在一定程度上避免單個請求對整個系統(tǒng)造成過大的影響。

• 選擇性拋棄一部分請求：與隨機(jī)拋棄不同，選擇性拋棄是針對某些特定的請求進(jìn)行處理。例如，可以根據(jù)請求的來源、參數(shù)等信息來判斷是否需要拋棄該請求。這種方式可以更加靈活地控制限流策略，但也需要更多的資源和技術(shù)支持。

服務(wù)限流是一種有效的保護(hù)機(jī)制，可以幫助我們應(yīng)對高并發(fā)場景下的挑戰(zhàn)。通過合理設(shè)置業(yè)務(wù)限流規(guī)則，我們可以保證系統(tǒng)的穩(wěn)定運(yùn)行，提高用戶體驗和滿意度。

主流的限流算法有:

(1)、計數(shù)器法

計數(shù)器法是限流算法里最簡單也是最容易實現(xiàn)的一種算法。比如我們規(guī)定，對于A接口來說，我們1分鐘的訪問次數(shù)不能超過100個，分布式計數(shù)器一般會用自研計數(shù)服務(wù)或者 redis 等組件來做。

(2)、滑動時間窗口算法（JSF限流模式之一）

為了解決計數(shù)器法統(tǒng)計精度太低的問題，引入了滑動窗口算法。下面這張圖，很好地解釋了滑動窗口算法：

在上圖中，整個紅色的矩形框表示一個時間窗口，在我們的例子中，一個時間窗口就是一分鐘。然后我們將時間窗口進(jìn)行劃分，比如圖中，我們就將滑動窗口劃成了6格，所以每格代表的是10秒鐘。每過10秒鐘，我們的時間窗口就會往右滑動一格。每一個格子都有自己獨(dú)立的計數(shù)器counter，比如當(dāng)一個請求 在0:35秒的時候到達(dá)，那么0:30~0:39對應(yīng)的counter就會加1。

計數(shù)器算法其實就是滑動窗口算法。只是它沒有對時間窗口做進(jìn)一步地劃分，所以只有1格。

由此可見，當(dāng)滑動窗口的格子劃分的越多，那么滑動窗口的滾動就越平滑，限流的統(tǒng)計就會越精確。

(3)、漏桶算法

漏桶算法思路很簡單，水（請求）先進(jìn)入到漏桶里，漏桶以一定的速度出水，當(dāng)水流入速度過大會直接溢出，可以看出漏桶算法能強(qiáng)行限制數(shù)據(jù)的傳輸速率。

從圖中我們可以看到，整個算法其實十分簡單。首先，我們有一個固定容量的桶，有水流進(jìn)來，也有水流出去。對于流進(jìn)來的水來說，我們無法預(yù)計一共有多少水會流進(jìn)來，也無法預(yù)計水流的速度。但是對于流出去的水來說，這個桶可以固定水流出的速率。而且，當(dāng)桶滿了之后，多余的水將會溢出。

我們將算法中的水換成實際應(yīng)用中的請求，我們可以看到漏桶算法天生就限制了請求的速度。當(dāng)使用了漏桶算法，我們可以保證接口會以一個常速速率來處理請求。所以漏桶算法天生不會出現(xiàn)臨界問題。

(4)、令牌桶算法（JSF限流模式之一）

令牌桶算法是網(wǎng)絡(luò)流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種算法。典型情況下，令牌桶算法用來控制發(fā)送到網(wǎng)絡(luò)上的數(shù)據(jù)的數(shù)目，并允許突發(fā)數(shù)據(jù)的發(fā)送。

從圖中我們可以看到，令牌桶算法比漏桶算法稍顯復(fù)雜。首先，我們有一個固定容量的桶，桶里存放著令牌

（token）。桶一開始是空的，token以 一個固定的速率r往桶里填充，直到達(dá)到桶的容量，多余的令牌將會被丟棄。每當(dāng)一個請求過來時，就會嘗試從桶里移除一個令牌，如果沒有令牌的話，請求無法通過。

(5)、限流算法小結(jié)

計數(shù)器 VS 滑動窗口：

1 計數(shù)器算法是最簡單的算法，可以看成是滑動窗口的低精度實現(xiàn)。

2 滑動窗口由于需要存儲多份的計數(shù)器（每一個格子存一份）,所以滑動窗口在實現(xiàn)上需要更多的存儲空間。

3 如果滑動窗口的精度越高，需要的存儲空間就越大。

漏桶算法 VS令牌桶算法：

1 漏桶算法和令牌桶算法最明顯的區(qū)別是令牌桶算法允許流量一定程度的突發(fā)。

2 因為默認(rèn)的令牌桶算法，取走token是不需要耗費(fèi)時間的，也就是說，假設(shè)桶內(nèi)有100個token時，那么可以瞬間允

3 當(dāng)然我們需要具體情況具體分析，只有最合適的算法，沒有最優(yōu)的算法。

3、服務(wù)熔斷

服務(wù)與服務(wù)之間的依賴性，故障會傳播，會對整個微服務(wù)系統(tǒng)造成災(zāi)難性的嚴(yán)重后果，這就是服務(wù)故障的“雪崩”效應(yīng)。為了解決這個問題，業(yè)界提出了斷路器模型。

服務(wù)熔斷是在分布式系統(tǒng)中避免從系統(tǒng)局部的、小規(guī)模的故障，最終導(dǎo)致全局性的后果的手段。它是通過快速失?。‵ail Fast）的機(jī)制，避免請求大量阻塞，從而保護(hù)調(diào)用方。比如：一個服務(wù)A調(diào)用當(dāng)下游B超時或失敗時，會導(dǎo)致請求超時引起堆積隊列，從而導(dǎo)致下游B系統(tǒng)壓力越來越大而無法恢復(fù)。如果我們我們還是盲目地去請求，即時失敗了多次，還是傻傻的去請求，去等待。這樣一來增加了整個鏈路的請求時間，同時下游B系統(tǒng)本身就出現(xiàn)了問題，不斷的請求又把系統(tǒng)問題加重了，恢復(fù)困難。如果使用了熔斷功能，則當(dāng)觸發(fā)熔斷后，到下游B服務(wù)的壓力減小，從而保護(hù)了存活的系統(tǒng)。原理圖如下：

業(yè)內(nèi)目前流行的熔斷器很多，例如Sentinel,以及最多人使用的Hystrix，同時京東內(nèi)部的JSF也支持熔斷

關(guān)于熔斷原理詳見這篇文章

【源碼】SpringCloud-Hystrix服務(wù)熔斷與降級工作原理&源碼

四、容錯設(shè)計

容錯設(shè)計對系統(tǒng)穩(wěn)定性至關(guān)重要，在容錯設(shè)計中，首先應(yīng)確定系統(tǒng)容錯等級策略，策略分級可參考如下表

容錯設(shè)計等級等級描述無容錯性設(shè)計所依賴的外部資源訪問出錯，本應(yīng)用未能檢測識別到，導(dǎo)致應(yīng)用處理數(shù)據(jù)出錯，造成臟數(shù)據(jù)的弱容錯性設(shè)計所依賴的外部資源訪問出錯，本應(yīng)用服務(wù)不可用且難以恢復(fù)的基本容錯性設(shè)計所依賴的外部資源訪問出錯，本應(yīng)用服務(wù)不可用，但是由人工操作后可恢復(fù)的較強(qiáng)容錯性設(shè)計所依賴的外部資源訪問出錯，本應(yīng)用服務(wù)不可用，但可自動恢復(fù)的強(qiáng)容錯性設(shè)計所依賴的外部資源訪問出錯，本應(yīng)用不受影響并正常對外提供服務(wù)的

(容錯等級設(shè)計)

確定好容錯策略分級之后，開始系統(tǒng)容錯設(shè)計。系統(tǒng)需要提供充足的容錯機(jī)制，以應(yīng)對所依賴的外部服務(wù)或其他依賴資源發(fā)生故障情況；系統(tǒng)的設(shè)計原則應(yīng)該本著不信任外部資源（外部服務(wù)、DB、網(wǎng)絡(luò)設(shè)備、存儲、消息等）100%可用的原則，在關(guān)鍵處理路徑上針對上述可能發(fā)生故障的點(diǎn)進(jìn)行容錯加固設(shè)計，保護(hù)系統(tǒng)自身的可用性。

1、服務(wù)不可用容錯設(shè)計

服務(wù)不可用容錯設(shè)計：跨系統(tǒng)服務(wù)調(diào)用，調(diào)用端必須保障請求準(zhǔn)確送達(dá)、服務(wù)端必須保障響應(yīng)準(zhǔn)確返回；基于此原則，某些場景下可能發(fā)生請求送達(dá)或響應(yīng)返回丟失的，必須使用重試機(jī)制來彌補(bǔ)，如通過異步確保消息通知機(jī)制來解決跨系統(tǒng)、一次性調(diào)用場景下請求無法確保送達(dá)問題。服務(wù)提供方系統(tǒng)發(fā)布中、或其他不可預(yù)知的服務(wù)訪問超時，都有可能導(dǎo)致客戶端請求失敗，此時客戶端應(yīng)用若無任何容錯機(jī)制，則業(yè)務(wù)處理異常中斷。

探活檢測：是故障隔離的基礎(chǔ)，通過應(yīng)用的健康檢查可以識別出異常的服務(wù)節(jié)點(diǎn)。負(fù)載均衡和服務(wù)注冊中心可以及時地將這些異常節(jié)點(diǎn)剔除，從而阻止請求流量再次分發(fā)到這些節(jié)點(diǎn)，實現(xiàn)節(jié)點(diǎn)維度的故障隔離。同樣地，數(shù)據(jù)庫連接探活也是類似的思路。

重試邏輯：在分布式系統(tǒng)中，微服務(wù)系統(tǒng)的重試操作可能會觸發(fā)多個其他請求或重試操作，并導(dǎo)致級聯(lián)效應(yīng)。為了避免這種影響，我們應(yīng)該盡量減少重試的次數(shù)，并使用指數(shù)退避算法來逐漸增加重試之間的延遲時間，直到達(dá)到最大限制。重試的另外一個要求是服務(wù)的冪等設(shè)計。

故障轉(zhuǎn)移：對于冪等服務(wù)，調(diào)用出現(xiàn)故障，系統(tǒng)不會立即向調(diào)用者返回失敗結(jié)果，而是自動切換到其他服務(wù)副本，嘗試其他副本能否返回成功調(diào)用的結(jié)果，從而保證了整體的高可用性。

快速失敗：快速失敗是指依賴方不可用時，不能耗費(fèi)大量的寶貴系統(tǒng)資源（比如線程、連接數(shù)等），再等待其恢復(fù)，而是要在其達(dá)不到合理的功能和性能要求時快速失敗，避免占用資源，甚至拖垮系統(tǒng)。

對于非冪等的服務(wù)，重復(fù)調(diào)用就可能產(chǎn)生臟數(shù)據(jù)，引起的麻煩遠(yuǎn)大于單純的某次服務(wù)調(diào)用失敗，此時就應(yīng)該以快速失敗作為首選的容錯策略。我們可以使用基于操作的成功或失敗統(tǒng)計次數(shù)的熔斷模式，而不是使用超時。

同步轉(zhuǎn)異步：同步調(diào)用意味著強(qiáng)依賴。消息隊列起到很好的削峰填谷的作用，且一般都具備很大規(guī)模的消息堆積能力。

資源隔離：線程池隔離：我們可以通過線程池隔離的方式來實現(xiàn)資源的隔離，不同的請求使用相應(yīng)的線程池來處理，即便出現(xiàn)請求資源time out的情況，最多影響當(dāng)前線程池的資源，而不會影響整個服務(wù)的線程資源。類似船艙中的隔離區(qū)域。

信號量隔離：信號量主要是用來控制線程數(shù)的，規(guī)定好一些調(diào)用最大的并發(fā)量，超過指定的信號量后，可以將請求丟棄或者延時處理，防止線程的不斷增長導(dǎo)致的服務(wù)異常。

降級、限流、熔斷：參考上一章節(jié)

2、數(shù)據(jù)容錯設(shè)計

數(shù)據(jù)庫容錯設(shè)計：業(yè)務(wù)在正常執(zhí)行的時候，如果遇到某個數(shù)據(jù)庫故障，需要具備快速的容錯機(jī)制，保證后續(xù)業(yè)務(wù)的正常進(jìn)行。這種容錯機(jī)制包括數(shù)據(jù)庫的災(zāi)難轉(zhuǎn)移或切換方案。

緩存數(shù)據(jù)設(shè)計：依賴本地緩存是一種數(shù)據(jù)的降級方案，當(dāng)依賴方（服務(wù)或數(shù)據(jù)庫）出現(xiàn)故障時，可以一定程度地保障業(yè)務(wù)可用。一般是應(yīng)用于核心、決不能出錯的業(yè)務(wù)場景。緩存的問題是數(shù)據(jù)實時更新的一致性問題，但在很多場景下，對于客戶的體驗，讀到舊的數(shù)據(jù)往往要比系統(tǒng)無法響應(yīng)要好很多。

參考：

中國信通院分布式系統(tǒng)穩(wěn)定性建設(shè)指南

本文所述技術(shù)仍有待進(jìn)一步研究和探討，希望能為相關(guān)領(lǐng)域的研究者提供一些啟示。文章中難免會有不足之處，希望讀者能給予寶貴的意見和建議。謝謝！

轉(zhuǎn)自：http://www.npqdlp.com/