SkyWalking分布式追蹤系統

随着微服務架構的流行，一些微服務架構下的問題也會越來越突出，比如一個請求會涉及多個服務，而服務本身可能也會依賴其他服務，整個請求路徑就構成了一個網狀的調用鍊，而在整個調用鍊中一旦某個節點發生異常，整個調用鍊的穩定性就會受到影響，是以會深深的感受到 “銀彈” 這個詞是不存在的，每種架構都有其優缺點 。

service map

面對以上情況， 我們就需要一些可以幫助了解系統行為、用于分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題，這時候 APM（應用性能管理）工具就該閃亮登場了。

目前主要的一些 APM 工具有: Cat、Zipkin、Pinpoint、SkyWalking，這裡主要介紹 SkyWalking ，它是一款優秀的國産 APM 工具，包括了分布式追蹤、性能名額分析、應用和服務依賴分析等。

下面是 SkyWalking 6.x 的架構圖：

6.x architecture

說明： SkyWalking 的核心是資料分析和度量結果的存儲平台，通過 HTTP 或 gRPC 方式向 SkyWalking Collecter 送出分析和度量資料，SkyWalking Collecter 對資料進行分析和聚合，存儲到 Elasticsearch、H2、MySQL、TiDB 等其一即可，最後我們可以通過 SkyWalking UI 的可視化界面對最終的結果進行檢視。Skywalking 支援從多個來源和多種格式收集資料：多種語言的 Skywalking Agent 、Zipkin v1/v2 、Istio 勘測、Envoy 度量等資料格式。

整體架構看似子產品有點多，但在實際上還是比較清晰的，主要就是通過收集各種格式的資料進行存儲，然後展示。是以搭建 Skywalking 服務我們需要關注的是 SkyWalking Collecter、SkyWalking UI 和 儲存設備，SkyWalking Collecter、SkyWalking UI 官方下載下傳安裝包内已包含，最終我們隻需考慮儲存設備即可。

下面基于 Windows 環境使用 SkyAPM-dotnet 來介紹一下 SkyWalking， SkyAPM-dotnet 是 SkyWalking 的 .NET Agent。

環境要求

1. JDK8+
2. Elasticsearch 6.x
3. 8080,10800,11800,12800 端口不被占用

Elasticsearch下載下傳安裝 參考官方教程， 安裝完成後需要對 config/elasticsearch.yml 做如下修改：

# 修改
# 如果 cluster.name 不設定為 CollectorDBCluster ，則需要修改 SkyWalking 的配置檔案
cluster.name: CollectorDBCluster   
network.host: 0.0.0.0
# 增加
thread_pool.bulk.queue_size: 1000
           

如果是 linux 環境，Elasticsearch 安裝可能沒有那麼順利，請參考 Linux 環境下安裝 Elasticsearch 5.x、6.x 問題彙總。

下載下傳 SkyWalking

SkyWalking 個人建議直接下載下傳官方編譯好的，下載下傳位址

啟動 SkyWalking

skywalking config

config/application.yml 的預設資料存儲開啟是的 h2，這裡我們需要修改資料存儲為 Elasticsearch（在啟動 SkyWalking 之前，確定 Elasticsearch 已啟動）

SkyWalking 的啟動包括兩部分，一個是 SkyWalking Collector（oapService） ，一個是 SkyWalking UI（webappService），SkyWalking 解壓後的 bin 目錄：

skywalking bin

bat 為 windows 環境使用，sh 為 linux 環境使用，我們可以分别啟動 oapService 和 webappService，也可以通過 startup 一次性全部啟動，從 startup 中的指令可以知道其實就是分别啟動 oapService 和 webappService。

如果一切順利(不順利請多看幾遍 快速入門)，這時候就可以通過 http://localhost:8080 來檢視 SkyWalking UI 了（預設全是0，截圖是測試效果），預設賬号/密碼：admin/admin。

skywalking ui

Java 項目接入

參考 部署 skywalking javaagent，skywalking-agent.jar 位于下載下傳包的 agent 目錄下，具體效果這裡就不測試了

skywalking java agent

.NET 項目接入

這裡以 .NET Core 項目來測試，基于 .NET Framework 的項目目前也是支援的，隻是相對不完善一些，參考 SkyAPM-dotnet

1. 建立一個.NET Core API 項目，安裝 NuGet 包：

   Install-Package SkyAPM.Agent.AspNetCore
              

2. 添加項目環境變量（實際情況應該是在 CI 流程中設定環境變量，參考：https://github.com/SkyAPM/SkyAPM-dotnet#examples）

   set ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=SkyAPM.Agent.AspNetCore
              

   

   hostingStartupAssemblies
3. 項目根目錄下添加 skyapm.json 檔案（來自官方例子），設定為 “如果較新則複制”，添加 SkyWalking 的配置資訊，更多預設配置參考。（不過從源碼可以看出其實也不需要建立單獨的 skyapm.json，直接在 appsettings.json 增加 SkyWalking 節點配置也是沒問題的）

   {
     "SkyWalking": {
       "ServiceName": "WebAPIServiceA", // 服務名
       "Transport": {
         "gRPC": {
           "Servers": "localhost:11800"  // 服務位址
         }
       }
     }
   }
              

4. 啟動程式，請求的追蹤結果就會被記錄下來，通過 SkyWalking UI 檢視：

   

   skywalking request log

單個服務的效果并不明顯，看不出請求跨度、鍊路關系，下面是一個多服務的例子(下載下傳源碼)，依賴關系圖如下：

service request map

目前 SkyWalking 的 .NET Agent 還不支援 gRPC 的調用跟蹤，整個項目還在不斷的完善中，期待後續更多的進展。根據以上的關系圖搭建好項目後，通路接口後結果如下：

skywalking spans

一共有4各跨度，先通路 WenAPIServiceA，然後發送 HttpClient 請求，轉到 WenAPIServiceB，WenAPIServiceB 執行操作 DB 的指令，每個跨度的耗時一目了然。

服務關系的拓撲圖，調用鍊路徑也非常清晰：

skywalking topology map

參考連結

• Apache SkyWalking
• SkyWalking-github
• SkyWalking-dotnet
• SkyWalking-sample

作者：BeckJin

連結：https://www.jianshu.com/p/2fd56627a3cf

來源：簡書

著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。