案例實踐丨基于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情況，將性能損耗降到最小。

入群學習交流↓↓↓↓↓↓