作者：趙禹光，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 分享的時候都有使用者提問，Seata性能消耗資料，因為分布式事務的性能消耗與場景關系非常大，是以使用者通過 SkyWalking 可以更簡單的觀測自己的場景，自己給自己答案。
- 分布式事務執行過程有痕迹
在 AT 模式下，Seata 通過面向傳輸的消息頭部，傳遞全局事務 XID ，全局事務執行完成後，每個在 DB 中的執行過程都會被清理掉，這在回溯執行過程的時候非常不友好，這些海量資料 Seata 可不會存儲，這嚴重增加分布式事務關聯資料庫表的空間，帶來不必要的性能消耗。是以兩個生态融合後，SkyWalking 相關的資料庫監控，就可以記錄這些執行過程的海量資料。
- 定位問題的提效
在日志中列印 XID 的同時列印 TraceId ，當出現問題想回溯 XID 相關聯的全局鍊路時，在 SkyWalking 的展示端輸入 TraceId 即可，通過 Seata 整體監控融入 SkyWalking ，不僅擁有全鍊路領域的監控，還在儀表盤、拓撲圖、線上剖析和報警都得到了監控。
- 入門 Seata 提高一個次元
分布式事務一直被炒得很熱，但真正能在市場上落地的也隻有 Seata ，是以 Seata 并沒有開源的學習範本，是以快速帶領大家入門的資料也比較少。而且 Seata 有3個角色、4種經典模式，可以多種組合，綜上所訴，不由得讓使用者雲裡霧裡，兩個生态融合後，使用者可以清晰從上帝(監控)知道 Seata 的執行過程，進而透析工作原理。
二、典型 AT 模式監控場景
下面就官方 AT 模式的 Demo ，展示下接入後的 APM 特性。
官方描述的 ToC 交易場景
- 使用者請求交易服務
- 交易服務鎖定庫存
- 交易服務建立賬單
- 賬單服務進行扣款
當 Seata 與 SkyWalking 融合後，場景複原
全局事務正常鍊路描述
全局事務異常鍊路描述
使用者手冊
官網
SkyWalking APM:
http://seata.io/zh-cn/docs/user/apm/skywalking.html常用連結
Seata:
https://github.com/seata/seataSamples:
https://github.com/seata/seata-samplesRelease:
https://github.com/seata/seata/releases官網:
https://seata.io投稿
歡迎大家将 Seata 相關的實踐文章投稿至：[email protected]_