容錯設計又叫彈力設計，其中著眼于分布式系統的各種“容忍”能力，包括容錯能力（服務 隔離、異步調用、請求冪等性）、可伸縮性（有 / 無狀態的服務）、一致性（補償事務、重 試）、應對大流量的能力（熔斷、降級）。可以看到，在確保系統正確性的前提下，系統的可用性是彈力設計保障的重點。

隔離設計
what:
顧名思義，它是指將系統按照一定的原則劃分為若干個服務模塊，各個模塊之間相對獨立，無強依賴。當有故障發生時，能將問題和影響隔離在某個模塊內部，而不擴散風險，不波及其它模塊，不影響整體的系統服務。它是借鑒于造船行業。

why：
任何軟件系統，故障是不可避免的，并且大多數還是不可預測的，因此，我們只能在系統的設計之初就充分的考慮好應對措施，如何在故障發生時，去盡最大可能的止損和減少故障范圍。
沒有人敢說他的系統是百分百可用，我們能做的就是，使用一切方法去減少故障的影響面，盡可能的去提高系統的整體可用率。
而把系統分離成子服務，將子服務進行一定程度隔離的做法，能保證在有不可預測的故障發生時，縮小故障范圍的最佳手段。
我們需要定義好隔離業務的大小和粒度，過大和過小都不好。這需要認真地做業務上的需求 和系統分析。

how:
1.按服務/功能做隔離
如果我們要設計個電商平臺，可以將其中的用戶系統、訂單系統、支付系統、倉儲系統都分別進行獨立隔離，這樣做就是從服務層面實現了故障的隔離效果

2.按用戶分類隔離:
先部署多套一模一樣的業務服務，然后將用戶根據一定的特征去做分類，讓不同分類的用戶去訪問不同的業務實例，達到分流和隔離的效果。

3.在代碼層面也可以做隔離設計，比如不同業務使用不同的線程池，防止某個業務故障直接影響到其他的業務

異步通訊設計:

what:
通訊一般來說分同步和異步兩種。同步通訊就像打電話，需要實時響應，而異步通訊就像發郵 件，不需要馬上回復。

why:
1.整個同步調用鏈的性能會由慢的那個服務所決定
2.同步調用會導致調用方一直在等待被調用方完成，如果一層接一層地同步調用下去，所有的 參與方會有相同的等待時間。這會非常消耗調用方的資源。

3.同步調用不好的是，如果被調用方有問題，那么其調用方就會跟著出問題，會出現多 米諾骨牌效應。

所以，異步通訊相對于同步通訊來說，除了可以增加系統的吞吐量之外，大的一個好處是其可 以讓服務間的解耦更為徹底，系統的調用方和被調用方可以按照自己的速率而不是步調一致，各個服務間的性能不受干擾相對獨立。從 而可以更好地保護系統，讓系統更有彈力。

how:
有幾種方式
1.請求響應式 在這種情況下，發送方（sender）會直接請求接收方（receiver），被請求方接收到請求后，直 接返回——收到請求，正在處理。
對于返回結果，有兩種方法，一種是發送方時不時地去輪詢一下，問一下干沒干完。另一種方式 是發送方注冊一個回調方法，也就是接收方處理完后回調請求方。這種架構模型在以前的網上支 付中比較常見，頁面先從商家跳轉到支付寶或銀行，商家會把回調的 URL 傳給支付頁面，支付 完后，再跳轉回商家的 URL。
很明顯，這種情況下還是有一定耦合的。是發送方依賴于接收方，并且要把自己的回調發送給接 收方，處理完后回調。

2.發布訂閱的方式
通過消息中間件（Broker），發送方（sender）和接收方（receiver）都互相看不到對方， 它們看得到的是一個 Broker，發送方向 Broker 發送消息，接收方向 Broker 訂閱消息。

在 Broker 這種模式下，發送方的服務和接收方的服務大程度地解耦。但是所有人都依賴于一 個總線，所以這個總線就需要有如下的特性：

必需是高可用的，因為它成了整個系統的關鍵；
必需是高性能而且是可以水平擴展的；
必需是可以持久化不丟數據的。

要做到這三條還是比較難的，所以一般下游系統會提供查詢接口給上游調用。

注意點：
消息順序很難保證，業務最好設計成不依賴消息順序的。

消息傳遞中，可能有的業務邏輯會有像 TCP 協議那樣的 send 和 ACK 機制。比如：A 服務 發出一個消息之后，開始等待處理方的 ACK，如果等不到的話，就需要做重傳。此時，需要 處理方有冪等的處理，即同一件消息無論收到多少次都只處理一次。

關于冪等性設計，現在我們一般是采用先查詢的方式，但是絕大多數請求應該都不會是重新發過來的，所以讓 100% 的請求都到這個存儲里去查一下，這會導致處理流程可能會很慢。
所以，好是當這個存儲出現沖突的時候會報錯。也就是說，我們收到交易請求后，直接去存儲 里記錄這個 ID（相對于數據的 Insert 操作），如果出現 ID 沖突了的異常，那么我們就知道這個之前已經有人發過來了，所以就不用再做了。

