APM的定義與演進(jìn) 分布式追蹤技術(shù)原理分析

隨著虛擬化、云化技術(shù)越來越成熟，分布式系統(tǒng)的成本和架構(gòu)優(yōu)勢日漸凸顯，特別是微服務(wù)等設(shè)計(jì)理念在業(yè)務(wù)系統(tǒng)尤其是大型的互聯(lián)網(wǎng)公司中越來越流行，業(yè)務(wù)的調(diào)用關(guān)系越來越復(fù)雜。

而隨著業(yè)務(wù)的膨脹、服務(wù)的拆分，系統(tǒng)的模塊變得越來越多，不同的模塊可能由不同的團(tuán)隊(duì)/程序員來維護(hù)。一次客戶的業(yè)務(wù)請求，可能會涉及數(shù)個乃至數(shù)十個服務(wù)的協(xié)同處理，牽扯到多個團(tuán)隊(duì)/程序員的維護(hù)模塊，不同的緩存、數(shù)據(jù)庫、消息隊(duì)列等中間件。在這樣的云化應(yīng)用架構(gòu)下，請求鏈路的任何一條請求出現(xiàn)故障或性能問題，都將嚴(yán)重影響服務(wù)的用戶體驗(yàn)。如何能夠快速準(zhǔn)確的定位到線上故障根因？如何捕捉請求中的性能瓶頸并實(shí)施優(yōu)化？如何將離散的業(yè)務(wù)請求數(shù)據(jù)關(guān)聯(lián)在一起進(jìn)行有效的用戶體驗(yàn)分析？對于大型的、訪問量大的網(wǎng)站、社交、電商、游戲應(yīng)用，這類問題尤其突出，直接影響最終用戶對系統(tǒng)的感知和留存率。

傳統(tǒng)的應(yīng)用運(yùn)維問題定位以日志為主，通過對告警、系統(tǒng)資源、日志的逐一分析，定位故障根因或性能瓶頸。但是由于云化架構(gòu)的復(fù)雜性，業(yè)務(wù)請求鏈路的多樣性，傳統(tǒng)的應(yīng)用運(yùn)維模式已經(jīng)無法繼續(xù)支撐故障定位與性能分析的訴求。這個時候就需要APM系統(tǒng)來大展身手了。

APM (ApplicaTIon Performance Management) 即應(yīng)用性能管理，屬于IT運(yùn)維管理（ITOM)范疇。主要是針對企業(yè)關(guān)鍵業(yè)務(wù)的IT應(yīng)用性能和用戶體驗(yàn)的監(jiān)測、優(yōu)化，提高企業(yè)IT應(yīng)用的可靠性和質(zhì)量，保證用戶得到良好的服務(wù)，降低IT總擁有成本(TCO)。APM隨著互聯(lián)網(wǎng)的發(fā)展，經(jīng)歷了以下三個階段：

第一階段的APM出現(xiàn)在互聯(lián)網(wǎng)興起的初期，由于網(wǎng)絡(luò)基礎(chǔ)設(shè)施的水平普遍較差，使應(yīng)用速度對網(wǎng)絡(luò)速度與基礎(chǔ)資源的性能非常敏感。這個階段的APM以網(wǎng)絡(luò)為中心，認(rèn)為網(wǎng)絡(luò)速度既應(yīng)用速度，APM主要監(jiān)控主機(jī)的CPU、I/O、內(nèi)存、網(wǎng)絡(luò)吞吐等為主。

第二階段的APM以監(jiān)控各種基礎(chǔ)組件為主，隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)絡(luò)應(yīng)用變得越來越復(fù)雜，各種基礎(chǔ)組件越來越多，促使APM進(jìn)入以IT組件的健康狀態(tài)、可用性、性能監(jiān)控為中心第二個階段。

近幾年移動互聯(lián)網(wǎng)、云計(jì)算、大數(shù)據(jù)、物聯(lián)網(wǎng)等技術(shù)的迅猛發(fā)展，各種業(yè)務(wù)應(yīng)用不斷出現(xiàn)，IT應(yīng)用復(fù)雜度呈現(xiàn)爆炸式增長，而互聯(lián)網(wǎng)產(chǎn)品本身“用戶至上”的屬性決定用戶體驗(yàn)成為各互聯(lián)網(wǎng)產(chǎn)品生存發(fā)展的關(guān)鍵因素。如何提升用戶體驗(yàn)，保證服務(wù)和產(chǎn)品的可靠性、穩(wěn)定性、優(yōu)化服務(wù)等問題，對應(yīng)用性能管理提出了新的需求，應(yīng)用性能管理進(jìn)入以用戶體驗(yàn)為核心、專注業(yè)務(wù)交易與應(yīng)用架構(gòu)高度復(fù)雜性的第三階段。

