選型目的

        隨著公司業務的與日俱增，各個系統也越來越複雜，服務間的呼叫，服務的依賴，以及分析服務的效能問題也越棘手，因此引入服務追蹤系統尤為重要。
現有的服務追蹤體系，基本都是參考Google的Dapper的體系來做的。通過跟蹤請求的處理過程，來對應用系統在前後端處理、服務端呼叫的效能消耗進行跟蹤（每個請求的完整呼叫鏈路，收集呼叫鏈路上每個服務的效能資料），方便工程師能夠快速定位問題。

主要選型技術
        Zipkin
       Pinpoint

一，Zipkin

簡介

       twitter開源出來的，參考Dapper的體系實現，為分散式鏈路呼叫監控系統，聚合各業務系統呼叫延遲資料，達到鏈路呼叫監控跟蹤的目的。

實現

       Zipkin的一個叫Brave的元件來實現對應用內部的效能分析資料採集，通過實現一系列的java攔截器，來做到對http/servlet請求、資料庫訪問的呼叫過程跟蹤。然後通過在spring之類的配置檔案里加入這些攔截器，完成對java應用的效能資料採集。

 

二，Pinpoint

簡介

       pinpoint是開源在github上的一款APM監控工具，它是用Java編寫的，用於大規模分散式系統監控。它對效能的影響最小（只增加約3％資源利用率），安裝agent是無侵入式的。

實現

       通過JavaAgent的機制來做位元組碼程式碼植入，實現加入traceid和抓取效能資料的目的。
 

三，對比

侵入性

       pinPoint採用的是Java Agent向節點應用指定的函式前注入before和after邏輯，向伺服器傳送訊息，因此基本不用修改程式碼，只需簡單修改一下配置；--零侵入

       zipKin採用的是布點等方式，需要修改程式原始碼進行預埋點，相對麻煩一點；
dubbo實現Filter、http新增攔截器等方式進行布點。    ---侵入、更靈活

效能

       Pinpoint 採用二進位制格式、非同步、UDP的方式進行取樣，zipkin非同步傳輸。

擴充套件性

       pinPoint原理是Java Agent，因此支援的模組不多，如下：
•    Tomcat 6/7/8, Jetty 8/9
•    Spring, Spring Boot
•    Apache HTTP Client 3.x/4.x, JDK HttpConnector, GoogleHttpClient, OkHttpClient, NingAsyncHttpClient
•    Thrift Client, Thrift Service
•    MySQL, Oracle, MSSQL, CUBRID, DBCP, POSTGRESQL
•    Arcus, Memcached, Redis
•    iBATIS, MyBatis
•    gson, Jackson, Json Lib
•    log4j, Logback

       zipKin基本可以支援所有的應用、所有的語言，並接提供了各種客戶端，例如java的brave客戶端，js的zipkin-js客戶端

資料展示
       zipKin提供最簡單的展示介面，只是簡單的展示鏈路所用時間；
 
 
       pinPoint的展示介面要豐富的多，並且提供各種統計方式；
 

 相關部署手冊：