分散式鏈路追蹤系統深入理解
背景
對於普通系統或者服務來說，一般通過打日誌來進行埋點，然後再通過elk進行定位及分析問題，更有甚者直接遠端伺服器，使用各種linux命令單手操作檢視日誌，說到這，我也沒擺脫這種困境。那麼隨著業務越來越複雜，企業應用也進入了分散式服務化的階段，傳統的日誌監控等方式無法很好達到跟蹤呼叫，排查問題等需求。
總之，在各種服務之間呼叫：
- 如何快速發現問題？
- 如何判斷故障影響範圍？
- 如何梳理服務依賴以及依賴的合理性？
- 如何分析鏈路效能問題以及實時容量規劃？
如何在分散式服務進行日誌監控呢？首先大家會想到分散式鏈路追蹤系統，說到這，就得講 OpenTracing 規範，OpenTracing 是一個輕量級的標準化層，它位於應用程式/類庫和追蹤或日誌分析程式之間。詳細介紹見
在谷歌論文《 Dapper，大規模分散式系統的跟蹤系統》的指導下，許多優秀的APM應運而生。分散式追蹤系統發展很快，種類繁多，給我們帶來很大的方便。但在資料採集過程中，有時需要侵入使用者程式碼，並且不同系統的 API 並不相容，這就導致瞭如果您希望切換追蹤系統，往往會帶來較大改動。OpenTracing為了解決不同的分散式追蹤系統 API 不相容的問題。
技術調研指標
面對各種鏈式追蹤系統開源，我們要如何選擇：
我們主要關注在請求處理期間各個呼叫的各項效能指標，比如：吞吐量（TPS）、響應時間及錯誤記錄等。
- 吞吐量，根據拓撲可計算相應元件、平臺、物理裝置的實時吞吐量。
- 響應時間，包括整體呼叫的響應時間和各個服務的響應時間等。
- 錯誤記錄，根據服務返回統計單位時間異常次數。
全鏈路效能監控 從整體維度到區域性維度展示各項指標，將跨應用的所有呼叫鏈效能資訊集中展現，可方便度量整體和區域性效能，並且方便找到故障產生的源頭，生產上可極大縮短故障排除時間。
我們除了效能指標之外，我們也需要鏈式追蹤系統擁有以下功能：
- 請求鏈路追蹤，故障快速定位：可以通過呼叫鏈結合業務日誌快速定位錯誤資訊。
- 視覺化： 各個階段耗時，進行效能分析。
- 依賴優化：各個呼叫環節的可用性、梳理服務依賴關係以及優化。
- 資料分析，優化鏈路：可以得到使用者的行為路徑，彙總分析應用在很多業務場景。
當然這些要求可能有些過分了，但我們換著自己的目標進行技術選型。
接下來我們主要來介紹四種常見的開源鏈式追蹤系統，除了一些背景、所使用技術棧、支援的技術棧，我們還需要深入程式碼層面進行分析等等
瞭解鏈式追蹤系統
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
深入分析技術目標要求
1、探針的效能消耗
APM元件服務的影響應該做到足夠小。服務呼叫埋點本身會帶來效能損耗，這就需要呼叫跟蹤的低損耗，實際中還會通過配置取樣率的方式，選擇一部分請求去分析請求路徑。在一些高度優化過的服務，即使一點點損耗也會很容易察覺到，而且有可能迫使線上服務的部署團隊不得不將跟蹤系統關停。
2、程式碼的侵入性
即也作為業務元件，應當儘可能少入侵或者無入侵其他業務系統，對於使用方透明，減少開發人員的負擔。
對於應用的程式設計師來說，是不需要知道有跟蹤系統這回事的。如果一個跟蹤系統想生效，就必須需要依賴應用的開發者主動配合，那麼這個跟蹤系統也太脆弱了，往往由於跟蹤系統在應用中植入程式碼的bug或疏忽導致應用出問題，這樣才是無法滿足對跟蹤系統“無所不在的部署”這個需求。
3、可擴充套件性
一個優秀的呼叫跟蹤系統必須支援分散式部署，具備良好的可擴充套件性。能夠支援的元件越多當然越好。或者提供便捷的外掛開發API，對於一些沒有監控到的元件，應用開發者也可以自行擴充套件。
4、資料的分析
資料的分析要快 ，分析的維度儘可能多。跟蹤系統能提供足夠快的資訊反饋，就可以對生產環境下的異常狀況做出快速反應。分析的全面，能夠避免二次開發。
功能要求
1、埋點與生成日誌
埋點即系統在當前節點的上下文資訊，可以分為 客戶端埋點、服務端埋點，以及客戶端和服務端雙向型埋點。埋點日誌通常要包含以下內容traceId、spanId、呼叫的開始時間，協議型別、呼叫方ip和埠，請求的服務名、呼叫耗時，呼叫結果，異常資訊等，同時預留可擴充套件欄位，為下一步擴充套件做準備；
不能造成效能負擔：一個價值未被驗證，卻會影響效能的東西，是很難在公司推廣的！
因為要寫log，業務QPS越高，效能影響越重。通過取樣和非同步log解決。
2、收集和儲存日誌
主要支援分散式日誌採集的方案，同時增加MQ作為緩衝；
- 每個機器上有一個 deamon 做日誌收集，業務程序把自己的Trace發到daemon，daemon把收集Trace往上一級傳送；
- 多級的collector，類似pub/sub架構，可以負載均衡；
- 對聚合的資料進行 實時分析和離線儲存；
- 離線分析 需要將同一條呼叫鏈的日誌彙總在一起；
3、分析和統計呼叫鏈路資料，以及時效性
呼叫鏈跟蹤分析：把同一TraceID的Span收集起來，按時間排序就是timeline。把ParentID串起來就是呼叫棧。
拋異常或者超時，在日誌裡列印TraceID。利用TraceID查詢呼叫鏈情況，定位問題。
依賴度量：
- 強依賴：呼叫失敗會直接中斷主流程
- 高度依賴：一次鏈路中呼叫某個依賴的機率高
- 頻繁依賴：一次鏈路呼叫同一個依賴的次數多
離線分析：按TraceID彙總，通過Span的ID和ParentID還原呼叫關係，分析鏈路形態。
實時分析：對單條日誌直接分析，不做彙總，重組。得到當前QPS，延遲。
4、展現以及決策支援
四種系統對比
模擬了三種併發使用者：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，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新版本的反映情況較少依賴較多。 |
| 文件 | 網上資料較少，僅官網提供的文件，比較亂 | 文件完善 | 文件完善 | 文件完善 |
| 開發者 | 大眾點評 | naver | 吳晟（華為開發者） ，目前已經加入Apache孵化器 | |
| 使用公司 | 大眾點評， 攜程， 陸金所，同程旅遊，獵聘網 | naver | 華為軟體開發雲、天源迪科、噹噹網、京東金融 |
技術原始碼分析
展望
由於本人接觸分散式鏈路追蹤時間不久，尚未理解它們各個的架構、網路拓撲，後續個人補上，當然有興趣的小夥伴可以自行get。