基于APM 市場分析，Gardern對APM進(jìn)行了新的定義描述：

在新的標(biāo)準(zhǔn)下，APM市場發(fā)展迅速。APM通過對應(yīng)用服務(wù)的性能和可用性進(jìn)行監(jiān)控管理，幫助應(yīng)用/服務(wù)開發(fā)者發(fā)現(xiàn)和定位性能瓶頸和故障，保證應(yīng)用達(dá)到預(yù)期的服務(wù)水平及最終用戶體驗(yàn)。

現(xiàn)代的APM基本都是參考Google的Dapper體系來實(shí)現(xiàn)的。Dapper通過跟蹤請求的處理過程，來對應(yīng)用系統(tǒng)在前后端處理、服務(wù)端調(diào)用的性能消耗進(jìn)行跟蹤。Google基于Dapper的實(shí)現(xiàn)發(fā)表了論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，給行業(yè)內(nèi)分布式跟蹤的實(shí)現(xiàn)提供了非常有價值的參考，該論文也成為了當(dāng)前分布式跟蹤系統(tǒng)的理論基礎(chǔ)。大家可以參考Dapper論文原版，進(jìn)行詳細(xì)了解，本文只對原理做簡單介紹。

如上圖所示，對于業(yè)務(wù)鏈條中的每一次請求調(diào)用，劃分為clientSend（客戶端發(fā)送請求）、clientRecv（客戶端收到響應(yīng)）、serverRecv（服務(wù)端收到請求）、serverSend（服務(wù)端發(fā)送響應(yīng)）等四個事件，并由這四個事件組織為一個稱作Span的數(shù)據(jù)結(jié)構(gòu)。通過定義Span之間的調(diào)用（父子）關(guān)系，可以對離散的Span數(shù)據(jù)進(jìn)行重組，以還原完整的調(diào)用鏈條。Span間的關(guān)系通過traceId、parenTId、spanId來標(biāo)識。traceId是一次完整調(diào)用鏈路的唯一標(biāo)識，parenTId標(biāo)識當(dāng)前Span的前一個調(diào)用Span，spanId用來唯一的標(biāo)識某一次調(diào)用。Span在跟蹤鏈路中的關(guān)聯(lián)關(guān)系可以用下圖表示：

基于Google Dapper這種通過traceid、parenTId、spanid還原原始鏈路的思路，眾多大型互聯(lián)網(wǎng)公司都開發(fā)了自己的調(diào)用跟蹤系統(tǒng)，如Twitter的Zipkin、淘寶的鷹眼、京東的Hydra、開源的PinPoint，總體思路雖然一致，但是植入點(diǎn)選擇上卻有一些分歧。

分布式追蹤采集技術(shù)兩大流派橫評

應(yīng)用性能管理系統(tǒng)主要由數(shù)據(jù)源、采集傳輸、分析計(jì)算、可視化查詢幾部分組成，其中最核心的部分就是數(shù)據(jù)源。通過從客戶端和服務(wù)端進(jìn)行數(shù)據(jù)采集，其中客戶端的數(shù)據(jù)采集技術(shù)主要包括主動式撥測與被動式埋點(diǎn)探測，在此不再展開詳細(xì)描述，本文主要對服務(wù)端的數(shù)據(jù)采集技術(shù)進(jìn)行簡單介紹。

服務(wù)端的數(shù)據(jù)采集主要分為兩大類：

·網(wǎng)絡(luò)旁路監(jiān)聽，通過在應(yīng)用或服務(wù)部署的生產(chǎn)網(wǎng)絡(luò)的交換機(jī)或網(wǎng)絡(luò)接口抓取應(yīng)用訪問流量進(jìn)行應(yīng)用性能分析。這種方式對于應(yīng)用或者服務(wù)的侵入性小，性能影響小。然而此方式采集粒度較大，無法提供代碼級的問題定位，且在安全傳輸協(xié)議下，無法針對請求或事物進(jìn)行分析。