補償事務：
what:
業務補償主要做兩件事。

努力地把一個業務流程執行完成。

如果執行不下去，需要啟動補償機制，回滾業務流程

why:
在很多情況下，我們是無法做到強一致的ACID 的。特別是我們需要跨多個系統的時候。BASE理論強調軟狀態與最終一致性，
如果一個事務失敗了或是超時了，我們需要 不斷地重試，努力地達到最終我們想要的狀態。然后，如果我們不能達到這個我們想要的狀態， 我們需要把整個狀態恢復到之前的狀態。另外，如果有變化的請求，我們需要啟動整個事務的業務更新機制。

how:
因為要把一個業務流程執行完成，需要這個流程中所涉及的服務方支持冪等性。并且在上游 有重試機制
需要小心維護和監控整個過程的狀態

補償的業務邏輯和流程不一定非得是嚴格反向操作。有時候可以并行，有時候，可能會更簡 單。總之，設計業務正向流程的時候，也需要設計業務的反向補償流程

業務補償的業務邏輯是強業務相關的，很難做成通用的

下層的業務方最好提供短期的資源預留機制。就像電商中的把貨品的庫存預先占住等待用戶 在 15 分鐘內支付。如果沒有收到用戶的支付，則釋放庫存。然后回滾到之前的下單操作，等待用戶重新下單。

重試設計：

重試的場景：
調用超時、被調用端返回了某種可以重試的錯誤（如繁忙中、流控中、維護中、資源不足等）。
而對于一些別的錯誤，則最好不要重試，比如：業務級的錯誤（如沒有權限、或是非法數據等錯 誤），技術上的錯誤（如：HTTP 的 503 等，這種原因可能是觸發了代碼的 bug，重試下去沒 有意義）。

重試的策略：
指數級退避策略。在這種情況下，每一次重試所需要的休息時間都會翻倍增加。這種機制主要是用來讓被調用方能夠有更多的時間來從容處理我們的請求。類似TCP 的擁塞控制

注意點:
要確定什么樣的錯誤下需要重試；

重試的時間和重試的次數。這種在不同的情況下要有不同的考量。有時候，而對一些不是很 重要的問題時，我們應該更快失敗而不是重試一段時間若干次。比如一個前端的交互需要用 到后端的服務。這種情況下，在面對錯誤的時候，應該快速度失敗報錯（比如：網絡錯誤請 重試）。而面對其它的一些錯誤，比如流控，那么應該使用指數退避的方式，以避免造成更 多的流量。

如果超過重試次數，或是一段時間，那么重試就沒有意義了

需要考慮被調用方是否有冪等的設計。如果沒有，那么重試是不安全的，可能會導致 一個相同的操作被執行多次。

熔斷機制：
借鑒于我們電閘上的 " 保險絲 "，當電壓有問題時（比如短路），自動跳閘，此時電路 就會斷開，我們的電器就會受到保護。
重試機制，如果錯誤太多， 或是在短時間內得不到修復，那么我們重試也沒有意義了，此時應該開啟我們的熔斷操作，尤其 是后端太忙的時候，使用熔斷設計可以保護后端不會過載。

熔斷器可以使用狀態機來實現，內部模擬以下幾種狀態。
閉合（Closed）狀態：我們需要一個調用失敗的計數器，如果調用失敗，則使失敗次數加 1。如果最近失敗次數超過了在給定時間內允許失敗的閾值，則切換到斷開 (Open) 狀態。此 時開啟了一個超時時鐘，當該時鐘超過了該時間，則切換到半斷開（Half-Open）狀態。該 超時時間的設定是給了系統一次機會來修正導致調用失敗的錯誤，以回到正常工作的狀態。

在 Closed 狀態下，錯誤計數器是基于時間的。在特定的時間間隔內會自動重置。這能夠防 止由于某次的偶然錯誤導致熔斷器進入斷開狀態。也可以基于連續失敗的次數。

斷開 (Open) 狀態：在該狀態下，對應用程序的請求會立即返回錯誤響應，而不調用后端的 服務。這樣也許比較粗暴，有些時候，我們可以 cache 住上次成功請求，直接返回緩存（當 然，這個緩存放在本地內存就好了），如果沒有緩存再返回錯誤（緩存的機制最好用在全站 一樣的數據，而不是用在不同的用戶間不同的數據，因為后者需要緩存的數據有可能會很 多）。

半開（Half-Open）狀態：允許應用程序一定數量的請求去調用服務。如果這些請求對服務 的調用成功，那么可以認為之前導致調用失敗的錯誤已經修正，此時熔斷器切換到閉合狀態 (并且將錯誤計數器重置)。
如果這一定數量的請求有調用失敗的情況，則認為導致之前調用失敗的問題仍然存在，熔斷器切 回到斷開狀態，然后重置計時器來給系統一定的時間來修正錯誤。半斷開狀態能夠有效防止正在 恢復中的服務被突然而來的大量請求再次拖垮。

