Design for failure常見的12種設計思想｜8月更文挑戰

一般狀況下，咱們的一個請求會通過三個服務來處理。

請 求從客戶端發出，到達 Proxy Layer（執行一些公共的邏輯，如邏輯、流控、審計等），完成後，發往 App Layer（執行具體業務邏輯），執行完畢後，發向 Data Laye（進行數據持久化）。

事情看起來很簡單，然而，在一個分佈式系統中：出錯是常態。

所以，咱們須要：Design For Failure。即當你的系統將錯誤看成正常流時，系統便已經對錯誤免疫了。

在此，跟你們介紹常見的 12 種設計思想。

一、防護性設計（Defensive Design）

所謂的防護性設計實際上就是「防呆」，英文叫 Idiot Proofing。說白了就是用戶有時候會不自覺的作一些蠢事，咱們在設計的時候要儘可能考慮到一些不規範的交互行爲，若是你的用戶是一隻猴子，你要寫包單保證系統不被玩壞。

例如，在 Android 開發中使用到的 Monkey Test 就是用於這樣的目的。

二、邊界狀況（Edge Case）

這個設計思想在測試領域比較常見，就是咱們在設計咱們的設計案例的時候有沒有充分考慮在邊界狀況下的系統行爲。

比較常見的例如，閏年狀況、跨日狀況等邊界。

三、防誤措施（Mistake Proofing）

怎麼保證不會發生錯誤。例如在人機交互環節，能不能進行輸入校驗？

四、解耦（Decoupling）

設計的時候，哪怕是最基礎的代碼也應該符合開閉原則。

Spring 的 IOC 就是爲了把對象建立及維護從原來的由引用類負責這種強耦合模式轉成經過 spring 容器負責。且解耦通常的作法是經過把內部邏輯封裝起來，暴露對外統一 API 接口，調用方不須要了解被調用方的內部邏輯實現，只須要知道提供什麼功能便可。

再引伸一下，解耦的做用就在於複用，把全部的高內聚功能獨立成一個個模塊，而後就能夠像樂高積木同樣根據調用方的實際需求進行組裝。

五、冗餘（Redundancy）

所謂的冗餘指的經過重複配置關鍵組件或部件，保證在關鍵組件失效的狀況下還有備份組件運做以便保證系統能夠繼續提供服務。生活中的例子請參與飛機的雙引擎設計。

主從模式就是冗餘的體現。在正常狀況下，主實例負責提供所有的服務，從實例在主實例總體或部分不可用的狀況下，徹底替代主實例總體或局部而對外提供服務。

六、重試（Retry）

重試是在分佈式系統下處理瞬態故障的一個基本手段，簡單有效（固然重試的前提是要求冪等）。可是重試也是能夠很危險的，它可以引發把一個局部小時間迅速升級爲一個系統重大故障，嚴重者致使系統假死。

舉個簡單例子：若是咱們的鏈路相似上圖，這裏會發生什麼問題？

在極端狀況下，重試次數達到 5*5*5*5=625 次。

當鏈路中的其中一個服務故障率異常的時候，那重試風暴便開啓了，由於重試爲服務器帶來額外的開銷和線程的佔用，而後其餘新來的請求又造成排隊，這樣的話就造成了相似的 DDos 惡性事件。

七、冷備（Cold Standby）

冷備實際上也是冗餘設計的其中一種體現，只是它會更側重於「冷」，意思是當系統發生宕機時，這個系統是須要手動啓動用於替換下線的主實例，它是跟熱備是不同，熱備更多體如今自動切換。

八、熔斷（Derating）

熔斷本質上就是一種防護性設計或者策略。假設一個微服務體系下的系統，其中 A 服務調用 B 服務。系統的 QPS 是千級別，當時若是 B 服務掛掉的話 A 的線程絕對在短期內佔滿耗盡而致使假死，從而造成大量 A 請求積壓而致使狀況惡化，最終造成雪崩。

九、容錯（Error Tolerance）

狹義的容錯泛指人機交互界面的時候須要對用戶輸入進行輸入校驗，保證數據準確性。

廣義的容錯應該是兩個具備明確邊界的事物（如服務間，系統間）交互時候針對可能發生的一切主客觀異常狀況的防護性手段。常見的容錯機制有 failsafe、failback、failover、failfast。

• failfast 更多指的是快速失敗，避免線程積壓致使系統滾雪球式崩潰。

• failover 指的是失效轉移。

• failsafe 指的是失效安全。

• failback 指的是失效自動恢復，將故障實例切換到備實例。

十、失效安全（Fail safe）

所謂的失效安全，就是指在特定失效的狀況下，一個系統或者服務也不會對業務形成損害。

例如：咱們使用 token 進行安全登陸也是一種失效安全的體現，若是 token 失效了（如時間過時），用戶是沒法登陸的，由於正常登陸須要 token 有一種約束因素，這種因素就是時間。若是時間過了，表明這種約束因素不存在或者再也不有效了，登陸功能就不能正常工做了。

十一、優雅降級（Graceful Degradation）

服務降級跟熔斷仍是挺像的，只是降級來得更加溫和和優雅一點。熔斷是直接斷掉防止異常進一步擴大而致使雪崩，可是咱們的終極目標是提供儘量多的服務，這個就是優雅降級的理念。在一些異常狀況或者秒殺場景下，爲了保證核心服務（如商品下單、支付）的正常可用，會放棄掉一些非核心服務（如歷史帳單查詢），這就是所謂的服務降級。

在微服務框架中，通常會使用 Hystrix 的 @HystrixCommand 或 Feign 的 @FeignClient 對服務進行聲明，而後爲每一個服務配置相應的 fallback 類，最終結合起來進行服務降級。

十二、耐用性（Durability）

這裏我理解的是系統或數據的耐受性。

例如數據，爲何咱們必定要持久化到數據庫，由於就是要藉助數據庫硬件各類維度的耐受性。

補充

做爲一名 designer 或者 developer，應該要對墨菲定律心存敬畏。

另外，須要額外補充一點的就是：監控（Monitoring）。

咱們的系統有哪幾個緯度的監控，估計最多就是常規的硬件狀態監控。固然這裏的監控我理解除了技術指標監控，還更應該有業務指標監控，不然咱們都在裸泳，等海水退下去後就一覽無遺。

監控其實是爲了更好的主動防護，一套完善的告警監控系統，可以快速通知開發與運維，開發側可以完成緊急修復並可以協同運維進行快速部署。

做者：架構精進之路，十年研發風雨路，大廠架構師，CSDN 博客專家，專一架構技術沉澱學習及分享，職業與認知升級，堅持分享接地氣兒的乾貨文章，期待與你一塊兒成長

關注並私信我回復「01」，送你一份程序員成長進階大禮包，歡迎勾搭。

Thanks for reading!