誰比 Seata 還懂 Seata？SkyWalking-

作者：趙禹光，Seata Contributor，SkyWalking PMC

背景前序

正如所看到的文章題目，就在此時，Seata 與 SkyWalking 兩個生態融合, 取得了階段性成果。下面就結合文章內容，給你徐徐道來。

事情的起因是這樣的，Seata、SkyWalking 分別是分佈式事務領域、一站式 APM 領域的的佼佼者，這一點通過 Github Star 排名就可以知道，也就不再贅述了。所以早在 2019 年，Seata 的用戶就提出了使用 SkyWalking 觀測的訴求。

Seata 融入 SkyWalking 監控後，就有了 APM 特性，用戶在定位 Seata 分佈式事務的問題時，可以通過分佈式鏈路、機器指標、日誌內容等多個維度進行問題剖析，實現定位問題的提效。

那結合這個訴求，兩個社區感興趣的同學就開始展開了初步討論和實踐，但是由於當時 Seata 的傳輸協議中，沒有類似於 HTTP Header 的面向傳輸的消息頭部，所以實現的第一版雖然實現了監控觀測，但是兼容性非常不友好，這在解決分佈式事務的監控中，顯然是有欠缺的。故此，我們開啓了二番討論，結論是兼容性的前置條件是必須的，所以，Seata 要實現傳輸協議升級，就此 Seata 將此事放在了 RoadMap 中。SkyWalking 社區這邊也暫時擱置了這件事。

時光荏苒，轉眼 1 年多就過去了，Seata 社區在過程中已經完成了傳輸協議的升級，那我們就重啓此事。

一. Seata 接入 SkyWalking 後，用戶得到了什麼

背景已經敘述完了，由於時間有些久，可能大家對兩個生態融合之後帶來的效果，也不是很清晰了，這裏就我的個人的理解，介紹下兩個生態融合後，給用戶帶來的益處：

我看到很多 Seata 的分享的時候都有用戶提問，Seata 性能消耗數據，因爲分佈式事務的性能消耗與場景關係非常大，所以用戶通過 SkyWalking 可以更簡單的觀測自己的場景，自己給自己答案。

在 AT 模式下，Seata 通過面向傳輸的消息頭部，傳遞全局事務 XID，全局事務執行完成後，每個在 DB 中的執行過程都會被清理掉，這在回溯執行過程的時候非常不友好，這些海量數據 Seata 可不會存儲，這嚴重增加分佈式事務關聯數據庫表的空間，帶來不必要的性能消耗。所以兩個生態融合後，SkyWalking 相關的數據庫監控，就可以記錄這些執行過程的海量數據。

在日誌中打印 XID 的同時打印 TraceId，當出現問題想回溯 XID 相關聯的全局鏈路時，在 SkyWalking 的展示端輸入 TraceId 即可，通過 Seata 整體監控融入 SkyWalking，不僅擁有全鏈路領域的監控，還在儀表盤、拓撲圖、在線剖析和報警都得到了監控。

分佈式事務一直被炒得很熱，但真正能在市場上落地的也只有 Seata，所以 Seata 並沒有開源的學習範本，所以快速帶領大家入門的資料也比較少。而且 Seata 有 3 個角色、4 中經典模式，可以多種組合，綜上所訴，不由得讓使用者雲裏霧裏，兩個生態融合後，用戶可以清晰從上帝 (監控) 知道 Seata 的執行過程，進而透析工作原理。

二. 典型 AT 模式監控場景

下面就官方 AT 模式的 Demo，展示下接入後的 APM 特性。

2.1 官方描述的 ToC 交易場景

  1. 用戶請求交易服務

  2. 交易服務鎖定庫存

  3. 交易服務創建賬單

  4. 賬單服務進行扣款

2.1.2 當 Seata 與 SkyWalking 融合後，場景復原

2.1.3 全局事務正常鏈路描述

2.1.3 全局事務異常鏈路描述

用戶手冊

官網 SkyWalking APM: http://seata.io/zh-cn/docs/user/apm/skywalking.html

常用鏈接

歡迎大家將 Seata 相關的實踐文章投稿至：slievrly@gmail.com

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ok5Z_zOE9x62rMSKQGxV-w

猜你喜歡