前面幾篇文章提到了微服務(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ù)，不想再回去改代碼)

分析粒度盡量細(xì)

支持較為豐富

所以今天主要來看一下SkyWalking。

SkyWalking當(dāng)前的最新版本已經(jīng)到了8，我已經(jīng)在生產(chǎn)環(huán)境搭建好了。可以先看一下效果。

服務(wù)拓?fù)?/p>

請求追蹤

可以看到當(dāng)前的服務(wù)調(diào)用鏈。用戶發(fā)起請求后就會基于調(diào)用的相關(guān)服務(wù)生成調(diào)用鏈拓?fù)鋱D。而每個請求也能看到詳細(xì)的調(diào)用信息。同時調(diào)用拓?fù)渲幸渤朔?wù)之外也包含對于數(shù)據(jù)庫，外部請求，消息隊列等進行拓?fù)洹?/p>

「SkyWalking的核心是數(shù)據(jù)分析與度量的平臺，通過Http或者gRPC的方式向信息搜集器(SkyWalking Collecter)上報收集到的客戶端采集的信息。

信息搜集器(SkyWalking Collecter)對搜集到的結(jié)果進行分析與聚合。它的數(shù)據(jù)主要使用ElasticSearch，MySql，H2，TiDB等進行存儲。當(dāng)然任選其一即可。我們通過UI進行查看分析的數(shù)據(jù)結(jié)果。采集器則負(fù)責(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)化。

總結(jié)

以上是生活随笔為你收集整理的PHP分布式链路追踪,SkyWalking:分布式架构链路追踪-SkyWalking介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。