前言
微服務框架落地后，分布式部署架構帶來的問題就會迅速凸顯出來。尤其線上出現問題，不知道如何排查，問題出現在哪個服務？如何快速定位問題？如何跟蹤業務調用鏈路？如何分析解決業務瓶頸？今天老顧來跟小伙伴們看看如何解決以上問題。
什么是鏈路追蹤
微服務架構是通過業務來劃分服務的，使用REST調用。對外暴露的一個接口，可能需要很多個服務協同才能完成這個接口功能，如果鏈路上任何一個服務出現問題或者網絡超時，都會形成導致接口調用失敗。隨著業務的不斷擴張，服務之間互相調用會越來越復雜。
上圖中，user調用A，A會調用C，C再調用E；這條調用鏈路，我們還能夠看清楚；但是一旦微服務很多，調用依賴復雜就看不清楚了，如下圖
上圖是不是看到后，有密集恐懼癥，像個線團，一團亂麻；如果這個時候出現了調用異常，那我們依據調用接口入口，一步步、一個服務一個服務的去跟蹤調試；這個流程會把人搞瘋的，也許1個小時后，也不知道什么問題；就像我們以前找線頭，然后一步步的去重新卷圈。
面對以上情況，我們就需要一些可以幫助理解系統行為、用于分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題，這就是所謂的 APM（應用性能管理）。
什么是 SkyWalking
Skywalking是一款國內開源的應用性能監控工具，支持對分布式系統的監控、跟蹤和診斷。目前主要的一些 APM 工具有: Cat、Zipkin、Pinpoint、SkyWalking。SkyWalking也是Apache的孵化項目之一，擁有頂級二級域名。
它提供了如下的主要功能特性：
功能特性：
- 多種監控手段，語言探針和服務網格(Service Mesh)
- 多語言自動探針，JAVA，.NET Core 和 Node.JS
- 輕量高效，不需要大數據
- 模塊化，UI、存儲、集群管理多種機制可選
- 支持告警
- 優秀的可視化方案
技術架構
上圖看了是不是比較亂，其實Skywalking總體可以分為四部分：
1、Skywalking Agent：使用Javaagent做字節碼植入，無侵入式的收集，并通過HTTP或者gRPC方式發送數據到Skywalking Collector。
2、Skywalking Collector ：鏈路數據收集器，對agent傳過來的數據進行整合分析處理并落入相關的數據存儲中。
3、Storage：Skywalking的存儲，在6.x版本中支持以ElasticSearch（推薦）、MySQL、TiDB、H2、作為存儲介質進行數據存儲。
4、UI ：Web可視化平臺，用來展示落地的數據。
下載并啟動 SkyWalking
官方已經為我們準備好了編譯過的服務端版本，現在最新版本為6.4.0
下載地址為 http://skywalking.apache.org/downloads/
配置 SkyWalking
下載完成后解壓縮
# tar -xvf apache-skywalking-apm-6.4.0.tar # mv apache-skywalking-apm-bin /usr/local/skywalking # cd /usr/local/skywalking
修改配置
# cd config
# vim Application.yml@
配置存儲方式，默認H2，官方推薦elasticsearch
這里需要做三件事：
- 注釋 H2 存儲方案
- 啟用 ElasticSearch 存儲方案
- 修改 ElasticSearch 服務器地址
clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}
啟動 SkyWalking
修改完配置后，進入 skywalkingbin 目錄，運行startup.bat啟動服務端
通過瀏覽器訪問 http://localhost:8080 出現如下界面即表示啟動成功
默認的用戶名密碼為：admin/admin，登錄成功后，效果如下圖
Java Agent 服務器探針
agent簡單的理解就是放一個插件，隨著應用程序啟動，監控數據、收集數據、發送數據的作用。
探針文件在skywalking/agent目錄下
啟動方式
在以前啟動應用程序時，加上一些參數
java -javaagent:/path/to/skywalking-agent/skywalking-agent.jar -Dskywalking.agent.service_name=shop-goods-provider -Dskywalking.collector.backend_service=localhost:11800 -jar yourApp.jar
參數含義：
- -javaagent：用于指定探針路徑
- -Dskywalking.agent.service_name：用于重寫 agent/config/agent.config 配置文件中的服務名
- -Dskywalking.collector.backend_service：用于重寫 agent/config/agent.config 配置文件中的服務地址
啟動后，訪問鏈接，就會發現 Service 與 Endpoint 已經成功檢測到了
表示 SkyWalking 鏈路追蹤配置成功。
Service Topology監控
調用鏈路監控可以從兩個角度去看待。我們先從整體上來認識一下我們所監控的系統。
通過給服務添加探針并產生實際的調用之后，我們可以通過Skywalking的前端UI查看服務之間的調用關系。
從圖中可以看到:
有兩個服務節點：provider & consumer
有一個數據庫節點：localhost【mysql】
consumer消費了provider提供出來的接口。
一個系統的拓撲圖讓我們清晰的認識到系統之間的應用的依賴關系以及當前狀態下的業務流轉流程。
細心的小伙伴們可能發現圖示節點consumer上有一部分是紅色的，紅色是什么意思呢？
紅色代表當前流經consumer節點的請求有一斷時間內是響應異常的。當節點全部變紅的時候證明服務現階段內就徹底不可用了。運維人員可以通過Topology迅速發現某一個服務潛在的問題，并進行下一步的排查并做到預防。
Skywalking Trace監控
Skywalking通過業務調用監控進行依賴分析，提供給我們了服務之間的服務調用拓撲關系、以及針對每個endpoint的trace記錄。
我們在之前看到consumer節點服務中發生了錯誤，讓我們一起來定位下錯誤是發生在了什么地方又是什么原因呢？
在每一條trace的信息中都可以看到當前請求的時間、GloableId、以及請求被調用的時間。我們分別看一看正確的調用和異常的調用。
Trace調用鏈路監控
上圖展示的是一次正常的響應，這條響應總耗時19ms；可以詳細點擊每個span查看詳細信息
Service JVM信息監控
Skywalking還可以監控到Service運行時的CPU、堆內存、非堆內存使用率、以及GC情況。這些信息來源于JVM。
Skywalking 服務告警
上面我們提到了通過查看拓撲圖以及調用鏈路可以定位問題，可是運維人員又不可能一直盯著這些數據，那么我們就需要告警能力，在異常達到一定閾值的時候主動的提示我們去查看系統狀態。
在Sywalking 6.x版本中新增了對服務狀態的告警能力。它通過webhook的方式讓我們可以自定義我們告警信息的通知方式。諸如:郵件通知、微信通知、短信通知等。
告警的規則配置。在alarm-settings.xml中可以配置告警規則，告警規則支持自定義。
1、service_resp_time_rule：告警規則名稱 ***_rule （規則名稱可以自定義但是必須以’_rule’結尾
2、indicator-name：指標數據名稱： 定義參見http://t.cn/EGhfbmd
3、op: 操作符： > , < , = 【當然你可以自己擴展開發其他的操作符】
4、threshold：目標值：指標數據的目標數據 如sample中的1000就是服務響應時間，配合上操作符就是大于1000ms的服務響應
5、period: 告警檢查周期：多久檢查一次當前的指標數據是否符合告警規則
6、counts: 達到告警閾值的次數
7、silence-period：忽略相同告警信息的周期
8、message：告警信息
文件結尾有最后一個webhooks屬性：服務告警通知服務地址
webhooks: # - http://127.0.0.1/notify/ # - http://127.0.0.1/go-wechat/
總結
本文簡單了介紹了Skywalking簡單的知識，可以通過Skywalking，可以讓我們方便的查看微服務架構中系統瓶頸以及性能問題等。小伙伴們可以去嘗試操作一下哦，謝謝！??！
---End---
最近老顧上傳了微服務網關的分享課程，請大家多多支持