·探針埋點(diǎn)，通過在生產(chǎn)服務(wù)器上的應(yīng)用部署或者嵌入探針的方式進(jìn)行應(yīng)用性能數(shù)據(jù)采集。這種方式能夠提供非常完整與細(xì)粒度的監(jiān)控數(shù)據(jù)采集，提供代碼級的問題定位。但此方式對于應(yīng)用來說是侵入性的，如果埋點(diǎn)代碼異常，會對應(yīng)用本身的性能和穩(wěn)定性產(chǎn)生一定影響。

在針對應(yīng)用與服務(wù)的埋點(diǎn)數(shù)據(jù)采集中，主要使用了探針埋點(diǎn)的方式。探針埋點(diǎn)的方式主要分為兩類，以Zipkin為代表的代碼侵入式埋點(diǎn)與以PinPoint為代表的字節(jié)碼增強(qiáng)式埋點(diǎn)。

Zipkin與侵入式采集 不依賴框架生態(tài)成熟

Zipkin是Twitter開源的分布式追蹤系統(tǒng)，用戶幫助微服務(wù)收集排查潛在問題的時序數(shù)據(jù)，提供調(diào)用跟蹤數(shù)據(jù)的收集、存儲、查詢以及依賴分析的能力。Zipkin是一個分布式跟蹤系統(tǒng)，不具備用戶體驗(yàn)分析、應(yīng)用監(jiān)控統(tǒng)計(jì)等特性。Zipkin使用代碼侵入埋點(diǎn)的方式，官方提供基于Finagle框架的埋點(diǎn)方案，其他語言和框架的支持主要依賴社區(qū)貢獻(xiàn)。當(dāng)前支持包括Java、Scala、Node、Go、Python、Ruby、C#等主流語言和框架。代碼侵入式埋點(diǎn)指通過提供應(yīng)用開發(fā)的SDK，或者提供集成埋點(diǎn)代碼的框架的方式供應(yīng)用開發(fā)者調(diào)用。部分具備框架研發(fā)能力的企業(yè)像Google一樣將植入點(diǎn)選在開發(fā)框架或通信框架中，確?；诮y(tǒng)一框架開發(fā)或通信的應(yīng)用天然具備埋點(diǎn)能力，除框架開發(fā)團(tuán)隊(duì)外無需關(guān)注埋點(diǎn)實(shí)現(xiàn)、調(diào)用方式。這種埋點(diǎn)方式優(yōu)勢在于使用框架后無需額外關(guān)注埋點(diǎn)能力，變相降低了埋點(diǎn)的成本。Twitter的Zipkin、淘寶的鷹眼選擇了這種埋點(diǎn)方式。

同時，業(yè)界也有非常多的埋點(diǎn)裝備庫，支持使用埋點(diǎn)組件的方式實(shí)現(xiàn)調(diào)用鏈數(shù)據(jù)埋點(diǎn)。這種埋點(diǎn)方式，通過提供標(biāo)準(zhǔn)的服務(wù)框架，如：Servlet、Spring MVC、Http Client以及通用的中間件，如MySQL、Kafka等的裝備類的方式，通過編寫簡單代碼和配置，讓基于這些標(biāo)準(zhǔn)框架構(gòu)建的應(yīng)用可以輸出調(diào)用鏈報告數(shù)據(jù)。Brave為這種埋點(diǎn)方式提供了大量的標(biāo)準(zhǔn)框架實(shí)現(xiàn)。也提供了非常簡單且標(biāo)準(zhǔn)化的接口，支持在以上的封裝實(shí)現(xiàn)無法滿足業(yè)務(wù)要求時，進(jìn)行定制與擴(kuò)展。

代碼侵入式埋點(diǎn)具有較好的擴(kuò)展性，方便用戶自定義采集的數(shù)據(jù)類型與層次。但是，不論提供框架埋點(diǎn)的方式還是提供裝備庫、SDK的方式，都需要代碼侵入，在應(yīng)用開發(fā)以及框架等升級場景下，應(yīng)用需要重新修改代碼。同時，對于應(yīng)用開發(fā)人員來說，精準(zhǔn)的識別需要埋點(diǎn)的地方也具有一定難度，而且基于代碼侵入的埋點(diǎn)跟蹤級別較低，無法獲取足夠詳細(xì)的運(yùn)行態(tài)信息。

深入埋點(diǎn)實(shí)現(xiàn)非侵入

