接口高可用整體框架

接口高可用架構的本質是"丟車保帥"策略，在系統面臨壓力時，業務或用戶體驗會部分有損，但能保證核心功能正常運行。接口高可用主要應對兩種效應：雪崩效應（請求量超過系統處理能力導致系統性能螺旋快速下降）和鏈式效應（某個故障引起后續一連串的故障）。

接口高可用的四大核心技術包括：限流、排隊、降級和熔斷。其中限流和排隊主要用于防止雪崩效應，而降級和熔斷則主要用于防止鏈式效應。

一、限流

限流是在用戶請求全流程的各個環節進行的流量控制措施，可分為三個層次：1. 請求端限流：在發起請求時就進行限流，被限流的請求實際上并沒有發給后端服務器。常見手段包括限制請求次數（如按鈕變灰）和嵌入簡單業務邏輯（如生成隨機數）。這種方式實現簡單，流量在本地就被控制，但只能防君子不防小人（腳本攻擊）。

2. 接入端限流：在接收到業務請求時進行限流，避免業務請求進入實際的業務處理流程。常見手段包括限制同一用戶請求頻率和隨機拋棄無狀態請求（如限流瀏覽請求，不限流下單請求）。這種方式實現較復雜，可以防刷，但限流閾值可能需要人工判斷。

3. 微服務限流：作為單個服務的自我保護措施，在處理能力不夠時丟棄新的請求。這種方式實現簡單，但處理能力難以精準配置。

限流算法主要有三種：

1. 時間窗口限流：   - 固定時間窗：統計固定時間周期內的請求量，超過閾值則限流。存在臨界點問題。   - 滑動時間窗：統計滑動時間周期內的請求量，超過閾值則限流。判斷比較準確，但實現稍微復雜。

2. 漏桶算法：   請求放入"桶"（如消息隊列），業務處理單元從桶里拿請求處理，桶滿則丟棄新的請求。技術本質是總量控制，桶大小是設計關鍵。優點是可以應對瞬時高并發流量（如0點簽到，整點秒殺），缺點是桶大小動態調整比較困難，無法精確控制處理速度。      Java實現漏桶算法的關鍵是：業務線程和IO線程分離，通過隊列傳遞請求；合理配置BlockingQueue的長度。      漏桶算法的變種是寫緩沖(Buffer)，如果漏桶容量無限（如用Kafka消息隊列），則可以用來做寫緩沖。技術本質是同步改異步，緩沖所有請求，慢慢處理。適用于高并發寫入請求，如熱門微博評論。

3. 令牌桶算法：   某個處理單元按照指定速率將令牌放入"桶"，業務處理單元收到請求后需要獲取令牌，獲取不到就丟棄請求。技術本質是速率控制，令牌產生的速度是設計關鍵。優點是可以動態調整處理速度，缺點是突發流量時可能丟棄很多請求，實現相對復雜。適用于控制訪問第三方服務的速度（防止把下游壓垮）和控制自己的處理速度（防止過載）。

二、排隊

排隊的基本原理是收到請求后并不同步處理，而是將請求放入隊列，系統根據能力異步處理。技術本質是請求緩存+同步改異步+請求端輪詢。適用于秒殺、搶購等場景。

排隊的架構設計關鍵在于：如何設計異步處理流程和如何保證用戶體驗（前端、客戶端交互）。

排隊的具體實現方案通常包括以下步驟：1. 用戶發起請求到排隊服務器2. 排隊服務器將請求放入隊列（如Kafka），并返回排隊號給用戶3. 用戶使用排隊號輪詢查詢處理狀態4. 業務服務器從隊列獲取請求并處理，處理完成后生成token并存儲（如Redis）5. 用戶查詢到token后，帶著token訪問實際的業務接口6. 業務接口驗證token有效性，并返回業務處理結果

以1號店雙十一秒殺排隊為例，其架構包括：排隊模塊（負責接收用戶搶購請求，將請求以先入先出方式保存）、調度模塊（負責排隊模塊到服務模塊的動態調度）和服務模塊（負責調用真正業務處理服務，并返回處理結果）。

三、降級

降級的基本原理是直接停用某個接口或URL，收到請求后直接返回錯誤（如HTTP 503）。主要應用于故障應急，通常將非核心業務降級，保住核心業務，例如降級日志服務、升級服務等。

降級架構實現的設計要點：1. 使用獨立系統操作降級，可以是獨立的降級系統，也可以是嵌入到其它系統的降級功能2. 人工判斷，人工執行，不要過度依賴自動化系統

四、熔斷

熔斷的基本原理是下游接口故障時，一定時期內不再調用該接口。主要應用于服務自我保護，防止故障鏈式效應。

熔斷架構實現的細節：1. 可以通過配置中心或配置文件來配置熔斷策略2. 熔斷處理一般由框架或SDK提供，例如Dubbo+Hystrix3. 熔斷策略一般按照失敗次數、失敗比例、響應時長等來確定

總結

接口高可用是系統架構設計中的重要環節，通過限流、排隊、降級和熔斷四種核心技術，可以有效防止系統在高負載或故障情況下出現雪崩效應和鏈式效應。這些技術各有特點和適用場景，架構師需要根據具體業務需求選擇合適的技術組合，實現系統的高可用性。