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

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

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

APM的定義與演進

APM (Application Performance Management) 即應用性能管理，屬于IT運維管理（ITOM)范疇。主要是針對企業(yè)關鍵業(yè)務的IT應用性能和用戶體驗的監(jiān)測、優(yōu)化，提高企業(yè)IT應用的可靠性和質量，保證用戶得到良好的服務，降低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、內存、網(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)等技術的迅猛發(fā)展，各種業(yè)務應用不斷出現(xiàn)，IT應用復雜度呈現(xiàn)爆炸式增長，而互聯(lián)網(wǎng)產品本身“用戶至上”的屬性決定用戶體驗成為各互聯(lián)網(wǎng)產品生存發(fā)展的關鍵因素。如何提升用戶體驗，保證服務和產品的可靠性、穩(wěn)定性、優(yōu)化服務等問題，對應用性能管理提出了新的需求，應用性能管理進入以用戶體驗為核心、專注業(yè)務交易與應用架構高度復雜性的第三階段。

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

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

分布式追蹤技術原理

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

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

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

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

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

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

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

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

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

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

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

同時，業(yè)界也有非常多的埋點裝備庫，支持使用埋點組件的方式實現(xiàn)調用鏈數(shù)據(jù)埋點。這種埋點方式，通過提供標準的服務框架，如：Servlet、Spring MVC、Http Client以及通用的中間件，如MySQL、Kafka等的裝備類的方式，通過編寫簡單代碼和配置，讓基于這些標準框架構建的應用可以輸出調用鏈報告數(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é)碼增強式埋點方式，提倡代碼的非侵入性，不同的編程語言，通過不同的技術在語言運行環(huán)境或基礎庫上植入。對于Java應用，利用字節(jié)碼增強技術，在啟動JVM時通過不同的埋點插件覆蓋不同的通信協(xié)議、中間件、開發(fā)框架，對Java基礎調用代碼進行函數(shù)級埋點。這種埋點方式優(yōu)勢在于能夠拿到堆棧級的調用信息與其他更多運行態(tài)信息，幫助使用者無需日志等輔助手段即可快速完成問題定位。

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

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

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

華為APM結合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的論文，理論基礎大致相同。但是在調用鏈的數(shù)據(jù)模型上還是有很大的差異性。在開放性以及社區(qū)活躍度等方面，Zipkin更具有優(yōu)勢。為支持Zipkin用戶接入，華為APM探針支持按照Zipkin的數(shù)據(jù)模型進行調用鏈數(shù)據(jù)輸出。

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

· 數(shù)據(jù)精準采集：調用鏈數(shù)據(jù)更多的關注調用超時（閾值支持自定義）或調用異常的調用鏈條。華為APM在基礎采樣率的基礎上，從客戶的實際運維場景觸發(fā)，提供精準采集動態(tài)配置能力。精準采集支持客戶針對應用或交易事務設置超時閾值、周期采集異常調用樣本個數(shù)、周期內正常調用樣本，以減少資源消耗的同時保證異?；虺瑫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. 應用程序分析：應用關系與異常一目了然、故障下鉆

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

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

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

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

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

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