[熔斷、隔離、重試、降級、超時、限流，高可用架構流量治理核心策略全掌握](https://mp.weixin.qq.com/s/yaCgQlZp1sfZhfJU_Qu67A) [高并發架構設計（三大利器：緩存、限流和降級）](https://mp.weixin.qq.com/s/1mBorW_B2xvJ_8FjE_JrCw) # 簡介 高可用（High Availability, HA）方案是一種旨在保證系統在各種故障情況下仍能持續提供服務的設計策略。在分布式系統中，高可用主要通過冗余、負載均衡、數據備份與恢復、故障隔離和自動故障轉移等手段實現。 以下是一些常見的高可用設計方案： 1. 冗余部署：(jar包和mysql) * 主從模式：關鍵服務或組件進行主從備份，主節點處理請求，當主節點出現故障時，從節點接管服務 * 集群模式：多臺服務器組成集群，通過負載均衡技術分發請求，即使部分服務器宕機，其他服務器仍可繼續提供服務。 2. 負載均衡： * 使用負載均衡器如Nginx、Ribbon等，根據預設策略將用戶請求分發到不同的后端服務器，提高系統的并發處理能力和容錯性。 3. 數據持久化與備份： * 數據庫層面采用主從復制、集群、分區等技術，確保數據的可靠性與一致性，并定期進行備份以應對數據丟失風險。 * 對于分布式存儲，可以使用副本集等方式提高數據安全性。 4.故障檢測與隔離： * 健康檢查：定期對各個服務進行健康狀態檢測，一旦發現異常，立即將其剔除出服務列表，避免影響整個系統的穩定性。 * 服務熔斷與降級：如Hystrix、Sentinel等框架提供的熔斷機制，當依賴的服務出現故障時，及時切斷調用鏈，防止雪崩效應。 5.自動故障轉移： * 在云環境下，可以通過云服務商提供的彈性伸縮、自動修復等功能實現自動故障轉移。 * 在自建環境中，可通過心跳檢測、ZooKeeper等工具進行服務注冊與發現，以及主備切換。 6.異地多活/多數據中心： * 在地理上分散部署多個數據中心，每個中心都能獨立對外提供服務，當某個數據中心發生故障時，流量可以迅速切換至其他數據中心。 7.強一致性的分布式事務： * 利用分布式事務解決方案如兩階段提交（2PC）、三階段提交（3PC）、TCC、Saga等保證跨服務操作的一致性。 綜合運用上述多種技術和策略，可以在最大程度上提升系統的穩定性和可用性，降低由于單點故障導致的服務中斷風險。 # 主要涉及的技術 熔斷：一種保護機制，當某個服務出現故障或響應超時時，為了防止整個系統出現雪崩效應，熔斷機制會暫時停止對該服務的調用，并快速返回一個錯誤信息或備用方案，從而保護系統的穩定性和可用性。通過設置閾值和時間窗口，當服務的錯誤率或響應時間超過預設的閾值時，可以觸發熔斷，并在一段時間內拒絕請求。這可以減輕故障對系統的影響，提高系統的可用性。 降級：降級是在系統負載過高或出現異常情況時，臨時關閉一些非關鍵的功能或服務，以保證核心功能的可用性。通過降級，可以將系統的負載降低到可接受的范圍內，避免系統崩潰或無法響應。 限流：限流是控制系統流量的手段，可以限制并發請求的數量，以保護系統免受過載的影響。通過設置最大并發數或請求速率，可以防止系統被過多的請求壓垮，保持系統的穩定性和可用性。 超時：設置合理的超時時間是保證系統可用性的重要手段。當服務請求超過預設的時間限制時，可以主動中斷請求，避免長時間的等待導致系統資源浪費。通過合理設置超時時間，可以提高系統的響應速度和穩定性。 隔離：隔離是將不同的服務或模塊之間的流量進行分離，以降低由于某個服務或模塊故障而對整個系統產生的影響。通過隔離，可以將流量限制在一個有限的范圍內，使故障局限在一個較小的區域，以保證系統的可用性。 重試：重試是當服務請求失敗時，自動進行重試，以增加請求成功的概率。通過設置最大重試次數和重試策略，可以在服務不可用或響應延遲的情況下，嘗試重新發送請求，以提高系統的可用性。但重試存在風險，它可能會解決故障，也可能會放大故障。 冪等：在處理網絡請求、數據庫操作、分布式系統等領域，冪等性是無論一個操作執行一次還是多次，結果都是相同的。重試可能會導致重復觸發，出現臟數據，一般重試會和冪等結合使用。 多活策略（冗余部署）：一種提高系統可用性和容錯能力的策略，在系統多個節點或實例上同時運行應用程序，并確保每個節點或實例都能夠處理請求，從而提高系統的整體可用性和容錯能力，以確保在部分節點或服務器出現故障時，系統依然能夠正常運行。 容災備份：為了保障應用程序的穩定運行和數據安全，在出現故障或災難時能夠快速恢復業務和數據而采取的一系列措施。容災備份包括數據備份、系統備份、容災演練等多個方面。 負載均衡：提高系統性能和可靠性的關鍵策略，通過將請求分散到多個服務器或節點上，以確保系統能夠高效、穩定地處理大量并發請求。 自動故障轉移：在系統出現故障時，能夠自動將業務從一個節點或實例轉移到另一個健康的節點或實例上，以保證業務的連續性和系統的可用性。 ## 熔斷 當某個服務出現故障或響應超時時，為了防止整個系統出現雪崩效應，熔斷機制會暫時停止對該服務的調用，并快速返回一個錯誤信息或備用方案，從而保護系統的穩定性和可用性。 熔斷的主要方式是使用斷路器阻斷對故障服務器的調用。 ### 主要作用： 1. 快速失敗：當依賴的服務不穩定或響應超時時，熔斷機制能夠迅速判斷并中斷對該服務的調用，避免無謂的等待和資源浪費，防止整個系統出現雪崩效應。 2. 自動恢復：熔斷機制會根據一定的算法和策略，動態地探測依賴服務的健康狀況，當服務恢復穩定后，會自動解除熔斷狀態，恢復正常的服務調用。 3. 服務降級：在熔斷期間，為了保證整體系統的可用性，可以采用服務降級的策略。即暫時舍棄一些非核心的功能或數據請求，直接返回一個預設的錯誤處理信息或備用方案。 ### 斷路器有三種狀態，關閉、打開、半打開。 * 關閉：默認狀態，允許請求訪問，同時會記錄一定時間內的成功和失敗次數，到達設置的錯誤率將切換為打開，拒絕請求訪問。 * 打開：對請求返回錯誤信息或者執行降級處理邏輯，不會調用目標接口。 * 半打開：在進入打開狀態后，會有一個超時時間，超過之后會進入半打開狀態，此時會允許一定數量的請求去調用目標接口。 * 對成功執行的調用進行計數，達到配置的閾值后會認為目標服務恢復正常，此時熔斷器回到“關閉”狀態； * 如果有請求出現失敗的情況，則回到“打開”狀態，并重新啟動超時計時器，再給系統一段時間來從故障中恢復。 當進入 打開 狀態時會拒絕所有請求；進入 關閉 狀態時瞬間會有大量請求，這時服務端可能還沒有完全恢復，會導致熔斷器又切換到 打開 狀態；而 半打開 狀態存在的目的在于實現了服務的自我修復，同時防止正在恢復的服務再次被大量打垮，所以是一種比較剛性的熔斷策略。 阿里 sentinel 可以實現熔斷，限流，降級 ## 降級 在系統負載過高或出現異常情況時，臨時關閉一些非關鍵的功能或服務，以保證核心功能的可用性。 ### 主要作用包括： 1. 減輕負載壓力：在系統負載過高或資源不足的情況下，通過降級非核心功能或服務，可以減輕系統的負載壓力，避免系統崩潰或性能下降。 2. 保證核心業務：降級策略可以確保核心業務的正常運行，即使在一些非關鍵功能上做出妥協，也能保證整體業務的穩定性和可用性。 3. 靈活應對變化：降級策略可以根據實際情況進行靈活調整，例如根據系統負載、響應時間等指標動態地調整降級策略，以適應不同的業務場景和需求。 4. 降級屬于有損操作。 阿里 sentinel 可以實現熔斷，限流，降級 ### 降級策略： 1. 降低體驗性 把高體驗性改成低體驗性，犧牲用戶體驗保證功能完整 2. 放棄非核心功能的功能 比如雙十一退貨退款功能停用 3. 降低一致性 點贊量，評論量等數據做成最終一致性，并且允許較長時間的不一致 4. 降低數據量 限制返回的數據量，數據只能指定月份查詢 #### 自動降級 * 適合觸發條件明確可控的場景，比如請求調用失敗次數大于一定的閾值，服務接口超時等情況； * 對于一些旁路服務，服務負載過高也可以直接觸發自動降級。 #### 手動降級 * 降級操作都是有損的，部分情況下需要根據對業務的影響程度進行手動降級； * 通常需要先制定降級的分級策略，影響面由淺至深。 ## 限流 限制并發請求的數量，以保護系統免受過載的影響。 阿里 sentinel 可以實現熔斷，限流，降級 限流實現的兩個關鍵點： 1.如何判斷系統是否過載 - 資源使用率； - 請求成功率； - 響應時間； - 請求排隊時間 2.過載時如何選擇要丟棄的請求 - 按照主調方（客戶端）的重要性來劃分優先級 - 根據用戶的重要性進行區分。 常見的限流算法： 1. 計數器限流 2. 滑動窗口限流 3. 漏桶限流 4. 令牌桶限流 ## 隔離 隔離是將不同的服務或模塊之間的流量進行分離，以降低由于某個服務或模塊故障而對整個系統產生的影響。 每個系統可以有自己獨立的代碼庫，獨立開發，獨立發布。一旦出現故障，也不會相互干擾。 隔離最常見的微服務解決方案。 ### 動靜隔離 系統的動態內容和靜態內容分開處理 就是Nginx動靜分離，將網站靜態資源（HTML，JavaScript，CSS，img等文件）與后臺應用分開部署，提高用戶訪問靜態代碼的速度，降低對后臺應用服務器的請求。后臺應用服務器只負責動態數據請求。 靜態還可以把前端css、js、圖片、文件等靜態資源存儲到 OSS 并通過 CDN 進行訪問加速。 ### CDN加速 CDN的工作原理就是將您源站的資源緩存到位于全球各地的CDN節點上，用戶請求資源時，就近返回節點上緩存的資源，而不需要每個用戶的請求都回您的源站獲取，避免網絡擁塞、緩解源站壓力，保證用戶訪問資源的速度和體驗。 ### 讀寫隔離 將讀操作和寫操作分離到不同的服務或實例中處理 大部分的系統里讀寫操作都是不均衡的，寫數據可能遠遠少于讀數據； 業務上配置數據庫的讀寫分離 比如我們系統有個專門對外共享數據的功能， 這個功能主要就是讀，這時候單獨弄成一個服務，核心功能也在這個服務里，盡量不與其他服務產生關聯，數據庫也讀取備庫，這樣這個服務宕機也不會影響系統的其他核心功能 ### 核心隔離 核心隔離通常是指將資源按照 “核心業務”與 “非核心業務”進行劃分，優先保障“核心業務”的穩定運行。 按照服務的核心程度進行分級，比如我們有些專題是領導使用，這樣的就是非常核心的業務 核心業務部署到性能更好的服務器上 核心業務可以搭建多集群通過冗余資源來提升吞吐和容災能力； 比如有個專題開發完成之后基本不動，但是這個專題是給上級單位領導看的大屏，這時候我們就是前端和后臺全部與其他功能分開，重新寫了一套并集群部署。 ### 熱點隔離 針對高頻訪問數據（熱點數據）的隔離策略 將訪問頻次最高的數據緩存起來，可以顯著減少對后端存儲服務的訪問壓力，同時提高數據訪問的速度； 可以創建一個獨立的緩存服務來存儲和管理熱點數據，實現熱點數據的隔離。 ### 集群隔離 將某些服務單獨部署成集群，或對于某些服務進行分組集群管理 比如有個專題開發完成之后基本不動，但是這個專題是給上級單位領導看的大屏，這時候我們就是前端和后臺全部與其他功能分開，重新寫了一套并集群部署。 ### 機房隔離 在不同的機房或數據中心部署和運行服務，實現物理層面的隔離 大型系統采用的，一般系統用不到 解決數據容量大、計算和 I/O 密集度高的問題，比如把北京的數據存儲在北京的服務器，上海的存儲在上海的服務器，這種區域化的數據管理能有效地分散流量和系統負載； 增強數據安全性和災難恢復能力。通過在不同地理位置建立服務的完整副本（包括計算服務和數據存儲），系統可以實現異地多活或冷備份。 ## 超時 當服務請求超過預設的時間限制時，可以主動中斷請求，避免長時間的等待導致系統資源浪費。 ### 主要作用有以下幾點： 1. 保護系統資源：由于各種不確定性的因素可能導致接口調用時間的不確定性，設置超時時間可以防止接口調用無限制地等待響應，從而避免系統資源的長時間占用和可能的系統崩潰。 2. 提高用戶體驗：對于與用戶操作相關的接口，如果不設置超時時間，可能會出現長時間的無響應，這將嚴重影響用戶的體驗。 3. 保證業務連續性：在負載很高的系統中，大量調用耗時長的接口可能導致系統性能急劇下降，影響其他正常的業務。設置超時時間可以在一定程度上保證系統的業務連續性。 4. 協調不同服務：在微服務架構中，服務間的調用通常會設置超時時間。當某個服務出現故障或響應超時時，調用方可以根據超時時間做出相應的處理，比如重試、降級或熔斷，從而協調不同服務之間的交互。 接口設置超時時間是一種有效的保護機制，可以提高系統的健壯性、用戶體驗和業務連續性。在實際應用中，需要根據具體業務場景和需求來合理設置超時時間。 無論是內部服務之間調用還是調用第三方接口都應設置超時時間，比如下載文件的連接超時時間和讀取超時時間，如果是事務里調用了第三方接口，不設置這倆時間可能會導致事務一直無法提交最終耗盡數據庫連接。 ## 重試 重試是當服務請求失敗時，自動進行重試，以增加請求成功的概率。 網絡是脆弱的，隨時都可能會出現抖動，解決的辦法之一就是重試。但重試存在風險，它可能會解決故障，也可能會放大故障。 > **重試一定要保證重復執行不會造成系統數據錯誤，保證冪等性。** 通過設置最大重試次數和重試策略，可以在服務不可用或響應延遲的情況下，嘗試重新發送請求，以提高系統的可用性。但重試存在風險，它可能會解決故障，也可能會放大故障。 簡單重試：可以在調用接口返回失敗之后，系統簡單地再調用一遍。這種策略通常適用于瞬態錯誤，如暫時的網絡中斷或服務重啟。 復雜重試：可以設置重試次數已經重試間隔，spring-retry 組件 ## 冪等 在處理網絡請求、數據庫操作、分布式系統等領域，冪等性是無論一個操作執行一次還是多次，結果都是相同的。重試可能會導致重復觸發，出現臟數據，一般重試會和冪等結合使用。 冪等設置主要是處理重復請求，保證多次重復請求獲得預期結果一致 ### 主要作用： 1. 解決重試機制導致的重復：在網絡請求或分布式系統中，由于網絡波動、超時等原因，請求可能會被重復發送。冪等性可以確保即使請求被重復發送，系統也只會執行一次操作，防止重復操作導致的數據不一致問題。 2. 解決用戶的重復操作：在Web應用中，用戶可能會因為網絡延遲或手抖或有意重復點擊，會導致發送多個相同的請求，又或者太多用戶執行同一操作導致并發太高。冪等性可以確保即使用戶多次點擊，系統也只會執行一次操作，優化用戶體驗。 ### 解決方案： 主要解決的是添加和編輯功能 唯一約束：比如注冊用戶時，用戶名稱是唯一的，數據庫設置為唯一索引，在業務上做校驗，都可以根據唯一性去處理 業務狀態：比如審核功能，可以根據當前的業務狀態去判斷當前流程是否重復審核 版本號：表增加版本號字段，每次修改時，版本號字段都加1，版本號對應不上說明已經更新過了 Token機制：進入表單頁面先去后臺獲取一個唯一令牌，提交時把令牌也帶上，服務端校驗，業務執行完刪除令牌。 前端提交后禁用提交按鈕：前端點擊提交按鈕后，直接把按鈕禁用，也可以在提交后在vue的請求config配置全局loading效果。因為是純前端實現，實現簡單，適合要求低的小項目（有比沒有強的那種項目，因為有些外包項目基本就沒做冪等）。 全局唯一ID：根據業務的操作和內容生成一個全局ID，在執行操作前先根據這個全局唯一ID是否存在，來判斷這個操作是否已經執行。 鎖：分布式鎖，數據庫行鎖，樂觀鎖等等，可以結合上面幾種一塊使用 ## 多活策略（冗余部署）： 一種提高系統可用性和容錯能力的策略，在系統多個節點或實例上同時運行應用程序，并確保每個節點或實例都能夠處理請求，從而提高系統的整體可用性和容錯能力，以確保在部分節點或服務器出現故障時，系統依然能夠正常運行。 多活策略雖然可以提高系統的可用性和容錯能力，但也會增加系統的復雜性和管理成本。 ### 主要作用： 1. 提高可用性：冗余部署能夠在節點或服務器出現故障時，自動切換到其他正常運行的節點或服務器，從而確保系統始終可用。 2. 增強容錯能力：冗余部署可以分散系統的負載，減少單點故障的風險。當某個節點或服務器出現故障時，其他節點或服務器可以接管其任務，保證業務的連續性。 3. 負載均衡：通過冗余部署，可以將請求分散到多個節點或服務器上，實現負載均衡，提高系統的處理能力和響應速度。 ### 方案 1. 多實例集群部署：在同一臺物理機或虛擬機上部署多個應用程序實例，每個實例監聽不同的端口或使用不同的配置文件。通過負載均衡器將請求分發到這些實例上，實現多活。 2. 容器化集群：利用容器技術（如Docker、Kubernetes）實現多活策略。通過容器編排工具創建和管理多個容器實例，每個容器實例運行一個應用程序。容器編排工具負責容器的調度、負載均衡和故障轉移。 3. 微服務架構：將應用程序拆分為多個微服務，每個微服務獨立部署和運行。每個微服務都可以有多個實例，通過服務注冊與發現機制實現多活。 4. 數據庫集群：對于數據庫系統，可以采用多主復制或分布式數據庫實現多活。多主復制允許多個節點同時寫入數據，提高系統的可用性和性能。分布式數據庫將數據分散存儲在多個節點上，每個節點都可以處理讀寫請求。 5. 負載均衡器：使用負載均衡器將請求分發到多個應用程序實例上。負載均衡器可以根據一定的算法（如輪詢、最小連接數等）將請求轉發到不同的實例，實現負載均衡和多活。 ### 容災備份 為了保障應用程序的穩定運行和數據安全，在出現故障或災難時能夠快速恢復業務和數據而采取的一系列措施。容災備份包括數據備份、系統備份、容災演練等多個方面。 ### 數據備份 數據備份是容災備份的核心，主要包括對數據庫、文件系統等關鍵數據的備份。備份的頻率、存儲周期、備份策略等需要根據業務需求和數據重要性來制定。 ### 系統備份 目前有很多服務器是搞得虛擬服務器，可以對其進行整體備份，使用的容器的話，也可以容器備份 ### 容災演練 容災演練是為了驗證容災備份的有效性而進行的模擬故障恢復操作。通過容災演練可以發現備份數據的問題、優化備份策略、提高故障恢復能力。 ## 負載均衡 提高系統性能和可靠性的關鍵策略，通過將請求分散到多個服務器或節點上，以確保系統能夠高效、穩定地處理大量并發請求。 ### 作用 1. 提高系統性能：負載均衡可以將請求分發到多個服務器上，使得每個服務器只處理部分請求，從而降低了單個服務器的負載，提高了系統的整體性能。 2. 增強系統可靠性：當某個服務器出現故障時，負載均衡器可以將其從服務器池中移除，將請求轉發到其他正常的服務器上，保證了系統的可靠性。 3. 提高資源利用率：通過負載均衡，可以更加合理地利用服務器資源，避免了資源的浪費和瓶頸問題。 ### 方案 1. 軟件負載均衡：使用專門的負載均衡軟件，如Nginx、HAProxy等，將請求分發到多個應用服務器實例上。這些負載均衡軟件通常具有豐富的負載均衡算法和配置選項，可以根據業務需求進行靈活配置。 2. 硬件負載均衡：使用專門的負載均衡硬件設備，如F5、Citrix等。這些設備通常具有高性能和穩定性，適用于大規模和高要求的系統。硬件負載均衡設備通常提供豐富的負載均衡策略、健康檢查、會話保持等功能。 3. 反向代理：通過反向代理服務器（如Nginx、Apache等）實現負載均衡。反向代理服務器接收客戶端的請求，然后根據負載均衡算法選擇一個應用服務器實例進行轉發。反向代理服務器還可以提供緩存、SSL終止等功能。 4. 容器化負載均衡：在容器化環境中，可以使用容器編排工具（如Kubernetes）提供的負載均衡功能。Kubernetes可以通過Service資源實現負載均衡，將請求分發到多個Pod實例上。此外，Kubernetes還支持Ingress資源，可以實現更高級別的負載均衡和訪問控制。 ## 自動故障轉移 在系統出現故障時，能夠自動將業務從一個節點或實例轉移到另一個健康的節點或實例上，以保證業務的連續性和系統的可用性。 ### 作用 1. 保證業務連續性：在系統出現故障時，自動故障轉移機制能夠快速將業務轉移到其他健康的節點或實例上，確保業務不中斷。 2. 提高系統可用性：通過自動故障轉移，系統可以自動排除故障節點或實例，保證剩余的健康節點或實例能夠繼續處理請求。 3. 減少人工干預：自動故障轉移機制能夠自動處理故障轉移過程，減少了人工干預的需要，降低了運維成本。 ### 方案 1. 使用負載均衡器：負載均衡器通常具有故障檢測和健康檢查功能，可以自動檢測和排除故障節點或實例。當負載均衡器檢測到某個節點或實例出現故障時，可以將其從服務器池中移除，并將請求轉發到其他健康的節點或實例上。 2. 使用分布式系統框架：一些分布式系統框架（如Apache ZooKeeper、etcd等）提供了自動故障轉移的功能。這些框架可以維護一個集群的狀態，并在節點或實例出現故障時自動進行故障轉移。例如，ZooKeeper可以通過選舉新的Leader節點來實現自動故障轉移。 3. 微服務架構：在微服務架構中，每個微服務都可以有多個實例，并且每個實例都可以注冊到服務注冊中心。當某個實例出現故障時，服務注冊中心可以將其從服務列表中移除，并將請求轉發到其他健康的實例上。這種機制可以實現微服務的自動故障轉移。 4. 數據庫自動故障轉移：對于數據庫系統，可以采用主從復制或集群的方式實現自動故障轉移。當主節點出現故障時，從節點可以自動升級為主節點，并接管主節點的業務。一些數據庫管理系統（如MySQL、PostgreSQL等）提供了自動故障轉移的功能。