背景前序

正如所看到的文章題目，就在此時，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 分享的時候都有用戶提問，Seata性能消耗數據，因為分布式事務的性能消耗與場景關系非常大，所以用戶通過 SkyWalking 可以更簡單的觀測自己的場景，自己給自己答案。

分布式事務執行過程有痕跡

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

定位問題的提效

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

入門 Seata 提高一個維度

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