隨著虛擬化、云化技術越來越成熟，分布式系統的成本和架構優勢日漸凸顯，特別是微服務等設計理念在業務系統尤其是大型的互聯網公司中越來越流行，業務的調用關系越來越復雜。

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

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

APM的定義與演進

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

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

第二階段的APM以監控各種基礎組件為主，隨著互聯網的發展，網絡應用變得越來越復雜，各種基礎組件越來越多，促使APM進入以IT組件的健康狀態、可用性、性能監控為中心第二個階段。

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

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

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

分布式追蹤技術原理

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

如上圖所示，對于業務鏈條中的每一次請求調用，劃分為clientSend（客戶端發送請求）、clientRecv（客戶端收到響應）、serverRecv（服務端收到請求）、serverSend（服務端發送響應）等四個事件，并由這四個事件組織為一個稱作Span的數據結構。通過定義Span之間的調用（父子）關系，可以對離散的Span數據進行重組，以還原完整的調用鏈條。Span間的關系通過traceId、parentId、spanId來標識。traceId是一次完整調用鏈路的唯一標識，parentId標識當前Span的前一個調用Span，spanId用來唯一的標識某一次調用。Span在跟蹤鏈路中的關聯關系可以用下圖表示：

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

分布式追蹤采集技術兩大流派橫評

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

服務端的數據采集主要分為兩大類：

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

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

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

Zipkin與侵入式采集 不依賴框架生態成熟

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

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

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

PinPoint與字節碼增強式采集

深入埋點實現非侵入

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

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

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

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

華為APM結合PinPoint與Zipkin兩種典型系統的優點，提供更便捷、更高效、性價比更高的解決方案。

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

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

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

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

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

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

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

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

2. 數字化運營：提供業務運營體驗管理與性能分析

實時跟蹤每條業務交易，快速分析交易的運行狀態并提供診斷能力

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

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

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

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

· 應用發現與依賴關系：精確采集異常性能數據，可對比歷史基線數據，也能找到應用的異常方法，提升運維效率。

· 應用KPI匯聚：微服務實例匯聚到應用，KPI數據自動匯聚到應用。

4. 應用程序跟蹤：對異常業務調用鏈追蹤，快速問題定界

支持平臺、資源、應用的監控和微服務調用鏈分析：

· 海量數據規模支撐：支持百萬容器監控，秒級查詢響應。

· 故障下鉆：通過單擊故障節點可自動下鉆到故障的微服務實例、也可以關聯到失敗的調用鏈和調用棧，查看失敗函數的入參和返回值。