熔斷設計的重點：
錯誤的類型。需要注意的是請求失敗的原因會有很多種。需要根據不同的錯誤情況來調整相 應的策略。所以，熔斷和重試一樣，需要對返回的錯誤進行識別。一些錯誤先走重試的策略 （比如限流，或是超時），重試幾次后再打開熔斷。一些錯誤是遠程服務掛掉，恢復時間比 較長；這種錯誤不必走重試，可以直接打開熔斷策略。

日志監控。熔斷器應該能夠記錄所有失敗的請求，以及一些可能會嘗試成功的請求，使得管 理員能夠監控使用熔斷器保護的服務的執行情況。

測試服務是否可用。在斷開狀態下，熔斷器可以采用定期地 ping 一下遠程的服務的健康檢查 接口，來判斷服務是否恢復，而不是使用計時器來自動切換到半開狀態。這樣做的一個好處 是，在服務恢復的情況下，不需要真實的用戶流量就可以把狀態從半開狀態切回關閉狀態。 否則在半開狀態下，即便服務已恢復了，也需要用戶真實的請求來恢復，這會影響用戶的真 實請求。

手動重置。在系統中對于失敗操作的恢復時間是很難確定的，提供一個手動重置功能能夠使 得管理員可以手動地強制將熔斷器切換到閉合狀態。同樣的，如果受熔斷器保護的服務暫時 不可用的話，管理員能夠強制將熔斷器設置為斷開狀態。

并發問題。相同的熔斷器有可能被大量并發請求同時訪問。熔斷器的實現不應該阻塞并發的 請求或者增加每次請求調用的負擔。尤其是其中的對調用結果的統計，一般來說會成為一個 共享的數據結構，這個會導致有鎖的情況。在這種情況下，最好使用一些無鎖的數據結構， 或是 atomic 的原子操作。這樣會帶來更好的性能。

資源分區。有時候，我們會把資源分布在不同的分區上。比如，數據庫的分庫分表，某個分 區可能出現問題，而其它分區還可用。在這種情況下，單一的熔斷器會把所有的分區訪問給 混為一談，從而，一旦開始熔斷，那么所有的分區都會受到熔斷影響。或是出現一會兒熔斷 一會兒又好，來來回回的情況。所以，熔斷器需要考慮這樣的問題，只對有問題的分區進行 熔斷，而不是整體。

限流設計：
保護系統不會在過載的情況下導致問題，那么，我們就需要限流，熔斷機制也是限流的一種。

限流的策略：

拒絕服務

服務降級

限流的實現方式：
計數器方式

隊列算法

漏斗算法

令牌桶算法

降級設計：

本質是為了解決資源不足和訪問量過大的問題

降級需要犧牲掉的東西有：
降低一致性。從強一致性變成最終一致性

停止次要功能。停止訪問不重要的功能，從而釋放出更多的資源。

簡化功能。把一些功能簡化掉，比如，簡化業務流程，或是不再返回全量數據，只返回部分 數據

要點:
對于降級，一般來說是要犧牲業務功能或是流程，以及一致性的。所以，我們需要對業務做非常 仔細的梳理和分析。我們很難通過不侵入業務的方式來做到功能降級。
在設計降級的時候，需要清楚地定義好降級的關鍵條件，比如，吞吐量過大、響應時間過慢、失 敗次數過多，有網絡或是服務故障，等等，然后做好相應的應急預案。這些預案最好是寫成代碼 可以快速地自動化或半自動化執行的。
功能降級需要梳理業務的功能，哪些是 must-have 的功能，哪些是 nice-to-have 的功能；哪 些是必需要死保的功能，哪些是可以犧牲的功能。而且需要在事前設計好可以簡化的或是用來應 急的業務流程。當系統出問題的時候，就需要走簡化應急流程。
降級的時候，需要犧牲掉一致性，或是一些業務流程：對于讀操作來說，使用緩存來解決，對于 寫操作來說，需要異步調用來解決。并且，我們需要以流水賬的方式記錄下來，這樣方便對賬， 以免漏掉或是和正常的流程混淆。
降級的功能的開關可以是一個系統的配置開關。做成配置時，你需要在要降級的時候推送相應的 配置。另一種方式是，在對外服務的 API 上有所區分（方法簽名或是開關參數），這樣可以由 上游調用者來驅動。
比如：一個網關在限流時，在協議頭中加入了一個限流程度的參數，讓后端服務能知道限流在發 生中。當限流程度達到某個值時，或是限流時間超過某個值時，就自動開始降級，直到限流好
轉。
對于數據方面的降級，需要前端程序的配合。一般來說，前端的程序可以根據后端傳來的數據來 決定展示哪些界面模塊。比如，當前端收不到商品評論時，就不展示。為了區分本來就沒有數 據，還是因為降級了沒有數據的兩種情況，在協議頭中也應該加上降級的標簽。
因為降級的功能平時不會總是會發生，屬于應急的情況，所以，降級的這些業務流程和功能有可 能長期不用而出現 bug 或問題，對此，需要在平時做一些演練。

轉載于:https://www.cnblogs.com/laowz/p/10089376.html

總結

以上是生活随笔為你收集整理的弹力设计总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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