> 簡便快速的完成對分散式系統的監控；

# 一、業務背景

微服務作為當前系統架構的主流選型，雖然可以應對複雜的業務場景，但是隨著業務擴充套件，微服務架構本身的複雜度也會膨脹，對於一些核心的業務流程，其請求鏈路會涉及到多個業務服務，少則三五個，多則十幾個都很常見：

![](https://foruda.gitee.com/images/1665412893855014314/fc8d260c_5064118.png "1.png")

真實的業務場景遠比圖解複雜，在這種模式下當請求發生故障時，或者進行最佳化時，需要分析鏈路效能，追蹤呼叫鏈路，排查和解決鏈路故障；

要完成上述流程，需要對請求的鏈路有完整監控，並且採集和分析各個環節的資料，這樣才能清晰的理解系統的行為資訊，比如耗時分析，故障原因發現，從而進行最佳化和解決；能實現這種能力的元件很多，這裡來看看基於SkyWalking9的實踐方式；

# 二、元件原理

Skywalking是APM規範的國產開源分散式鏈路追蹤系統，APM（Application-Performance-Management）即應用效能管理，支援對SpringCloud微服務整合，並且無程式碼層面的侵入：

**結構體系**

![](https://foruda.gitee.com/images/1665412907750089916/724f3e0e_5064118.png "2.png")

**業務機制**

![](https://foruda.gitee.com/images/1665412917198969842/beaaf2e7_5064118.png "3.png")

**SpringCloud**：分散式系統中的服務，啟動時配置代理即可；

**Agent**：以探針的方式進行請求鏈路的資料採集，並向管理服務上報；

**OAP-Service**：接收資料，完成資料的儲存和展示；

**Storage**：資料的儲存層，支援ElasticSearch、Mysql、H2多種方式；

**UI介面**：資料的視覺化展示介面；

![](https://foruda.gitee.com/images/1665412930330893581/eb3c5a02_5064118.png "4.png")

工作流程，服務透過探針的方式接入資料採集的功能，之後請求鏈路的相關處理行為會上報到OAP服務中，進行資料的聚合管理和分析，並儲存在持久層，然後可以透過UI介面進行視覺化呈現；

# 三、安裝部署

**1、版本描述**

skywalking在之前的舊版本中，apm與agent是在一個包中的，在9.0的版本中是需要分開下載的；agent包下載解壓之後，也將其放到apm包下面維護：

- skywalking-apm-9.1.0.tar.gz
- skywalking-java-agent-8.10.0.tgz

![](https://foruda.gitee.com/images/1665412941438637931/d0f73374_5064118.png "5.png")

**2、配置儲存方式**

Skywalking資料儲存的元件有多種選型方式，這裡方便本地除錯，就選擇MySQL資料庫，在生產環境中通常選擇ElasticSearch元件；

配置檔案：`config/application.yml`

```
storage:
  selector: ${SW_STORAGE:mysql}
mysql:
  properties:
    jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://localhost:3306/swtest?rewriteBatchedStatements=true"}
    dataSource.user: ${SW_DATA_SOURCE_USER:username}
    dataSource.password: ${SW_DATA_SOURCE_PASSWORD:password}
```

需要注意的是，要在本地的MySQL中新建swtest資料庫，**採用latin1字元編碼**，可以避免索引長度的問題，表的建立是自動的，然後需要在包中新增MySQL依賴；

![](https://foruda.gitee.com/images/1665412952139587696/5f24ad37_5064118.png "6.png")

**3、啟動與停止**

- 啟動oap服務：sh bin/oapService.sh
- 啟動UI介面：sh bin/webappService.sh
- 服務停止命令：jps檢視，kill相關編號；

UI介面服務預設是8080埠，如果存在佔用問題，可以修改：`webapp/webapp.yml`檔案，更換埠；啟動完成後訪問`LocalIP:port`即可；

**4、服務整合**

在本地存在`gateway`，`facade`，`account`，三個服務，案例圍繞`account`服務中的請求展開，由於涉及閘道器服務，還需要新增相關外掛的依賴；

![](https://foruda.gitee.com/images/1665412961822926385/dc1e009a_5064118.png "7.png")

將`optional-plugins`可選外掛目錄中的兩個閘道器的依賴包，複製到`plugins`外掛目錄下；

在服務啟動類中新增`agent`配置，如果在生產環境中，通常會統一在指令碼中設定，由於在本地環境演示，基於IDEA工具進行管理；

![](https://foruda.gitee.com/images/1665412971900871465/8c07b64d_5064118.png "8.png")

```
-javaagent:本地路徑/agent/skywalking-agent.jar -Dskywalking.agent.service_name=gateway
-javaagent:本地路徑/agent/skywalking-agent.jar -Dskywalking.agent.service_name=facade
-javaagent:本地路徑/agent/skywalking-agent.jar -Dskywalking.agent.service_name=account
```

這樣全部的配置就完成了，依次啟動skywalking相關服務，與這裡配置的三個微服務，下面再來看看功能細節；

# 四、功能細節

**1、服務監控**

相關服務啟動完成後，訪問skywalking介面，主頁載入的即上述配置的三個微服務，這樣說明整個流程是正常的，點選服務名稱可以檢視服務相關的細節指標；

![](https://foruda.gitee.com/images/1665412983100028812/f2c3888b_5064118.png "9.png")

**2、拓補結構圖**

請求透過`gateway`閘道器服務，經過`facade`門面服務，到達`account`業務服務，完成一次呼叫後，檢視請求的拓補結構圖（即Topology一欄）；

![](https://foruda.gitee.com/images/1665412994416045726/87c81693_5064118.png "10.png")

可以清晰的看到請求的路由鏈路，以及相關服務訪問的資料庫地址，對於微服務架構中的複雜介面來說，藉助該拓補模型，既可以快速理解業務邏輯，同時在出具文件時可以節省很多畫圖時間；

**3、鏈路跟蹤**

上面只是請求的拓補結構圖，在實際應用中還是更側重鏈路跟蹤，檢視`account`服務請求鏈路（即Trace一欄）；

![](https://foruda.gitee.com/images/1665413004672850900/3f57caca_5064118.png "11.png")

skywalking元件對於開發來說，最常用的就是該功能，這裡採集了請求鏈路上的各個節點，以及執行的耗時分析，點選相關節點可以檢視詳細資訊，針對異常請求同樣可以採集到異常資訊的描述；

![](https://foruda.gitee.com/images/1665413016774276030/9d1b06b7_5064118.png "12.png")

這樣可以極大的提升問題排查的效率，尤其對於那種路由十多個服務的業務邏輯；

**4、資料庫監控**

雖然在整個配置中沒有顯式的新增對MySQL的監控，但是skywalking依舊可以實現對服務中的資料庫監控，對於這些指標細節不過多描述，可以自行查閱文件；

![](https://foruda.gitee.com/images/1665413028334457307/ef5af80c_5064118.png "13.png")

本篇文章只是站在開發的角度，總結skywalking的應用方式，並未涉及過多的細節原理，其它強大的功能設計，對於開發來說同樣值得參考。

# 五、原始碼參考

```
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent

元件封裝：
https://gitee.com/cicadasmile/butte-frame-parent
```

監控平臺SkyWalking9入門實踐

相關文章