分布式鍊路追蹤系統深入了解

背景

對于普通系統或者服務來說，一般通過打日志來進行埋點，然後再通過elk進行定位及分析問題，更有甚者直接遠端伺服器，使用各種linux指令單手操作檢視日志，說到這，我也沒擺脫這種困境。那麼随着業務越來越複雜，企業應用也進入了分布式服務化的階段，傳統的日志監控等方式無法很好達到跟蹤調用，排查問題等需求。

總之，在各種服務之間調用：

1. 如何快速發現問題？
2. 如何判斷故障影響範圍？
3. 如何梳理服務依賴以及依賴的合理性？
4. 如何分析鍊路性能問題以及實時容量規劃？

如何在分布式服務進行日志監控呢？首先大家會想到分布式鍊路追蹤系統，說到這，就得講 OpenTracing 規範，OpenTracing 是一個輕量級的标準化層，它位于應用程式/類庫和追蹤或日志分析程式之間。詳細介紹見 opentracing文檔中文版。

在谷歌論文《 Dapper，大規模分布式系統的跟蹤系統》的指導下，許多優秀的APM應運而生。分布式追蹤系統發展很快，種類繁多，給我們帶來很大的友善。但在資料采集過程中，有時需要侵入使用者代碼，并且不同系統的 API 并不相容，這就導緻了如果您希望切換追蹤系統，往往會帶來較大改動。OpenTracing為了解決不同的分布式追蹤系統 API 不相容的問題。

技術調研名額

面對各種鍊式追蹤系統開源，我們要如何選擇：

我們主要關注在請求處理期間各個調用的各項性能名額，比如：吞吐量（TPS）、響應時間及錯誤記錄等。

1. 吞吐量，根據拓撲可計算相應元件、平台、實體裝置的實時吞吐量。
2. 響應時間，包括整體調用的響應時間和各個服務的響應時間等。
3. 錯誤記錄，根據服務傳回統計機關時間異常次數。

全鍊路性能監控 從整體次元到局部次元展示各項名額，将跨應用的所有調用鍊性能資訊集中展現，可友善度量整體和局部性能，并且友善找到故障産生的源頭，生産上可極大縮短故障排除時間。

我們除了性能名額之外，我們也需要鍊式追蹤系統擁有以下功能：

1. 請求鍊路追蹤，故障快速定位：可以通過調用鍊結合業務日志快速定位錯誤資訊。
2. 可視化： 各個階段耗時，進行性能分析。
3. 依賴優化：各個調用環節的可用性、梳理服務依賴關系以及優化。
4. 資料分析，優化鍊路：可以得到使用者的行為路徑，彙總分析應用在很多業務場景。

當然這些要求可能有些過分了，但我們換着自己的目标進行技術選型。

接下來我們主要來介紹四種常見的開源鍊式追蹤系統，除了一些背景、所使用技術棧、支援的技術棧，我們還需要深入代碼層面進行分析等等

了解鍊式追蹤系統

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

我們選擇全鍊路監控元件有哪些目标要求呢？在谷歌論文《 Dapper，大規模分布式系統的跟蹤系統》，總結如下：

1、探針的性能消耗

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

2、代碼的侵入性

即也作為業務元件，應當盡可能少入侵或者無入侵其他業務系統，對于使用方透明，減少開發人員的負擔。

對于應用的程式員來說，是不需要知道有跟蹤系統這回事的。如果一個跟蹤系統想生效，就必須需要依賴應用的開發者主動配合，那麼這個跟蹤系統也太脆弱了，往往由于跟蹤系統在應用中植入代碼的bug或疏忽導緻應用出問題，這樣才是無法滿足對跟蹤系統“無所不在的部署”這個需求。

3、可擴充性

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

4、資料的分析

資料的分析要快 ，分析的次元盡可能多。跟蹤系統能提供足夠快的資訊回報，就可以對生産環境下的異常狀況做出快速反應。分析的全面，能夠避免二次開發。

功能要求

1、埋點與生成日志

埋點即系統在目前節點的上下文資訊，可以分為 用戶端埋點、服務端埋點，以及用戶端和服務端雙向型埋點。埋點日志通常要包含以下内容traceId、spanId、調用的開始時間，協定類型、調用方ip和端口，請求的服務名、調用耗時，調用結果，異常資訊等，同時預留可擴充字段，為下一步擴充做準備；

不能造成性能負擔：一個價值未被驗證，卻會影響性能的東西，是很難在公司推廣的！

因為要寫log，業務QPS越高，性能影響越重。通過采樣和異步log解決。

2、收集和存儲日志

主要支援分布式日志采集的方案，同時增加MQ作為緩沖；

1. 每個機器上有一個 deamon 做日志收集，業務程序把自己的Trace發到daemon，daemon把收集Trace往上一級發送；
2. 多級的collector，類似pub/sub架構，可以負載均衡；
3. 對聚合的資料進行 實時分析和離線存儲；
4. 離線分析 需要将同一條調用鍊的日志彙總在一起；

3、分析和統計調用鍊路資料，以及時效性

調用鍊跟蹤分析：把同一TraceID的Span收集起來，按時間排序就是timeline。把ParentID串起來就是調用棧。

抛異常或者逾時，在日志裡列印TraceID。利用TraceID查詢調用鍊情況，定位問題。

依賴度量：

1. 強依賴：調用失敗會直接中斷主流程
2. 高度依賴：一次鍊路中調用某個依賴的幾率高
3. 頻繁依賴：一次鍊路調用同一個依賴的次數多

離線分析：按TraceID彙總，通過Span的ID和ParentID還原調用關系，分析鍊路形态。

實時分析：對單條日志直接分析，不做彙總，重組。得到目前QPS，延遲。

4、展現以及決策支援

四種系統對比

模拟了三種并發使用者：500，750，1000。使用jmeter測試，每個線程發送30個請求，設定思考時間為10ms。使用的采樣率為1，即100%，這邊與生産可能有差别。

pinpoint預設的采樣率為20，即50%，通過設定agent的配置檔案改為100%。zipkin預設也是1。組合起來，一共有12種。下面看下彙總表：

http://wiki.enmonster.com/download/attachments/8886428/1525326931.jpgversion=1&modificationDate=1525326944536&api=v2

在三種鍊路監控元件中，skywalking的探針對吞吐量的影響最小，zipkin的吞吐量居中。pinpoint的探針對吞吐量的影響較為明顯，

在500并發使用者時，測試服務的吞吐量從1385降低到774，影響很大。然後再看下CPU和memory的影響，在内部伺服器進行的壓測，對CPU和memory的影響都差不多在10%之内。

比較

比較	cat	zipkin	pinpoint	skywalking
依賴	Java 6，7，8Maven 3.2.3+mysql5.6Linux 2.6以及之上（2.6核心才可以支援epoll）	Java 6，7，8Maven3.2+rabbitMQ	Java 6，7，8maven3+Hbase0.94+	Java 6，7，8maven3.0+nodejszookeeperelasticsearch
實作方式	代碼埋點（攔截器，注解，過濾器等）	攔截請求，發送（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	華為軟體開發雲、天源迪科、當當網、京東金融

該技術對比參考:https://blog.csdn.net/u012394095/article/details/79700200

技術源碼分析

SkyWalking：http://www.iocoder.cn/categories/SkyWalking/

Zipkin：http://www.iocoder.cn/Zipkin/good-collection/

展望

由于本人接觸分布式鍊路追蹤時間不久，尚未了解它們各個的架構、網絡拓撲，後續個人補上，當然有興趣的小夥伴可以自行get。

本文章來源：https://github.com/Zeb-D/my-review