與Zipkin不同，PinPoint是一款開源的應(yīng)用程序性能管理（Application Performance Management）工具，使用字節(jié)碼增強(qiáng)的方式進(jìn)行數(shù)據(jù)源收集，目前只有官方提供的Java Agent探針。字節(jié)碼增強(qiáng)式埋點(diǎn)方式，提倡代碼的非侵入性，不同的編程語言，通過不同的技術(shù)在語言運(yùn)行環(huán)境或基礎(chǔ)庫上植入。對于Java應(yīng)用，利用字節(jié)碼增強(qiáng)技術(shù)，在啟動JVM時通過不同的埋點(diǎn)插件覆蓋不同的通信協(xié)議、中間件、開發(fā)框架，對Java基礎(chǔ)調(diào)用代碼進(jìn)行函數(shù)級埋點(diǎn)。這種埋點(diǎn)方式優(yōu)勢在于能夠拿到堆棧級的調(diào)用信息與其他更多運(yùn)行態(tài)信息，幫助使用者無需日志等輔助手段即可快速完成問題定位。

PinPoint使用字節(jié)碼增強(qiáng)技術(shù)進(jìn)行APM數(shù)據(jù)采集，通過在應(yīng)用啟動時配置java agent探針的方式，主動干預(yù)應(yīng)用代碼行為，應(yīng)用開發(fā)者無需進(jìn)行代碼修改，由PinPoint來決定在哪些API進(jìn)行數(shù)據(jù)埋點(diǎn)。相比較PinPoint的字節(jié)碼增強(qiáng)技術(shù)與其他APM系統(tǒng)的代碼侵入式埋點(diǎn)來說，字節(jié)碼增強(qiáng)技術(shù)從理論上來說能夠在任何地方進(jìn)行埋點(diǎn)，而類似Brave裝備庫等侵入式埋點(diǎn)的方式本身依賴中間件的實(shí)現(xiàn)方式，其提供的應(yīng)用層面的 API 還需要框架底層驅(qū)動的支持，才能實(shí)現(xiàn)攔截。

PinPoint 在實(shí)現(xiàn)之初就考慮到了性能優(yōu)化，如采用 Thrift 的二進(jìn)制變長編碼格式、使用 UDP 作為傳輸鏈路、在傳遞常量的時候使用數(shù)據(jù)參考字典、使用異步傳輸方式等。但任然存在一些性能問題與使用的約束，并且由于字節(jié)碼增強(qiáng)技術(shù)對開發(fā)人員有較高的要求，其在擴(kuò)展性和社區(qū)生態(tài)方面具有一定的劣勢。

華為APM結(jié)合PinPoint與Zipkin兩種典型系統(tǒng)的優(yōu)點(diǎn)，提供更便捷、更高效、性價比更高的解決方案。

1. 非侵入式數(shù)據(jù)采集：一鍵式采集部署，更高效與健壯的數(shù)據(jù)采集能力

華為APM探針借鑒PinPoint采集探針優(yōu)勢，在采集數(shù)據(jù)模型、輸出組件性能、可靠性等方面進(jìn)行優(yōu)化，并統(tǒng)計(jì)業(yè)界各框架與中間件的使用廣泛性基礎(chǔ)上，增加插件支持能力。以保證在最小的資源占用下，為用戶提供最為有用的性能分析數(shù)據(jù)。

· 探針自動部署：華為APM支持與華為云容器引擎、云應(yīng)用編排等服務(wù)配合使用，可以在應(yīng)用部署時通過簡單勾選，實(shí)現(xiàn)采集探針的自動部署。

· 支持Zipkin模型：雖然PinPoint與Zipkin均基于Google Dapper的論文，理論基礎(chǔ)大致相同。但是在調(diào)用鏈的數(shù)據(jù)模型上還是有很大的差異性。在開放性以及社區(qū)活躍度等方面，Zipkin更具有優(yōu)勢。為支持Zipkin用戶接入，華為APM探針支持按照Zipkin的數(shù)據(jù)模型進(jìn)行調(diào)用鏈數(shù)據(jù)輸出。

