分散式鏈路追蹤自從用了SkyWalking，睡得真香！

bucaichenmou發表於2022-01-06

分散式

本篇文章介紹鏈路追蹤的另外一種解決方案Skywalking，文章目錄如下：

什麼是Skywalking？

上一篇文章介紹了分散式鏈路追蹤的一種方式：Spring Cloud Sleuth+ZipKin，這種方案目前也是有很多企業在用，但是作為程式設計師要的追逐一些新奇的技術，Skywalking作為後起之秀也是值得大家去學習的。

skywalking是一個優秀的國產開源框架，2015年由個人吳晟（華為開發者）開源， 2017年加入Apache孵化器。短短兩年就被Apache收入麾下，實力可見一斑。

skywalking支援dubbo，SpringCloud，SpringBoot整合，程式碼無侵入，通訊方式採用GRPC，效能較好，實現方式是java探針，支援告警，支援JVM監控，支援全域性呼叫統計等等，功能較完善。

Skywalking和Spring Cloud Sleuth+ZipKin如何選型？

Skywalking相比於zipkin還是有很大的優勢的，如下：

skywalking採用位元組碼增強的技術實現程式碼無侵入，zipKin程式碼侵入性比較高
skywalking功能比較豐富，報表統計，UI介面更加人性化

個人建議：如果是新的架構，建議優先選擇skywalking。

Skywalking架構是怎樣的？

skywalking和zipkin一樣，也分為服務端和客戶端，服務端負責收集日誌資料並且展示，架構如下：

上述架構圖中主要分為四個部分，如下：

上面的Agent：負責收集日誌資料，並且傳遞給中間的OAP伺服器
中間的OAP：負責接收 Agent 傳送的 Tracing 和Metric的資料資訊，然後進行分析(Analysis Core) ，儲存到外部儲存器( Storage )，最終提供查詢( Query )功能。
左面的UI：負責提供web控制檯，檢視鏈路，檢視各種指標，效能等等。
右面Storage：負責資料的儲存，支援多種儲存型別。

看了架構圖之後，思路很清晰了，Agent負責收集日誌傳輸資料，通過GRPC的方式傳遞給OAP進行分析並且儲存到資料庫中，最終通過UI介面將分析的統計報表、服務依賴、拓撲關係圖展示出來。

服務端如何搭建？

skywalking同樣是通過jar包方式啟動，需要下載jar包，地址：https://skywalking.apache.org/downloads/

1、下載安裝包

選擇V8.7.0這個版本，如下圖：

以上只是陳某的選擇，可以按照自己的需要選擇其他版本

解壓之後完整目錄如下圖：

重要的目錄結構分析如下：

agent：客戶端需要指定的目錄，其中有一個jar，就是負責和客戶端整合收集日誌
bin：服務端啟動的指令碼
config：一些配置檔案的目錄
logs：oap服務的日誌目錄
oap-libs：oap所需的依賴目錄
webapp：UI服務的目錄

2、配置修改

啟動之前需要對配置檔案做一些修改，修改如下：

1、/config/application.yml

這個是oap服務的配置檔案，需要修改註冊中心為nacos，如下圖：

配置①：修改預設註冊中心選擇nacos，這樣就不用在啟動引數中指定了。

配置②：修改nacos的相關配置，由於陳某是本地的，則不用改動，根據自己情況修改。

2、webapp/webapp.yml

這個是UI服務的配置檔案，其中有一個server.port配置，是UI服務的埠，預設8080，陳某將其改成8888，避免埠衝突，如下圖：

3、啟動服務

啟動命令在/bin目錄下，這裡需要啟動兩個服務，如下：

oap服務：對應的啟動指令碼oapService.bat，Linux下對應的字尾是sh
UI服務：對應的啟動指令碼webappService.bat，Linux下對應的字尾是sh

當然還有一個startup.bat啟動檔案，可以直接啟動上述兩個服務，我們可以直接使用這個指令碼，直接雙擊，將會彈出兩個視窗則表示啟動成功，如下圖：

此時直接訪問：http://localhost:8888/，直接進入UI端，如下圖：

客戶端如何搭建？

客戶端也就是單個微服務，由於Skywalking採用位元組碼增強技術，因此對於微服務無程式碼侵入，只要是普通的微服務即可，不需要引入什麼依賴。

還是上一篇Spring Cloud Sleuth的三個服務，如下：

skywalking-product1001：商品微服務
skywalking-order1002：訂單微服務
skywalking-gateway1003：閘道器微服務

