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

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

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

APM的定義與演進

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

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

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

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

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

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

分布式追蹤技術(shù)原理

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

如上圖所示，對于業(yè)務鏈條中的每一次請求調(diào)用，劃分為clientSend（客戶端發(fā)送請求）、clientRecv（客戶端收到響應）、serverRecv（服務端收到請求）、serverSend（服務端發(fā)送響應）等四個事件，并由這四個事件組織為一個稱作Span的數(shù)據(jù)結(jié)構(gòu)。通過定義Span之間的調(diào)用（父子）關(guān)系，可以對離散的Span數(shù)據(jù)進行重組，以還原完整的調(diào)用鏈條。Span間的關(guān)系通過traceId、parentId、spanId來標識。traceId是一次完整調(diào)用鏈路的唯一標識，parentId標識當前Span的前一個調(diào)用Span，spanId用來唯一的標識某一次調(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，總體思路雖然一致，但是植入點選擇上卻有一些分歧。

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

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

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

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

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

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

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

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

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

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

PinPoint與字節(jié)碼增強式采集

深入埋點實現(xiàn)非侵入

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

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

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

華為APM的技術(shù)實踐 零侵入式的全周期呵護

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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