Seata 簡介
Seata 的前身是阿里巴巴集團內大規模使用保證分佈式事務一致性的中間件，Seata 是其開源產品，由社區維護。在介紹 Seata 前，先與大家討論下我們業務發展過程中經常遇到的一些問題場景。
業務場景
我們業務在發展的過程中，基本上都是從一個簡單的應用，逐漸過渡到規模龐大、業務複雜的應用。這些複雜的場景難免遇到分佈式事務管理問題，Seata 的出現正是解決這些分佈式場景下的事務管理問題。介紹下其中幾個經典的場景：
場景一：分庫分表場景下的分佈式事務
起初我們的業務規模小、輕量化，單一數據庫就能保障我們的數據鏈路。但隨着業務規模不斷擴大、業務不斷複雜化，通常單一數據庫在容量、性能上會遭遇瓶頸。通常的解決方案是向分庫、分表的架構演進。此時，即引入了分庫分表場景下的分佈式事務場景。
場景二：跨服務場景下的分佈式事務
降低單體應用複雜度的方案：應用微服務化拆分。拆分後，我們的產品由多個功能各異的微服務組件構成，每個微服務都使用獨立的數據庫資源。在涉及到跨服務調用的數據一致性場景時，就引入了跨服務場景下的分佈式事務。
Seata 架構
- Transaction Coordinator（TC）事務協調器，維護全局事務的運行狀態，負責協調並驅動全局事務的提交或回滾。
- Transaction Manager（TM）控制全局事務的邊界，負責開啓一個全局事務，並最終發起全局提交或全局回滾的決議，TM 定義全局事務的邊界。
- Resource Manager（RM）控制分支事務，負責分支註冊、狀態彙報，並接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。RM 負責定義分支事務的邊界和行爲。
Seata 的可觀測實踐
爲什麼需要可觀測？
- 分佈式事務消息鏈路較複雜Seata 在解決了用戶易用性和分佈式事務一致性這些問題的同時，需要多次 TC 與 TM、RM 之間的交互，尤其當微服務的鏈路變複雜時，Seata 的交互鏈路也會呈正相關性增加。這種情況下，其實我們就需要引入可觀測的能力來觀察、分析事物鏈路。
- 異常鏈路、故障排查難定位，性能優化無從下手在排查 Seata 的異常事務鏈路時，傳統的方法需要看日誌，這樣檢索起來比較麻煩。在引入可觀測能力後，幫助我們直觀的分析鏈路，快速定位問題；爲優化耗時的事務鏈路提供依據。
- 可視化、數據可量化可視化能力可讓用戶對事務執行情況有直觀的感受；藉助可量化的數據，可幫助用戶評估資源消耗、規劃預算。
可觀測能力概覽
Metrics 維度
設計思路
- Seata 作爲一個被集成的數據一致性框架，Metrics 模塊將盡可能少的使用第三方依賴以降低發生衝突的風險
- Metrics 模塊將竭力爭取更高的度量性能和更低的資源開銷，儘可能降低開啓後帶來的副作用
- 配置時，Metrics 是否激活、數據如何發佈，取決於對應的配置；開啓配置則自動啓用，並默認將度量數據通過 prometheusexporter 的形式發佈
- 不使用 Spring，使用 SPI(Service Provider Interface) 加載擴展
模塊設計
- seata-metrics-core：Metrics 核心模塊，根據配置組織（加載）1 個 Registry 和 N 個 Exporter
- seata-metrics-api：定義了 Meter 指標接口，Registry 指標註冊中心接口
- seata-metrics-exporter-prometheus：內置的 prometheus-exporter 實現
- seata-metrics-registry-compact：內置的 Registry 實現，並輕量級實現了 Gauge、Counter、Summay、Timer 指標
metrics 模塊工作流
上圖是 metrics 模塊的工作流，其工作流程如下：
- 利用 SPI 機制，根據配置加載 Exporter 和 Registry 的實現類
- 基於消息訂閱與通知機制，監聽所有全局事務的狀態變更事件，並 publish 到EventBus
- 事件訂閱者消費事件，並將生成的 metrics 寫入 Registry
- 監控系統（如 prometheus）從 Exporter 中拉取數據
TC 核心指標
TM 核心指標
RM 核心指標
大盤展示
Tracing維度
Seata 爲什麼需要 tracing？
- 對業務側而言，引入 Seata 後，對業務性能會帶來多大損耗？主要時間消耗在什麼地方？如何針對性的優化業務邏輯？這些都是未知的。
- Seata 的所有消息記錄都通過日誌持久化落盤，但對不瞭解 Seata 的用戶而言，日誌非常不友好。能否通過接入 Tracing，提升事務鏈路排查效率？
- 對於新手用戶，可通過 Tracing 記錄，快速瞭解 Seata 的工作原理，降低 Seata 使用門檻。
Seata 的 tracing 解決方案
- Seata 在自定義的 RPC 消息協議中定義了 Header 信息
- SkyWalking 攔截指定的 RPC 消息，並注入 tracing 相關的 span 信息
- 以 RPC 消息的發出&接收爲臨界點，定義了 span 的生命週期範圍
基於上述的方式，Seata 實現了事務全鏈路的 tracing，具體接入可參考爲[Seata 應用 | Seata-server]接入 Skywalking[1]。
tracing 效果
- 基於的 demo 場景：
- 用戶請求交易服務
- 交易服務鎖定庫存
- 交易服務創建賬單
- 賬單服務進行扣款
- GlobalCommit 成功的事務鏈路（事例）
Logging 維度
設計思路
Logging 這一塊其實承擔的是可觀測這幾個維度當中的兜底角色。放在最底層的，其實就是我們日誌格式的設計，只有好日誌格式，我們才能對它進行更好的採集、模塊化的存儲和展示。在其之上，是日誌的採集、存儲、監控、告警、數據可視化，這些模塊更多的是有現成的工具，比如阿里的 SLS 日誌服務、還有 ELK 的一套技術棧，我們更多是將開銷成本、接入複雜度、生態繁榮度等作爲考量。
日誌格式設計
這裏拿 Seata-Server 的一個日誌格式作爲案例：
- 線程池規範命名：當線程池、線程比較多時，規範的線程命名能將無序執行的線程執行次序清晰展示
- 方法全類名可追溯：快速定位到具體的代碼塊
- 重點運行時信息透出：重點突出關鍵日誌，不關鍵的日誌不打印，減少日誌冗餘
- 消息格式可擴展：通過擴展消息類的輸出格式，減少日誌的代碼修改量
總結&展望
Metrics
總結：基本實現分佈式事務的可量化、可觀測。展望：更細粒度的指標、更廣闊的生態兼容。
Tracing
總結：分佈式事務全鏈路的可追溯。展望：根據 xid 追溯事務鏈路，異常鏈路根因快速定位。
Logging
總結：結構化的日誌格式。展望：日誌可觀測體系演進。
作者：察溯
本文爲阿里雲原創內容，未經允許不得轉載。