原始碼：GZH：碼猿技術專欄，回覆關鍵詞 9528獲取！

案例原始碼結構目錄如下圖：

想要傳輸資料必須藉助skywalking提供的agent，只需要在啟動引數指定即可，命令如下：

-javaagent:E:\springcloud\apache-skywalking-apm-es7-8.7.0\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar
-Dskywalking.agent.service_name=skywalking-product-service
-Dskywalking.collector.backend_service=127.0.0.1:11800

上述命令解析如下：

-javaagent：指定skywalking中的agent中的skywalking-agent.jar的路徑
-Dskywalking.agent.service_name：指定在skywalking中的服務名稱，一般是微服務的spring.application.name
-Dskywalking.collector.backend_service：指定oap服務繫結的地址，由於陳某這裡是本地，並且oap服務預設的埠是11800，因此只需要配置為127.0.0.1:11800

上述引數可以在命令列通過java -jar xxx指定，在IDEA中操作如下圖：

上述三個微服務都需要配置skywalking的啟動配置，配置成功後正常啟動即可。

注意：agent的jar包路徑不能包含中文，不能有空格，否則執行不成功。

成功啟動後，直接通過閘道器訪問：http://localhost:1003/order/get/12，返回如下資訊：

此時檢視skywalking的UI端，可以看到三個服務已經監控成功了，如下圖：

服務之前的依賴關係也是可以很清楚的看到，如下圖：

請求鏈路的資訊也是能夠很清楚的看到，比如請求的url，執行時間、呼叫的服務，如下圖：

感覺怎樣？是不是很高階，比zipkin的功能更加豐富。

資料如何持久化？

你會發現只要服務端重啟之後，這些鏈路追蹤資料將會丟失了，因為skywalking預設持久化的方式是儲存在記憶體中。

當然這裡也是可以通過插拔方式的替換掉儲存中介軟體，企業中往往是使用ES儲存，陳某這章介紹一下MySQL的方式儲存，ES方式後面單獨開一篇文章介紹。

1、修改配置檔案

修改config/application.yml檔案中的儲存方式，總共需要修改兩處地方。

修改預設的儲存方式為mysql，如下圖：

修改Mysql相關的資訊，比如使用者名稱、密碼等，如下圖：

2、新增MySQL的jdbc依賴

預設的oap中是沒有jdbc驅動依賴，因此需要我們手動新增一下，只需要將驅動的jar放在oap-libs資料夾中，如下圖：

好了，已經配置完成，啟動服務端，在skywalking這個資料庫中將會自動建立表，如下圖：

陳某這裡就不再測試了，自己耍耍吧.......

日誌監控如何做？

在skywalking的UI端有一個日誌的模組，用於收集客戶端的日誌，預設是沒有資料的，那麼需要如何將日誌資料傳輸到skywalking中呢？

日誌框架的種類很多，比較出名的有log4j，logback，log4j2，陳某就以logback為例子介紹一下如何配置，官方文件如下：

1、新增依賴

根據官方文件，需要先新增依賴，如下：

<dependency>
   <groupId>org.apache.skywalking</groupId>
   <artifactId>apm-toolkit-logback-1.x</artifactId>
   <version>${project.release.version}</version>
</dependency>

2、新增配置檔案

新建一個logback-spring.xml放在resource目錄下，配置如下圖：

以上配置全部都是拷貝官方文件的，對於日誌配置有不理解的地方，可以看陳某之前的文章：Spring Boot第三彈，一文帶你搞懂日誌如何配置？

配置完成之後，啟動服務，訪問：http://localhost:1003/order/get/12。

控制檯列印的日誌如下圖：

可以看到已經列印出了traceId。

skywalking中的日誌模組輸出的日誌如下圖：

日誌已經傳輸到了skywalking中..............

注意：如果agent和oap服務不在同一臺伺服器上，需要在/agent/config/agent.config配置檔案末尾新增如下配置：

plugin.toolkit.log.grpc.reporter.server_host=${SW_GRPC_LOG_SERVER_HOST:10.10.10.1}
plugin.toolkit.log.grpc.reporter.server_port=${SW_GRPC_LOG_SERVER_PORT:11800}
plugin.toolkit.log.grpc.reporter.max_message_size=${SW_GRPC_LOG_MAX_MESSAGE_SIZE:10485760}
plugin.toolkit.log.grpc.reporter.upstream_timeout=${SW_GRPC_LOG_GRPC_UPSTREAM_TIMEOUT:30}

配置分析如下圖：