APM 原理與框架選型

0. APM簡介

隨着微服務架構的流行，一次請求每每須要涉及到多個服務，所以服務性能監控和排查就變得更復雜：

• 不一樣的服務可能由不一樣的團隊開發、甚至可能使用不一樣的編程語言來實現
• 服務有可能布在了幾千臺服務器，橫跨多個不一樣的數據中心

所以，就須要一些能夠幫助理解系統行爲、用於分析性能問題的工具，以便發生故障的時候，可以快速定位和解決問題，這就是APM系統，全稱是（Application Performance Monitor，固然也有叫 Application Performance Management tools）

AMP最先是谷歌公開的論文提到的 Google Dapper。Dapper是Google生產環境下的分佈式跟蹤系統，自從Dapper發展成爲一流的監控系統以後，給google的開發者和運維團隊幫了大忙，因此谷歌公開論文分享了Dapper。

1. 谷歌Dapper介紹

1.1 Dapper的挑戰

在google的首頁頁面，提交一個查詢請求後，會經歷什麼：

• 可能對上百臺查詢服務器發起了一個Web查詢，每個查詢都有本身的Index
• 這個查詢可能會被髮送到多個的子系統，這些子系統分別用來處理廣告、進行拼寫檢查或是查找一些像圖片、視頻或新聞這樣的特殊結果
• 根據每一個子系統的查詢結果進行篩選，獲得最終結果，最後彙總到頁面上

總結一下：

• 一次全局搜索有可能調用上千臺服務器，涉及各類服務。
• 用戶對搜索的耗時是很敏感的，而任何一個子系統的低效都致使致使最終的搜索耗時

若是一次查詢耗時不正常，工程師怎麼來排查究竟是由哪一個服務調用形成的？

• 首先，這個工程師可能沒法準確的定位到此次全局搜索是調用了哪些服務，由於新的服務、乃至服務上的某個片斷，都有可能在任什麼時候間上過線或修改過，有多是面向用戶功能，也有多是一些例如針對性能或安全認證方面的功能改進
• 其次，你不能苛求這個工程師對全部參與此次全局搜索的服務都瞭如指掌，每個服務都有多是由不一樣的團隊開發或維護的
• 再次，這些暴露出來的服務或服務器有可能同時還被其餘客戶端使用着，因此此次全局搜索的性能問題甚至有多是由其餘應用形成的

從上面能夠看出Dapper須要：

• 無所不在的部署，無所不在的重要性不言而喻，由於在使用跟蹤系統的進行監控時，即使只有一小部分沒被監控到，那麼人們對這個系統是否是值得信任都會產生巨大的質疑
• 持續的監控

1.2 Dapper的三個具體設計目標

1. 性能消耗低

   APM組件服務的影響應該作到足夠小。服務調用埋點自己會帶來性能損耗，這就須要調用跟蹤的低損耗，實際中還會經過配置採樣率的方式，選擇一部分請求去分析請求路徑。在一些高度優化過的服務，即便一點點損耗也會很容易察覺到，並且有可能迫使在線服務的部署團隊不得不將跟蹤系統關停。

2. 應用透明，也就是代碼的侵入性小

   即也做爲業務組件，應當儘量少入侵或者無入侵其餘業務系統，對於使用方透明，減小開發人員的負擔。

   對於應用的程序員來講，是不須要知道有跟蹤系統這回事的。若是一個跟蹤系統想生效，就必須須要依賴應用的開發者主動配合，那麼這個跟蹤系統也太脆弱了，每每因爲跟蹤系統在應用中植入代碼的bug或疏忽致使應用出問題，這樣纔是沒法知足對跟蹤系統「無所不在的部署」這個需求。

3. 可擴展性

   一個優秀的調用跟蹤系統必須支持分佈式部署，具有良好的可擴展性。可以支持的組件越多固然越好。或者提供便捷的插件開發API，對於一些沒有監控到的組件，應用開發者也能夠自行擴展。

4. 數據的分析

   數據的分析要快 ，分析的維度儘量多。跟蹤系統能提供足夠快的信息反饋，就能夠對生產環境下的異常情況作出快速反應。分析的全面，可以避免二次開發。

1.3 Dapper的分佈式跟蹤原理

先來看一次請求調用示例：

1. 包括：前端（A），兩個中間層（B和C），以及兩個後端（D和E）
2. 當用戶發起一個請求時，首先到達前端A服務，而後分別對B服務和C服務進行RPC調用；
3. B服務處理完給A作出響應，可是C服務還須要和後端的D服務和E服務交互以後再返還給A服務，最後由A服務來響應用戶的請求；

