前面幾篇文章提到了微服務相關係統的使用與搭建，在微服務架構下的問題也比較突出。正常系統下我們的每個請求都會在同一個系統中進行輸出。但是在微服務架構中一個請求可能設置一到多個服務進行處理。服務之間相互依賴，服務之間形成一個調用鏈。如果調用鏈之間的某個服務出現故障那麼整個調用鏈都將會受到影響。
爲什麼需要鏈路追蹤
架構設計之初就提出了需要進行分佈式鏈路追蹤系統，而且當時也對需求進行了大概的一個推演。我們希望能夠得到的是一個下圖這樣的結構。每次請求能夠獲取到該請求的調用鏈。
當然上圖是一個正常的情況下的請求，異常情況下我們應該獲得的是一個能夠直接看到異常服務的狀態(「服務D異常」)。
SkyWalking
面對這些情況，我們需要一個能夠支撐起該需求的APM工具。目前主要的一些APM工具有,Cat,Zipkin,Pinpoint,SkyWalking。Zipkin是Twitter開源的，Pinpoint是韓國人開源的。Cat與SkyWalking均爲國人開發的。所以在選擇的時候主要關注的就是國人開發的.(英文不咋滴，怕看不懂文檔..)
其實也大概的翻閱了一下相關的博客，得到了一相關選型的分析與各個工具之間的區別。做了一些排除項，最終選擇爲SkyWalking。
-
不要代碼侵入(已經上線了幾個服務，不想再回去改代碼) -
分析粒度儘量細 -
支持較爲豐富
所以今天主要來看一下SkyWalking。
SkyWalking當前的最新版本已經到了8，我已經在生產環境搭建好了。可以先看一下效果。
-
服務拓撲
![]()
-
請求追蹤
![]()
可以看到當前的服務調用鏈。用戶發起請求後就會基於調用的相關服務生成調用鏈拓撲圖。而每個請求也能看到詳細的調用信息。同時調用拓撲中也除了服務之外也包含對於數據庫，外部請求，消息隊列等進行拓撲。
「SkyWalking的核心是數據分析與度量的平臺，通過Http或者gRPC的方式向信息蒐集器(SkyWalking Collecter)上報收集到的客戶端採集的信息。
信息蒐集器(SkyWalking Collecter)對蒐集到的結果進行分析與聚合。它的數據主要使用ElasticSearch，MySql，H2，TiDB等進行存儲。當然任選其一即可。我們通過UI進行查看分析的數據結果。採集器則負責蒐集數據，支持較多的語言 Java，PHP，.Net Core,NodeJS,Golang等」
總結
SkyWalking滿足我們的當前需求，最直觀的可以通過SkyWalking看到服務調用鏈是否合理。是不是一個DAG。同時能夠分析每個請求的追蹤是否有異常。而且支持MQ，MySQL，Http請求等各種方式能夠獲取到發生異常的點與RT較高的點進行優化。
本文分享自微信公衆號 - 指尖數蟲（zhijianshuchong）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。