引言：繼上篇《幾種分佈式調用鏈監控組件的實踐與比較（一）實踐》後，本篇將會講下幾種APM選型的比較與性能測試。
1. 前文回顧
上一篇文章主要講了三種分佈式調用鏈監控組件的實踐。問題的背景由微服務架構展開，微服務的好處已經不用多說，而微服務的多了之後，千頭萬緒，下面這張圖經常被用到。
系統的複雜度因此提升。系統越複雜，越難解決問題，例如系統失敗或者性能問題。在三層架構中找到解決方案還不是太難，僅僅需要分析3個組件比如web服務器，應用服務器和數據庫，而服務器數量也不多。但是，如果問題發生在n層架構中，就需要調查大量的組件和服務器。另一個問題是僅僅分析單個組件很難看到大局;當發生一個低可見度的問題時，系統複雜度越高，就需要更長的時間來查找原因。最糟糕的是，某些情況下我們甚至可能無法查找出來。
上面其實已經提到存在的故障定位問題，基於微服務體系之下構建的業務系統存在的問題基本上分爲三類：
- 故障定位難，一個簡單操作，其背後可能是由十幾個微服務共同完成的，這些微服務也由不同的團隊去負責。一旦出現問題，最壞情況下我們也許需要這十幾個團隊一起來解決問題。
- 鏈路梳理難，應用沒有形成應用拓撲，不知道自己的服務下游會影響其他哪些人。
- 資源浪費多，容量預估難。對於一些服務，其消耗的cpm和memory可能連10%不到，遠遠沒有充分利用物理機。這其實和容量預估關聯，過大或者過小估算峯值的機器容量，都是浪費。
APM主要的目的就是解決上面所說的這四個問題，主要的手段是通過收集、存儲、分析、分佈式系統中的調用事件數據，協助開發運營人員進行故障診斷、容量預估、性能瓶頸定位以及調用鏈路梳理。第一篇其實已經講過鏈路監控組件的需求：
- 代碼的侵入性
- 探針的性能消耗
- 全面的調用鏈路數據分析
- 可擴展性
這邊列一下pinpoint在其wiki中提到的幾點：
- 分佈式事務跟蹤，跟蹤跨分佈式應用的消息
- 自動檢測應用拓撲，幫助你搞清楚應用的架構
- 水平擴展以便支持大規模服務器集羣
- 提供代碼級別的可見性以便輕鬆定位失敗點和瓶頸
- 使用字節碼增強技術，添加新功能而無需修改代碼
下面我們沿着這些需求，看一下這幾種分佈式調用鏈監控組件。
2. AMP比較
上面列了需求，但是不夠通用，筆者將需要對比的項提煉出來：
- 探針的性能 主要是agent對服務的吞吐量、CPU和內存的影響。微服務的規模和動態性使得數據收集的成本大幅度提高。
- collector的可擴展性 能夠水平擴展以便支持大規模服務器集羣。
- 全面的調用鏈路數據分析 提供代碼級別的可見性以便輕鬆定位失敗點和瓶頸。
- 對於開發透明，容易開關 添加新功能而無需修改代碼，容易啓用或者禁用。
- 完整的調用鏈應用拓撲 自動檢測應用拓撲，幫助你搞清楚應用的架構
筆者根據主要的需求，提煉出如上五點。
2.1 探針的性能
筆者其實也是比較關注探針的性能，畢竟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.2 collector的可擴展性
collector的可擴展性，使得能夠水平擴展以便支持大規模服務器集羣。
- zipkin 在前一篇文章中，我們開發了zipkin-Server（其實就是提供的開箱即用包），zipkin-agent與zipkin-Server通過http或者mq進行通信，http通信會對正常的訪問造成影響，所以還是推薦基於mq異步方式通信，zipkin-Server通過訂閱具體的topic進行消費。這個當然是可以擴展的，多個zipkin-Server實例進行異步消費mq中的監控信息。
- skywalking skywalking的collector支持兩種部署方式：單機和集羣模式。collector與agent之間的通信使用了gRPC。
- pinpoint 同樣，pinpoint也是支持集羣和單機部署的。pinpoint agent通過thrift通信框架，發送鏈路信息到collector。
2.3 全面的調用鏈路數據分析
全面的調用鏈路數據分析，提供代碼級別的可見性以便輕鬆定位失敗點和瓶頸。
- zipkin
zipkin的鏈路監控粒度相對沒有那麼細，從上圖可以看到調用鏈中具體到接口級別，再進一步的調用信息並未涉及。
- skywalking
skywalking 還支持20+的中間件、框架、類庫，比如主流的dubbo、Okhttp，還有DB和消息中間件。上圖skywalking鏈路調用分析截取的比較簡單，網關調用user服務，由於支持衆多的中間件，所以skywalking鏈路調用分析比zipkin完備些。
- pinpoint
pinpoint應該是這三種APM組件中，數據分析最爲完備的組件。提供代碼級別的可見性以便輕鬆定位失敗點和瓶頸，上圖可以看到對於執行的sql語句，都進行了記錄。還可以配置報警規則等，設置每個應用對應的負責人，根據配置的規則報警，支持的中間件和框架也比較完備。
2.4 對於開發透明，容易開關
對於開發透明，容易開關，添加新功能而無需修改代碼，容易啓用或者禁用。我們期望功能可以不修改代碼就工作並希望得到代碼級別的可見性。
對於這一點，Zipkin 使用修改過的類庫和它自己的容器(Finagle)來提供分佈式事務跟蹤的功能。但是，它要求在需要時修改代碼。skywalking和pinpoint都是基於字節碼增強的方式，開發人員不需要修改代碼，並且可以收集到更多精確的數據因爲有字節碼中的更多信息。
2.5 完整的調用鏈應用拓撲
自動檢測應用拓撲，幫助你搞清楚應用的架構。
上面三幅圖，分別展示了APM組件各自的調用拓撲，都能實現完整的調用鏈應用拓撲。相對來說，pinpoint界面顯示的更加豐富，具體到調用的DB名，zipkin的拓撲侷限於服務於服務之間。
3. 總結
本文講了三種分佈式調用鏈監控組件的比較，主要從五方面着手，筆者對每一項都進了對比。至於具體選用哪款組件，大家可以根據實際的業務需求和場景進行選型，上面比較的數據僅供參考。這三款都是開源項目，一般公司都對針對實際情況進行一些二次開發，比如增加一些組件的支持、對接現存的大數據平臺等等。
最後，看了eagleEye的相關介紹，想提下監控系統如何從被動報警轉化爲主動發現，其實和AIOps很密切。鏈路監控數據量很大，儘管可以通過壓縮比來降低傳輸的數據量，但是我們真的需要存儲每一條鏈路嗎？是不是只需要識別每一個鏈路當中出現異常的情況。時序指標當中的異常點，那個時間點我們要識別出來。識別完了之後，對異常進行關聯，定位出最後的問題。當然這個涉及到業務和應用系統層面，很複雜，但筆者認爲是後面AIOps的大趨勢。
參考：
- Technical Overview Of Pinpoint
- 阿里微服務之殤及分佈式鏈路追蹤技術原理