Dapper是如何來跟蹤記錄此次請求呢？

1.3.1 跟蹤樹和span

Span是dapper的基本工做單元，一次鏈路調用（能夠是RPC，DB等沒有特定的限制）建立一個span，經過一個64位ID標識它；同時附加（Annotation）做爲payload負載信息，用於記錄性能等數據。

上圖說明了span在一次大的跟蹤過程當中是什麼樣的。Dapper記錄了span名稱，以及每一個span的ID和父ID，以重建在一次追蹤過程當中不一樣span之間的關係。若是一個span沒有父ID被稱爲root span。全部span都掛在一個特定的跟蹤上，也共用一個跟蹤id。

再來看下Span的細節：

Span數據結構：

type Span struct {
    TraceID    int64 // 用於標示一次完整的請求id
    Name       string
    ID         int64 // 當前此次調用span_id
    ParentID   int64 // 上層服務的調用span_id 最上層服務parent_id爲null
    Annotation []Annotation // 用於標記的時間戳
    Debug      bool
}

1.3.2 TraceID

相似於 樹結構的Span集合，表示一次完整的跟蹤，從請求到服務器開始，服務器返回response結束，跟蹤每次rpc調用的耗時，存在惟一標識trace_id。好比：你運行的分佈式大數據存儲一次Trace就由你的一次請求組成。

每種顏色的note標註了一個span，一條鏈路經過TraceId惟一標識，Span標識發起的請求信息。樹節點是整個架構的基本單元，而每個節點又是對span的引用。節點之間的連線表示的span和它的父span直接的關係。雖然span在日誌文件中只是簡單的表明span的開始和結束時間，他們在整個樹形結構中倒是相對獨立的。

1.3.3 Annotation

Dapper容許應用程序開發人員在Dapper跟蹤的過程當中添加額外的信息，以監控更高級別的系統行爲，或幫助調試問題。這就是Annotation：

Annotation，用來記錄請求特定事件相關信息（例如時間），一個span中會有多個annotation註解描述。一般包含四個註解信息：

(1) cs：Client Start，表示客戶端發起請求

(2) sr：Server Receive，表示服務端收到請求

(3) ss：Server Send，表示服務端完成處理，並將結果發送給客戶端

(4) cr：Client Received，表示客戶端獲取到服務端返回信息

Annotation數據結構：

type Annotation struct { Timestamp int64 Value string Host Endpoint Duration int32 }

1.3.4 採樣率

低損耗的是Dapper的一個關鍵的設計目標，由於若是這個工具價值未被證明但又對性能有影響的話，你能夠理解服務運營人員爲何不肯意部署它。

另外，某些類型的Web服務對植入帶來的性能損耗確實很是敏感。

所以，除了把Dapper的收集工做對基本組件的性能損耗限制的儘量小以外，Dapper支持設置採樣率來減小性能損耗，同時支持可變採樣。

2. APM組件選型

市面上的全鏈路監控理論模型大多都是借鑑Google Dapper論文，重點關注如下三種APM組件：

1. Zipkin：由Twitter公司開源，開放源代碼分佈式的跟蹤系統，用於收集服務的定時數據，以解決微服務架構中的延遲問題，包括：數據的收集、存儲、查找和展示。
2. Pinpoint：一款對Java編寫的大規模分佈式系統的APM工具，由韓國人開源的分佈式跟蹤組件。
3. Skywalking：國產的優秀APM組件，是一個對JAVA分佈式應用程序集羣的業務運行狀況進行追蹤、告警和分析的系統。

2.1 對比項

主要對比項：

1. 探針的性能

   主要是agent對服務的吞吐量、CPU和內存的影響。微服務的規模和動態性使得數據收集的成本大幅度提升。

2. collector的可擴展性

   可以水平擴展以便支持大規模服務器集羣。

3. 全面的調用鏈路數據分析

   提供代碼級別的可見性以便輕鬆定位失敗點和瓶頸。

4. 對於開發透明，容易開關

   添加新功能而無需修改代碼，容易啓用或者禁用。

5. 完整的調用鏈應用拓撲

   自動檢測應用拓撲，幫助你搞清楚應用的架構

2.2 探針的性能

比較關注探針的性能，畢竟APM定位仍是工具，若是啓用了鏈路監控組建後，直接致使吞吐量下降過半，那也是不能接受的。對skywalking、zipkin、pinpoint進行了壓測，並與基線（未使用探針）的狀況進行了對比。

