前面幾篇文章提到了微服務(wù)相關(guān)系統(tǒng)的使用與搭建，在微服務(wù)架構(gòu)下的問題也比較突出婴程。正常系統(tǒng)下我們的每個請求都會在同一個系統(tǒng)中進行輸出创译。但是在微服務(wù)架構(gòu)中一個請求可能設(shè)置一到多個服務(wù)進行處理。服務(wù)之間相互依賴蜜暑，服務(wù)之間形成一個調(diào)用鏈喂链。如果調(diào)用鏈之間的某個服務(wù)出現(xiàn)故障那么整個調(diào)用鏈都將會受到影響返十。
為什么需要鏈路追蹤
架構(gòu)設(shè)計之初就提出了需要進行分布式鏈路追蹤系統(tǒng)，而且當(dāng)時也對需求進行了大概的一個推演椭微。我們希望能夠得到的是一個下圖這樣的結(jié)構(gòu)洞坑。每次請求能夠獲取到該請求的調(diào)用鏈。
請求鏈路
當(dāng)然上圖是一個正常的情況下的請求蝇率，異常情況下我們應(yīng)該獲得的是一個能夠直接看到異常服務(wù)的狀態(tài)(「服務(wù)D異吵僭樱」)。
異常請求鏈路
SkyWalking
面對這些情況本慕，我們需要一個能夠支撐起該需求的APM工具排拷。目前主要的一些APM工具有,Cat,Zipkin,Pinpoint,SkyWalking。Zipkin是Twitter開源的锅尘，Pinpoint是韓國人開源的监氢。Cat與SkyWalking均為國人開發(fā)的。所以在選擇的時候主要關(guān)注的就是國人開發(fā)的.(英文不咋滴藤违，怕看不懂文檔..)其實也大概的翻閱了一下相關(guān)的博客浪腐，得到了一相關(guān)選型的分析與各個工具之間的區(qū)別。做了一些排除項顿乒，最終選擇為SkyWalking科雳。
- 不要代碼侵入(已經(jīng)上線了幾個服務(wù)何什，不想再回去改代碼)
- 分析粒度盡量細
- 支持較為豐富
所以今天主要來看一下SkyWalking倡鲸。SkyWalking當(dāng)前的最新版本已經(jīng)到了8亿驾，我已經(jīng)在生產(chǎn)環(huán)境搭建好了∮塘猓可以先看一下效果拾稳。
- 服務(wù)拓撲
拓撲圖
- 請求追蹤
請求追蹤
可以看到當(dāng)前的服務(wù)調(diào)用鏈。用戶發(fā)起請求后就會基于調(diào)用的相關(guān)服務(wù)生成調(diào)用鏈拓撲圖腊脱。而每個請求也能看到詳細的調(diào)用信息访得。同時調(diào)用拓撲中也除了服務(wù)之外也包含對于數(shù)據(jù)庫，外部請求，消息隊列等進行拓撲悍抑。
「SkyWalking的核心是數(shù)據(jù)分析與度量的平臺鳄炉，通過Http或者gRPC的方式向信息搜集器(SkyWalking Collecter)上報收集到的客戶端采集的信息。
信息搜集器(SkyWalking Collecter)對搜集到的結(jié)果進行分析與聚合搜骡。它的數(shù)據(jù)主要使用ElasticSearch拂盯，MySql，H2记靡，TiDB等進行存儲谈竿。當(dāng)然任選其一即可。我們通過UI進行查看分析的數(shù)據(jù)結(jié)果摸吠。采集器則負責(zé)搜集數(shù)據(jù)空凸，支持較多的語言 Java，PHP寸痢，.Net Core,NodeJS,Golang等」
總結(jié)
SkyWalking滿足我們的當(dāng)前需求呀洲，最直觀的可以通過SkyWalking看到服務(wù)調(diào)用鏈?zhǔn)欠窈侠怼Ｊ遣皇且粋€DAG啼止。同時能夠分析每個請求的追蹤是否有異常道逗。而且支持MQ，MySQL献烦，Http請求等各種方式能夠獲取到發(fā)生異常的點與RT較高的點進行優(yōu)化滓窍。
