前面幾篇文章提到了微服務相關系統(tǒng)的使用與搭建，在微服務架構下的問題也比較突出。正常系統(tǒng)下我們的每個請求都會在同一個系統(tǒng)中進行輸出。但是在微服務架構中一個請求可能設置一到多個服務進行處理。服務之間相互依賴，服務之間形成一個調用鏈。如果調用鏈之間的某個服務出現(xiàn)故障那么整個調用鏈都將會受到影響。
為什么需要鏈路追蹤
架構設計之初就提出了需要進行分布式鏈路追蹤系統(tǒng)，而且當時也對需求進行了大概的一個推演。我們希望能夠得到的是一個下圖這樣的結構。每次請求能夠獲取到該請求的調用鏈。
請求鏈路
當然上圖是一個正常的情況下的請求，異常情況下我們應該獲得的是一個能夠直接看到異常服務的狀態(tài)(「服務D異?！?/strong>)。
異常請求鏈路
SkyWalking
面對這些情況，我們需要一個能夠支撐起該需求的APM工具。目前主要的一些APM工具有,Cat,Zipkin,Pinpoint,SkyWalking。Zipkin是Twitter開源的，Pinpoint是韓國人開源的。Cat與SkyWalking均為國人開發(fā)的。所以在選擇的時候主要關注的就是國人開發(fā)的.(英文不咋滴，怕看不懂文檔..)其實也大概的翻閱了一下相關的博客，得到了一相關選型的分析與各個工具之間的區(qū)別。做了一些排除項，最終選擇為SkyWalking。
- 不要代碼侵入(已經上線了幾個服務，不想再回去改代碼)
- 分析粒度盡量細
- 支持較為豐富
所以今天主要來看一下SkyWalking。SkyWalking當前的最新版本已經到了8，我已經在生產環(huán)境搭建好了?？梢韵瓤匆幌滦Ч?。
- 服務拓撲
拓撲圖
- 請求追蹤
請求追蹤
可以看到當前的服務調用鏈。用戶發(fā)起請求后就會基于調用的相關服務生成調用鏈拓撲圖。而每個請求也能看到詳細的調用信息。同時調用拓撲中也除了服務之外也包含對于數(shù)據(jù)庫，外部請求，消息隊列等進行拓撲。
「SkyWalking的核心是數(shù)據(jù)分析與度量的平臺，通過Http或者gRPC的方式向信息搜集器(SkyWalking Collecter)上報收集到的客戶端采集的信息。
信息搜集器(SkyWalking Collecter)對搜集到的結果進行分析與聚合。它的數(shù)據(jù)主要使用ElasticSearch，MySql，H2，TiDB等進行存儲。當然任選其一即可。我們通過UI進行查看分析的數(shù)據(jù)結果。采集器則負責搜集數(shù)據(jù)，支持較多的語言 Java，PHP，.Net Core,NodeJS,Golang等」
總結
SkyWalking滿足我們的當前需求，最直觀的可以通過SkyWalking看到服務調用鏈是否合理。是不是一個DAG。同時能夠分析每個請求的追蹤是否有異常。而且支持MQ，MySQL，Http請求等各種方式能夠獲取到發(fā)生異常的點與RT較高的點進行優(yōu)化。