選用了一個常見的基於Spring的應用程序，他包含Spring Boot, Spring MVC，redis客戶端，mysql。 監控這個應用程序，每一個trace，探針會抓取5個span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。這邊基本和 skywalkingtest 的測試應用差很少。

模擬了三種併發用戶：500，750，1000。使用jmeter測試，每一個線程發送30個請求，設置思考時間爲10ms。使用的採樣率爲1，即100%，這邊與生產可能有差異。pinpoint默認的採樣率爲20，即50%，經過設置agent的配置文件改成100%。zipkin默認也是1。組合起來，一共有12種。下面看下彙總表：

從上表能夠看出，在三種鏈路監控組件中，skywalking的探針對吞吐量的影響最小，zipkin的吞吐量居中。pinpoint的探針對吞吐量的影響較爲明顯，在500併發用戶時，測試服務的吞吐量從1385下降到774，影響很大。而後再看下CPU和memory的影響，在內部服務器進行的壓測，對CPU和memory的影響都差很少在10%以內。

2.3 collector的可擴展性

collector的可擴展性，使得可以水平擴展以便支持大規模服務器集羣。

1. zipkin

   開發zipkin-Server（其實就是提供的開箱即用包），zipkin-agent與zipkin-Server經過http或者mq進行通訊，http通訊會對正常的訪問形成影響，因此仍是推薦基於mq異步方式通訊，zipkin-Server經過訂閱具體的topic進行消費。這個固然是能夠擴展的，多個zipkin-Server實例進行異步消費mq中的監控信息。

2. skywalking

   skywalking的collector支持兩種部署方式：單機和集羣模式。collector與agent之間的通訊使用了gRPC。

3. pinpoint

   一樣，pinpoint也是支持集羣和單機部署的。pinpoint agent經過thrift通訊框架，發送鏈路信息到collector。

2.4 全面的調用鏈路數據分析

全面的調用鏈路數據分析，提供代碼級別的可見性以便輕鬆定位失敗點和瓶頸。

zipkin

zipkin的鏈路監控粒度相對沒有那麼細，從上圖能夠看到調用鏈中具體到接口級別，再進一步的調用信息並未涉及。

skywalking

**skywalking 還支持20+的中間件、框架、類庫**，好比：主流的dubbo、Okhttp，還有DB和消息中間件。上圖skywalking鏈路調用分析截取的比較簡單，網關調用user服務，**因爲支持衆多的中間件，因此skywalking鏈路調用分析比zipkin完備些**。

pinpoint

pinpoint應該是這三種APM組件中，數據分析最爲完備的組件。提供代碼級別的可見性以便輕鬆定位失敗點和瓶頸，上圖能夠看到對於執行的sql語句，都進行了記錄。還能夠配置報警規則等，設置每一個應用對應的負責人，根據配置的規則報警，支持的中間件和框架也比較完備。

2.5 對於開發透明，容易開關

對於開發透明，容易開關，添加新功能而無需修改代碼，容易啓用或者禁用。咱們指望功能能夠不修改代碼就工做並但願獲得代碼級別的可見性。

對於這一點，Zipkin 使用修改過的類庫和它本身的容器(Finagle)來提供分佈式事務跟蹤的功能。可是，它要求在須要時修改代碼。skywalking和pinpoint都是基於字節碼加強的方式，開發人員不須要修改代碼，而且能夠收集到更多精確的數據由於有字節碼中的更多信息。

2.6 完整的調用鏈應用拓撲

自動檢測應用拓撲，幫助你搞清楚應用的架構。

zipkin鏈路拓撲：

skywalking鏈路拓撲：

三個組件都能實現完整的調用鏈應用拓撲。相對來講：

• pinpoint界面顯示的更加豐富，具體到調用的DB名
• zipkin的拓撲侷限於服務於服務之間

2.7 社區支持

Zipkin 由 Twitter 開發，能夠算得上是明星團隊，而 pinpoint的Naver 的團隊只是一個默默無聞的小團隊，skywalking是國內的明星項目，目前屬於apache孵化項目，社區活躍。

2.8 總結

	zipkin	pinpoint	skywalking
探針性能	中	低	高
collector擴展性	高	中	高
調用鏈路數據分析	低	高	中
對開發透明性	中	高	高
調用鏈應用拓撲	中	高	中
社區支持	高	中	高

相對來講，skywalking更佔優，所以團隊採用skywalking做爲APM工具。

3. 參考內容

本文主要內容參考下文：
http://www.javashuo.com/article/p-ekapditc-bv.html
http://bigbully.github.io/Dapper-translation/

原文地址：http://www.cnblogs.com/xiaoqi/p/apm.html