1. 程式人生 > >分散式鏈路追蹤技術對比

分散式鏈路追蹤技術對比

方案選擇

本文最終選擇了zipkin+sleuth做二次開發,這樣做靈活性比較大一點。 有興趣的可以進我部落格看一下,我會將我二次開發過程當中遇到的問題發出來。

常見開源產品

cat, zipkin, pinpoint , skywalking 

cat 

由大眾點評開源,基於Java開發的實時應用監控平臺,包括實時應用監控,業務監控 。 整合方案是通過

程式碼埋點的方式來實現監控,比如: 攔截器,註解,過濾器等。   對程式碼的侵入性很大,整合成本較高。

風險較大。 

支援技術棧: 

  • dubbo
  • spring mvc ,spring aop ,springmvc-url
  • spring boot
  • mybatis
  • log4j , logback
  • playframework
  • http請求

zipkin

由Twitter團隊開源, Zipkin是一個分散式的跟蹤系統。它有助於收集資料需要解決潛在的問題在市微服架構的時機。它管理資料的收集和查詢 . 

該產品結合spring-cloud-sleuth使用較為簡單, 整合很方便。  但是功能較簡單。 

支援技術棧: 

  • spring cloud

      以上是結合spring-cloud-sleuth支援的技術棧

pinpoint

由韓國團隊naver團隊開源,針對大規模分散式系統用鏈路監控,使用java寫的工具。靈感來自短小精悍,幫助分析系統的

體結構和內部元件如何被呼叫在分散式應用提供了一個很好的解決方案。

使用java探針位元組碼增加技術,實現對整個應用的監控 。 對應用零侵入

支援技術棧: 

  • Tomcat 6+, Jetty 8/9, JBoss 6, Resin 4, Websphere 6+, Vertx 3.3+
  • Spring, Spring Boot (Embedded Tomcat, Jetty)
  • HTTP Client 3.x/4.x, HttpConnector, GoogleHttpClient, OkHttpClient, NingAsyncHttpClient
  • Thrift, Dubbo
  • mysql, oracle, mssql, cubrid,PostgreSQL, maria
  • arcus, memcached, redis, cassandra
  • MyBatis
  • DBCP, DBCP2, HIKARICP
  • gson, Jackson, Json Lib
  • log4j, Logback

skywalking 

2015年由個人吳晟(華為開發者)開源 , 2017年加入Apache孵化器。 

針對分散式系統的應用效能監控系統,特別針對微服務、cloud native和容器化(Docker, Kubernetes, Mesos)架構, 其核心是個分散式追蹤系統。

使用java探針位元組碼增加技術,實現對整個應用的監控 。 對應用零侵入

支援技術棧

  • Tomcat7+ , resin3+, jetty
  • spring boot ,spring mvc
  • strtuts2
  • spring RestTemplete  ,spring-cloud-feign
  • okhttp , httpClient
  • msyql ,oracle , H2 , sharding-jdbc,PostgreSQL
  • dubbo,dubbox ,motan, gRpc ,
  • rocketMq , kafla
  • redis, mongoDB,memcached ,
  • elastic-job , Netflix Eureka , Hystric

效能分析

摘自:https://juejin.im/post/5a7a9e0af265da4e914b46f1

根據其他部落格提供的效能測試報告如下

模擬了三種併發使用者: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%之內。

比較

cat zipkin pinpoint skywalking 
依賴
  • Java 6,7,8
  • Maven 3.2.3+
  • mysql5.6
  • Linux 2.6以及之上(2.6核心才可以支援epoll)
  • Java 6,7,8
  • Maven3.2+
  • rabbitMQ
  • Java 6,7,8
  • maven3+
  • Hbase0.94+
  • Java 6,7,8
  • maven3.0+
  • nodejs
  • zookeeper
  • elasticsearch
實現方式 程式碼埋點(攔截器,註解,過濾器等) 攔截請求,傳送(HTTP,mq)資料至zipkin服務 java探針,位元組碼增強 java探針,位元組碼增強
儲存選擇 mysql , hdfs in-memory , mysql , Cassandra , Elasticsearch HBase elasticsearch , H2
通訊方式 http , MQ thrift GRPC
MQ監控 不支援 不支援 不支援 支援(RocketMQ,kafka)
全域性呼叫統計 支援 不支援 支援 支援
trace查詢 不支援 支援 不支援 支援
報警 支援 不支援 支援 支援
JVM監控 不支援 不支援 支援 支援
star數 4.5K 7.9K 5.6K 2.8K
優點 功能完善。

spring-cloud-sleuth可以很好的整合zipkin , 程式碼無侵入,整合非常簡單 , 社群更加活躍。

對外提供有query介面,更加容易二次開發

完全無侵入, 僅需修改啟動方式,介面完善,功能細緻。

完全無侵入,介面完善,支援應用拓撲圖及單個呼叫鏈查詢。

功能比較完善(zipkin + pinpoint)

缺點
  • 程式碼侵入性較強,需要埋點
  • 文件比較混亂,文件與釋出版本的符合性較低,需要依賴點評私服 (或者需要把他私服上的jar手動下載下來,然後上傳到我們的私服上去)。
  • 預設使用的是http請求向zipkin上報資訊,耗效能。
  • 跟sleuth結合可以使用rabbitMQ的方式非同步來做,增加了複雜度,需要引入rabbitMQ 。
  • 資料分析比較簡單。
  • 不支援查詢單個呼叫鏈, 對外表現的是整個應用的呼叫生態。
  • 二次開發難度較高
  • 3.2版本之前BUG較多 ,網上反映相容性較差 . 3.2新版本的反映情況較少
  • 依賴較多。
文件 網上資料較少,僅官網提供的文件,比較亂 文件完善 文件完善 文件完善
開發者 大眾點評 twitter naver 吳晟(華為開發者) ,目前已經加入Apache孵化器
使用公司 大眾點評, 攜程, 陸金所,同程旅遊,獵聘網 twitter naver 華為軟體開發雲、天源迪科、噹噹網、京東金融

sharedCode原始碼交流群,歡迎喜歡閱讀原始碼的朋友加群,新增下面的微信, 備註”加群“ 。