在微服務架構中，服務限流、降級、熔斷和隔離是保障系統高可用性的核心手段，但它們解決的問題和應用場景不同。以下是它們的區別、解決方案和實際案例的詳細說明：

---

一、服務限流（Rate Limiting）

定義：通過限制單位時間內的請求數量，防止系統因突發流量過載。
核心區別：主動防御，從入口控制流量。
解決方案：
? 計數器算法：簡單計數，超過閾值拒絕請求。
? 滑動窗口算法：更精準的時間窗口計數（如 Redis + Lua）。
? 漏桶算法：恒定速率處理請求（如 Apache Guava 的 RateLimiter）。
? 令牌桶算法：允許突發流量（如 Nginx 的 limit_req 模塊）。

實際例子：
? 電商秒殺場景：商品庫存僅 1000 件，通過令牌桶算法限制每秒最多處理 500 個請求，超出部分直接返回“活動太火爆，請稍后再試”。
? API 網關：某第三方地圖服務對免費用戶限制每秒 10 次調用，防止資源濫用。

---

二、服務降級（Fallback）

定義：在系統壓力過大時，暫時關閉非核心功能，釋放資源給核心流程。
核心區別：功能取舍，優先保障核心業務。
解決方案：
? 手動降級：運維通過配置中心（如 Nacos）動態關閉非核心功能。
? 自動降級：基于監控指標（如 CPU >80%）觸發降級策略。
? 默認返回值：直接返回緩存數據或靜態頁面（如 Hystrix 的 fallbackMethod）。

實際例子：
? 雙十一大促：關閉商品評價、推薦算法等非核心功能，確保下單、支付鏈路暢通。
? 天氣服務故障：降級時返回默認天氣數據（如北京默認 25°C），而非直接報錯。

---

三、熔斷（Circuit Breaking）

定義：當服務調用失敗率超過閾值時，暫時停止訪問故障服務，避免雪崩效應。
核心區別：快速失敗，防止故障擴散。
解決方案：
? 熔斷器模式：Hystrix、Resilience4j、Sentinel 等框架支持熔斷策略。
? 狀態機：關閉（直接拒絕請求）、半開（嘗試探測恢復）、打開（允許部分請求通過）。

實際例子：
? 支付服務超時：若連續 5 次調用支付接口超時，熔斷 30 秒，期間直接返回“系統繁忙，請稍后支付”。
? 數據庫訪問異常：當 SQL 失敗率超過 50% 時，熔斷數據庫訪問，改用緩存數據響應。

---

四、隔離（Isolation）

定義：通過資源隔離，避免單一服務故障影響整個系統。
核心區別：資源劃分，減少故障影響范圍。
解決方案：
? 線程池隔離：為不同服務分配獨立線程池（如 Hystrix 的 THREAD 隔離模式）。
? 信號量隔離：限制并發請求數（sentinel）。
? 物理隔離：不同服務部署到獨立的容器或 VM（如 Kubernetes 的 Namespace）。

實際例子：
? 用戶服務與訂單服務隔離：用戶認證服務使用獨立線程池，即使認證接口卡頓，也不會阻塞訂單生成。
? CPU 密集型任務隔離：將圖像處理服務部署到獨立容器，避免占用 API 服務的 CPU 資源。

---

五、協同使用場景示例

電商系統故障處理流程：

1. 限流：網關限制秒殺入口每秒 1000 個請求。
2. 隔離：秒殺服務使用獨立線程池，與普通商品查詢服務資源隔離。
3. 熔斷：若庫存服務響應超時 3 次，熔斷 10 秒，期間直接返回“庫存更新中”。
4. 降級：熔斷觸發后，降級推薦服務，返回靜態熱門商品列表。

---

六、常用技術棧對比

手段	常用工具/框架	適用場景
限流	Nginx、Sentinel、Guava	API 網關、秒殺活動
降級	Hystrix、Sentinel、Nacos	大促期間非核心功能關閉
熔斷	Hystrix、Resilience4j	依賴服務頻繁超時或報錯
隔離	Docker、Kubernetes、Hystrix	資源競爭嚴重或關鍵服務保護

---

總結

? 限流是流量入口的“閥門”，控制請求數量。
? 降級是功能維度的“止損”，優先保障核心業務。
? 熔斷是故障服務的“保險絲”，快速切斷故障源。
? 隔離是資源層面的“屏障”，縮小故障影響范圍。

實際系統中，這些手段通常結合使用：例如通過 Sentinel 同時實現限流和熔斷，配合 Kubernetes 資源隔離，再通過 Nacos 動態下發降級策略，形成完整的彈性防護體系。