· 數(shù)據(jù)分類優(yōu)化：對于APM調(diào)用性能統(tǒng)計(jì)分析（吞吐量、平均時延、TPN等），業(yè)界通用的方式為使用調(diào)用鏈數(shù)據(jù)進(jìn)行二次抽取匯聚。該方式下需要盡量多的調(diào)用鏈數(shù)據(jù)樣本，以使統(tǒng)計(jì)數(shù)據(jù)盡可能準(zhǔn)確，勢必消耗更多的應(yīng)用資源。為解決這個問題，華為APM探針對采集數(shù)據(jù)源進(jìn)行了分類：調(diào)用鏈數(shù)據(jù)與KPI數(shù)據(jù)。KPI數(shù)據(jù)針對每個業(yè)務(wù)請求按照周期進(jìn)行匯聚，輸出包含請求發(fā)起方、請求服務(wù)方、調(diào)用事務(wù)、調(diào)用狀態(tài)（耗時、成功或失敗等）等信息。由于KPI數(shù)據(jù)周期性輸出，且相比較調(diào)用鏈數(shù)據(jù)小得多，因此能夠在很小的資源負(fù)載下實(shí)現(xiàn)全量請求采集與統(tǒng)計(jì)。

· 數(shù)據(jù)精準(zhǔn)采集：調(diào)用鏈數(shù)據(jù)更多的關(guān)注調(diào)用超時（閾值支持自定義）或調(diào)用異常的調(diào)用鏈條。華為APM在基礎(chǔ)采樣率的基礎(chǔ)上，從客戶的實(shí)際運(yùn)維場景觸發(fā)，提供精準(zhǔn)采集動態(tài)配置能力。精準(zhǔn)采集支持客戶針對應(yīng)用或交易事務(wù)設(shè)置超時閾值、周期采集異常調(diào)用樣本個數(shù)、周期內(nèi)正常調(diào)用樣本，以減少資源消耗的同時保證異?；虺瑫r請求的數(shù)據(jù)樣本滿足性能分析要求。

· 數(shù)據(jù)傳輸優(yōu)化：針對大數(shù)據(jù)量下數(shù)據(jù)輸出對資源的消耗較高的問題，對輸出組件進(jìn)行優(yōu)化，通過異步文件輸出與異步Pipe輸出、輸出數(shù)據(jù)Cache，減少數(shù)據(jù)類型等方式，優(yōu)化應(yīng)用資源占用。

· 采集逃生機(jī)制：在高并發(fā)峰值場景下，應(yīng)用業(yè)務(wù)請求多，資源消耗大。此時，為保證業(yè)務(wù)正常運(yùn)行，華為APM支持用戶自定義配置逃生資源閾值。在應(yīng)用資源消耗達(dá)到閾值后，華為APM探針主動停止所有運(yùn)維數(shù)據(jù)采集，在資源消耗下降至閾值以下時自動恢復(fù)數(shù)據(jù)采集。逃生機(jī)制支持動態(tài)配置。

2. 數(shù)字化運(yùn)營：提供業(yè)務(wù)運(yùn)營體驗(yàn)管理與性能分析

實(shí)時跟蹤每條業(yè)務(wù)交易，快速分析交易的運(yùn)行狀態(tài)并提供診斷能力

· 自定義事務(wù)：用戶可根據(jù)每條URL定義事務(wù)名稱，方便理解。

· 健康規(guī)則配置：可以對每條事務(wù)配置健康規(guī)則，如超過1s提示異常。

· 性能追蹤：精確采集異常性能數(shù)據(jù)，可對比歷史基線數(shù)據(jù)，也能找到應(yīng)用的異常方法，提升運(yùn)維效率。

3. 應(yīng)用程序分析：應(yīng)用關(guān)系與異常一目了然、故障下鉆

· 應(yīng)用發(fā)現(xiàn)與依賴關(guān)系：精確采集異常性能數(shù)據(jù)，可對比歷史基線數(shù)據(jù)，也能找到應(yīng)用的異常方法，提升運(yùn)維效率。

· 應(yīng)用KPI匯聚：微服務(wù)實(shí)例匯聚到應(yīng)用，KPI數(shù)據(jù)自動匯聚到應(yīng)用。

4. 應(yīng)用程序跟蹤：對異常業(yè)務(wù)調(diào)用鏈追蹤，快速問題定界

支持平臺、資源、應(yīng)用的監(jiān)控和微服務(wù)調(diào)用鏈分析：

· 海量數(shù)據(jù)規(guī)模支撐：支持百萬容器監(jiān)控，秒級查詢響應(yīng)。

· 故障下鉆：通過單擊故障節(jié)點(diǎn)可自動下鉆到故障的微服務(wù)實(shí)例、也可以關(guān)聯(lián)到失敗的調(diào)用鏈和調(diào)用棧，查看失敗函數(shù)的入?yún)⒑头祷刂怠?/p>