之前的兩篇文章我們介紹了微服務的基礎概念及其服務間通信機制。本篇將深入探討微服務的核心保障：服務保護與分布式事務。
一、微服務保護
問題描述：
在一個購物車的微服務中，倘若某一項服務（服務A）同一時刻訪問的數據十分龐大，但是購物車服務Tomcat的線程數據是有限的，這會導致整個購物車服務崩潰。倘若這個購物車服務又和別的微服務進行關聯，這樣一級連一級，最終可能導致整個微服務網絡的崩潰，也被稱做“雪崩”。
解決方法：
服務保護的方案有很多，最典型這幾種：
- 請求限流
- 線程隔離
- 服務熔斷
這些方法都不用我們親自一一實現，已經有一個組件把這些集成了起來，因此我們只需要學習這個組件就行了——Sentinel
1.1 Sentinel
Sentinel 是阿里巴巴開源的一款 輕量級流量控制、熔斷降級和系統保護組件，專注于解決微服務架構中的 高可用性、穩定性 問題。它提供實時的監控和動態規則配置，幫助開發者保障服務在 高并發、依賴故障、突發流量 等場景下的穩定性。
核心功能：
- 流量控制（Flow Control）：精準控制QPS、并發線程數，防止系統過載。
- 熔斷降級（Circuit Breaking）：自動檢測異常比例/響應時間，觸發熔斷保護。
- 系統自適應保護（System Adaptive Protection）：智能調整入口流量，保護系統不被壓垮。
- 實時監控（Real-time Monitoring）：可視化查看接口調用情況、限流熔斷數據。
1.2 請求限流
核心作用：通過精準控制單位時間內的請求量，防止突發流量導致系統過載崩潰。
實現原理：
- 設定QPS（每秒查詢量）或并發線程數閾值
- 超出閾值的請求將被立即拒絕或排隊等待
- 支持多種算法：固定窗口、滑動窗口、漏桶、令牌桶等
典型應用場景：
- 秒殺系統的高峰期流量控制
- API網關的全局流量管控
- 核心業務接口的訪問保護
1.3 線程隔離
核心機制：通過為每個微服務子服務分配獨立的執行線程池，實現故障隔離。
關鍵優勢：
- 資源隔離：單個子服務的線程池耗盡不會影響其他服務
- 故障隔離：崩潰的線程僅影響當前服務實例
- 彈性伸縮：可根據服務重要性動態調整線程池大小
實現方式對比：
| 隔離策略 | 實現方式 | 適用場景 | 資源消耗 |
|---|---|---|---|
| 線程池隔離 | 每個服務獨立線程池 | 耗時較長的同步調用 | 較高 |
| 信號量隔離 | 計數器控制并發數 | 輕量級快速調用 | 較低 |
最佳實踐：
- 關鍵服務配置更大的線程池
- 配合熔斷機制實現雙重保護
- 通過監控實時調整線程池參數
補充說明：
雖然線程隔離能有效防止級聯故障，但仍需配合熔斷機制使用。當某服務線程池完全耗盡時，熔斷器可以快速失敗并啟動降級策略，避免請求堆積。
1.4 服務熔斷
當系統檢測到某個子服務即將崩潰（如響應時間飆升、錯誤率激增）時，直接阻斷對該服務的所有請求，并快速返回一個預設的備選結果（Fallback），從而避免級聯故障。
所以，我們要做兩件事情：
- 編寫服務降級邏輯：就是服務調用失敗后的處理邏輯，根據業務場景，可以拋出異常，也可以返回友好提示或默認數據。
- 異常統計和熔斷：統計服務提供方的異常比例，當比例過高表明該接口會影響到其它服務，應該拒絕調用該接口，而是直接走降級邏輯。
三者對比
| 保護策略 | 核心機制 | 主要作用 | 觸發條件 | 實現方式 | 適用場景 | 代表框架 |
|---|---|---|---|---|---|---|
| 請求限流 | 控制單位時間請求量 | 防止突發流量壓垮系統 | QPS或并發數超過閾值 | - 計數器算法 - 漏桶/令牌桶算法 | - 秒殺系統 - API網關限流 | Sentinel、Redis RateLimit |
| 線程隔離 | 資源隔離（線程池/信號量） | 避免單個服務耗盡所有線程資源 | 線程池滿/信號量耗盡 | - 獨立線程池 - 信號量計數 | - 同步阻塞調用 - 耗時操作隔離 | Hystrix、Sentinel |
| 服務熔斷 | 快速失敗+自動恢復 | 防止級聯故障，提升系統可用性 | 錯誤率/慢調用比例超過閾值 | - 熔斷器狀態機（開/半開/關） - 降級策略 | - 弱依賴服務 - 第三方接口調用 | Sentinel、Resilience4j |
二、分布式事務
在分布式系統中，一個業務執行需要多個微服務共同參與。以圖中為例，整個業務為購買商品事務，交易服務、購物車服務和庫存服務為分支事務。在單體項目中，很容易滿足事務ACID原則，但是在分布式如何滿足？
2.1 Seata
核心定位：阿里巴巴開源的 一站式分布式事務解決方案，提供 AT、TCC、Saga、XA 多種模式，解決微服務架構下的數據一致性問題。
Seata的事務管理中有三個重要的角色：
- TC (Transaction Coordinator) - 事務協調者：維護全局和分支事務的狀態，協調全局事務提交或回滾。
- TM (Transaction Manager) - 事務管理器：定義全局事務的范圍、開始全局事務、提交或回滾全局事務。
- RM (Resource Manager) - 資源管理器：管理分支事務，與TC交談以注冊分支事務和報告分支事務的狀態，并驅動分支事務提交或回滾。
TM 就是全局事務的管理者，由這個決定什么時候開啟事務，什么時候提交和回滾事務，RM 就是針對自己的分支事務進行匯報，分支事務的回滾和提交。TC 其實就先相當于一個中間人， 監控所有RM 狀態匯報給到TM，然后什么操作有TM決定
而TC服務則是事務協調中心，是一個獨立的微服務，需要單獨部署
2.2 Seata的XA模型
RM一階段的工作：
- 注冊分支事務到
TC - 執行分支業務sql但不提交
- 報告執行狀態到
TC
TC二階段的工作：
TC檢測各分支事務執行狀態- 如果都成功，通知所有RM提交事務
- 如果有失敗，通知所有RM回滾事務
RM二階段的工作：
- 接收
TC指令，提交或回滾事務
2.3 Seata的AT模型
階段一RM的工作：
- 注冊分支事務
- 記錄undo-log（數據快照）
- 執行業務sql并提交
- 報告事務狀態
階段二提交時RM的工作：
- 刪除undo-log即可
階段二回滾時RM的工作：
- 根據undo-log恢復數據到更新前
2.4 兩個模型之間的區別
| 對比維度 | AT模型（自動補償） | XA模型（兩階段提交） |
|---|---|---|
| 一致性 | 最終一致性（存在短暫中間狀態） | 強一致性（全程數據鎖定） |
| 性能 | ????（一階段已提交，無阻塞） | ??（同步阻塞，資源長時間鎖定） |
| 侵入性 | 低侵入（無需改造業務代碼） | 低侵入（依賴數據庫原生XA協議） |
| 實現復雜度 | 簡單（自動生成反向SQL） | 中等（需數據庫支持XA） |
| 鎖范圍 | 全局行鎖（僅二階段沖突檢測時短暫加鎖） | 全程行鎖（Prepare階段即鎖定） |
| 補償機制 | 自動生成undo_log反向SQL | 依賴數據庫回滾（無自動補償） |
| 適用場景 | 高并發OLTP場景（如電商、庫存） | 傳統金融系統（如銀行核心賬務） |
| 數據庫支持 | 支持主流關系型數據庫（MySQL/Oracle等） | 需數據庫明確支持XA協議（如MySQL InnoDB） |
| 故障恢復 | 依賴undo_log恢復（需保證日志可靠） | 依賴數據庫日志恢復 |
| 典型框架 | Seata默認模式 | Seata XA模式、傳統JTA |
 調研)
