案例實踐丨基於SkyWalking全鏈路監控的微服務系統效能調優實踐篇

 1背景

隨著開源社群和雲端計算的快速推進，雲原生微服務作為新型應用系統的核心架構，得到了越來越廣泛的應用。根據Gartner對微服務的定義：“微服務是範圍狹窄、封裝緊密、鬆散耦合、可獨立部署且可獨立伸縮的應用程式元件。”

微服務之父，馬丁.福勒，對微服務概述如下：就目前而言，對於微服務業界並沒有一個統一的、標準的定義。但通常而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程式劃分成一組小的服務，每個服務執行在自己獨立的程式中，服務之間互相協調、互相配合，為使用者提供最終價值。服務之間採用輕量級的通訊機制互相溝通（通常是基於HTTP的RESTful API)。

每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等，這種方法能夠提高應用系統的響應速度、靈活性和部署彈性，能夠按照業務發展與時俱進快速迭代和最佳化。目前行內越來越多的應用服務系統已升級改造為微服務架構，對現有應用監控體系提出了新的挑戰。

為推動微服務應用監控體系的建設和發展，探索微服務全鏈路監控技術在行內的實踐路徑，我們重點引入了SkyWalking開源可觀測平臺，透過非程式碼侵入的方式，採集微服務全鏈路監控資訊，以視覺化的方式展現微服務系統的拓撲關係、追蹤交易鏈路、精準識別效能瓶頸，彌補現有測試工具和方法對微服務全鏈路應用監控的缺失。

2 SkyWalking簡介

SkyWalking是開源的可觀測平臺的APM系統，專為微服務，雲原生架構和基於容器（Docker，k8s，Mesos等）的架構設計的應用程式效能監控工具，用於收集、分析、聚合和視覺化來自服務和雲原生基礎設施的資料。提供分散式追蹤、服務網格遙測分析、度量聚合和視覺化一體化解決方案。SkyWalking主要由以下四大部分構成：

Agent代理程式

探針收集資料並根據SkyWalking的要求對資料進行重新格式化(不同的探測器支援不同的來源)；Agent執行在各個服務例項中，負責採集服務例項的Trace、Metrics等資料，然後透過gRPC方式上報給SkyWalking後端，供OAP伺服器進行分析，本文將在第3章詳細介紹Agent代理程式。

OAP伺服器

SkyWalking的OAP（Observability Analysis Platform，觀測分析平臺）是一個用於分析鏈路取樣資料的分析計算系統。

在OAP服務主要需要計算以下三類資料：

（1）Record資料

記錄的鏈路資料，如Trace、訪問日誌等資料，由RecordStreamProcessor進行處理。

（2）Metrics資料

記錄的指標資料，絕大部分的OAL（Observability Analysis Language）指標都將生成這類資料，由MetricsStreamProcessor進行處理。

（3）TopN資料

記錄的週期性的取樣資料，如慢SQL的週期性採集，由TopNStreamProcessor進行處理。

Trace、訪問日誌等這類的明細資料，資料量比較大，但不需要歸併處理，所以在OAP節點內部即可處理完成，這些明細資料採用快取、非同步批次處理和流式寫入的方式將它們寫入到外部儲存器(Storage)中。

絕大部分由OAL（Observability Analysis Language）定義的指標資料是需要微服務聚合計算的，所以在OAP叢集計算流中將其分為了兩個步驟。

步驟一，接收和解析Agent代理程式傳送的資料，並執行當前OAP服務節點內的資料聚合，使用OAL或其他聚合模式。對於不需要聚合的資料，直接將其寫入到外部儲存器(Storage)中；如果是需要微服務聚合的資料，根據一定的路由規則傳送給指定的OAP服務節點。

步驟二，接收和解析經步驟一處理的資料，之後進行二次聚合計算，並將結果資料寫入到外部儲存器(Storage)中。

針對以上兩個步驟，OAP服務節點被分為Receiver（處理步驟一）和Aggregator（處理步驟二）兩種角色。

預設情況下，所有OAP服務節點均為Mixed混合角色，其既可以執行步驟一的操作，也可以執行步驟二的操作。在大規模系統部署SkyWalking的場景下，可根據網路流量進行角色分離的兩級部署。

OAP伺服器還服務響應SkyWalking UI介面傳送來的查詢請求，將前面持久化的資料查詢出來，組成正確的響應結果返回給UI介面進行展示。

Storage資料庫儲存

作為OAP服務的外部儲存裝置，負責資料的儲存，支援多種儲存型別，可以使用既有的儲存系統，如ElasticSearch，Mysql等，也可以自定義實現儲存系統。SkyWalking資料可以選擇儲存在已實現的ElasticSearch,Mysql,TiDB,InfluxDB，H2的持久化系統，其中H2是記憶體資料庫，儲存的資料在記憶體裡，不落到磁碟上，重啟SkyWalking服務會導致資料丟失，是預設的儲存方式，一般線上使用ElasticSearch叢集作為其後端儲存。

UI介面

負責視覺化和管理SkyWalking資料，前後端分離，該UI介面負責將使用者的查詢操作封裝為GraphQL請求提交給OAP後端觸發後續的查詢操作，待拿到查詢結果之後會在前端負責展示並可以檢視鏈路呼叫關係，檢視各種監控指標，效能指標等等。

由以上對構成SkyWalking的各分系統的介紹可知，Agent代理程式負責收集各種鏈路取樣資料，透過GRPC的?式傳遞給OAP進行分析並且儲存到資料庫中，最終透過UI介面將分析的統計報表、服務依賴、拓撲關係圖展示出來。

3 SkyWalking應用擴充套件及效能調優

自定義外掛開發示例，基於某系統開發自定義外掛，將其部署至SkyWalking部署包的plugins目錄內。

對某查詢介面執行呼叫操作，多個執行緒都可以在SkyWalking中檢視方法的取樣資訊，如圖1所示：

圖1某查詢方法的取樣資訊

點選圖1中的某查詢方法連結，可以檢視詳細的跨度資訊，如圖2所示。

圖2跨度資訊

由以上資訊可知，可以清晰看到我們新增的三個tag標籤分別為：invoke開始時間，invoke結束時間，系統間查詢方法執行時長（ms）。

系統重構，架構特點為多微服務、多鏈路系統。可應用引數配置檢查、可觀測性技術、資料移植、同步驗證4個課題的成果。

效能調優示例，為了儘可能減少SkyWaling Agent對業務效能測試的影響，真實監控出業務系統效能瓶頸，我們對SkywalkingAgent進行了一些效能調優，透過調整取樣頻率和取樣數量等相關引數，減少部署SkyWalking Agent後產生的額外的效能損耗。圖3是透過對同一只交易在未部署SkyWaling Agent情況下、已部署SkyWaling Agent標準化（未效能調優）情況下、已部署SkyWaling Agent已效能調優情況下，在相同併發下的效能測試結果對比，調優之後，我們發現效能表現相對於標準化部署場景下有提升，相較未部署agent情況，將效能損耗降到最小。

如果你想學習交流，看下方：

↓↓

可以到我的個人號：atstudy-js，就可以邀請你進群一起探討學習交流。