背景

隨著公司業(yè)務的高速發(fā)展，公司服務之間的調(diào)用關(guān)系愈加復雜，如何理清并跟蹤它們之間的調(diào)用關(guān)系就顯的比較關(guān)鍵。線上每一個請求會經(jīng)過多個業(yè)務系統(tǒng)，并產(chǎn)生對各種緩存或者 DB 的訪問，但是這些分散的數(shù)據(jù)對于問題排查，或者流程優(yōu)化提供的幫助有限。在這樣復雜的業(yè)務場景下，業(yè)務流會經(jīng)過很多個微服務的處理和傳遞，我們難免會遇到這些問題:

• 一次請求的流量從哪個服務而來？ 最終落到了哪個服務中去？
• 為什么這個請求這么慢? 到底哪個環(huán)節(jié)出了問題?
• 這個操作需要依賴哪些東西? 是數(shù)據(jù)庫還是消息隊列? Redis掛了，哪些業(yè)務受影響?

設計目標

• 低消耗性：跟蹤系統(tǒng)對業(yè)務系統(tǒng)的影響應該做到足夠小。在一些高度優(yōu)化過的服務，即使一點點損耗也容易察覺到，而且有可能迫使在線負責的部署團隊不得不將跟蹤系統(tǒng)關(guān)停
• 低侵入性：作為非業(yè)務組件，應當盡可能少侵入或者無侵入業(yè)務系統(tǒng)，對于使用方透明，減少開發(fā)人員的負擔
• 時效性：從數(shù)據(jù)的收集產(chǎn)生，到數(shù)據(jù)計算處理，再到最終展現(xiàn)，都要求盡可能快
• 決策支持：這些數(shù)據(jù)是否能在決策支持層面發(fā)揮作用，特別是從 DevOps 的角度
• 數(shù)據(jù)可視化：做到不用看日志通過可視化進行篩選

實現(xiàn)功能

• 故障定位：調(diào)用鏈路跟蹤，一次請求的邏輯軌跡可以完整清晰的展示出來。
• 性能分析：調(diào)用鏈的各個環(huán)節(jié)分別添加調(diào)用耗時，可以分析出系統(tǒng)的性能瓶頸，并針對性的優(yōu)化。
• 數(shù)據(jù)分析：調(diào)用鏈是一條完整的業(yè)務日志，可以得到請求的行為路徑，匯總分析應用在很多業(yè)務場景

設計思路

對于上面那些問題，業(yè)內(nèi)已經(jīng)有了一些具體實踐和解決方案。通過調(diào)用鏈的方式，把一次請求調(diào)用過程完整的串聯(lián)起來，這樣就實現(xiàn)了對請求鏈路的監(jiān)控。

在業(yè)界，目前已知的分布式跟蹤系統(tǒng)，比如「Twitter Zipkin 與淘寶鷹眼」，設計思想都是來自 Google Dapper 的論文 「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」

典型分布式調(diào)用過程

圖1：這個路徑由用戶的X請求發(fā)起，穿過一個簡單的服務系統(tǒng)。用字母標識的節(jié)點代表分布式系統(tǒng)中的不同處理過程。

分布式服務的跟蹤系統(tǒng)需要記錄在一次特定的請求后系統(tǒng)中完成的所有工作的信息。舉個例子，圖1展現(xiàn)的是一個和5臺服務器相關(guān)的一個服務，包括：前端（A），兩個中間層（B和C），以及兩個后端（D和E）。當一個用戶（這個用例的發(fā)起人）發(fā)起一個請求時，首先到達前端，然后發(fā)送兩個 RPC 到服務器 B 和 C 。B 會馬上做出反應，但是 C 需要和后端的 D 和 E 交互之后再返還給 A ，由 A 來響應最初的請求。對于這樣一個請求，簡單實用的全鏈路跟蹤的實現(xiàn)，就是為服務器上每一次你發(fā)送和接收動作來收集與跟蹤

調(diào)用鏈路關(guān)系圖

cs - CLIENT_SEND，客戶端發(fā)起請求 sr - SERVER_RECIEVE，服務端收到請求 ss - SERVER_SEND，服務端處理完成，發(fā)送結(jié)果給客戶端 cr - CLIENT_RECIEVE，客戶端收到響應

技術(shù)選型

公司選項是否開源優(yōu)缺點

淘寶	EagleEye	否	主要基于內(nèi)部 HSF 實現(xiàn)，HSF 沒有開源，故鷹眼也沒有開源
Twitter	Zipkin	是	基于 Http 實現(xiàn)，支持語言較多，比較適合我們公司業(yè)務
點評	CAT	是	自定義改造難度大，代碼比較復雜，侵入代碼，需要埋點
京東	Hydra	是	主要基于 Dubbo 實現(xiàn)，不適合公司 Http 請求為主的場景

綜上，考慮到公司目前以 Http 請求為主的場景，最終決定采用參考 Zipkin 的實現(xiàn)思路，同時以 OpenTracing 標準來兼容多語言客戶端

系統(tǒng)設計

整體架構(gòu)圖及說明

一般全鏈路跟蹤系統(tǒng)主要有四個部分：數(shù)據(jù)埋點、數(shù)據(jù)傳輸、數(shù)據(jù)存儲、查詢界面

數(shù)據(jù)埋點

• 通過集成 SDK 到滬江統(tǒng)一開發(fā)框架中，進行低侵入性的數(shù)據(jù)收集
• 采用 AOP 切面方式，將收集的數(shù)據(jù)存儲在本地線程變量 ThreadLocal 中，對應用透明
• 數(shù)據(jù)記錄 TraceId、事件應用、接口、開始時間、耗時
• 數(shù)據(jù)采用異步線程隊列的方式發(fā)送到 Kafka 隊列中，減少對業(yè)務的影響

目前支持的中間件有：

• Http 中間件
• Mysql 中間件
• RabbitMQ 中間件

數(shù)據(jù)傳輸

我們在 SDK 與后端服務之間加了一層 Kafka ，這樣做既可以實現(xiàn)工程解耦，又可以實現(xiàn)數(shù)據(jù)的延遲消費，起到削峰填谷的作用。我們不希望因為瞬時 QPS 過高而導致數(shù)據(jù)丟失，當然為此也付出了一些實效性上的代價。

Kafka Manager 展示

數(shù)據(jù)存儲

數(shù)據(jù)存儲采用 ElasticSearch ，主要存儲 Span 與 Annotation 相關(guān)的數(shù)據(jù)，考慮到數(shù)據(jù)量的規(guī)模，先期只保存最近 1 個月的數(shù)據(jù)。

ELasticSearch Head 數(shù)據(jù)

查詢界面

通過可視化 Web 界面來查詢分布式調(diào)用鏈路，同時還提供根據(jù)項目維度分析依賴聚合

查詢頁面

Trace 樹

依賴分析

遇到的一些坑

Web 頁面加載超時

問題

使用 Zipkin 官網(wǎng) UI 的時候，會偶發(fā)性的出現(xiàn)業(yè)務加載超時。

解決方案

原因是 Zipkin 加載頁面的時候會一次性加載該項目里面所有的 Span ，當項目使用 Restful 形式的 API 時，就會產(chǎn)生幾百萬的 Span。最后，我們重寫 UI 頁面采用懶加載的方式，默認展示最近 10 條 Span，同時支持輸入字符來動態(tài)查詢 Span 的功能。

Span 堆積過多

問題

當使用頁面查詢 Trace 的時候，發(fā)現(xiàn)某個鏈路堆積到上千條 Span

解決方案

排查下來，業(yè)務方使用 HttpClient 中間件發(fā)送 Http 請求超時的時候，SDK 并未攔截超時對應的異常，導致事件一直在存儲在線程對應的 ThreadLocal 中

總結(jié)

全鏈路跟蹤系統(tǒng)關(guān)鍵點：調(diào)用鏈。

每次請求都生成全局唯一的 TraceID，通過該 ID 將不同的系統(tǒng)串聯(lián)起來。實現(xiàn)調(diào)用鏈跟蹤，路徑分析，幫助業(yè)務人員快速定位性能瓶頸，排查故障原因。

參考資料

• Google Dapper http://bigbully.github.io/Dapper-translation/
• Twitter Zipkin
• 窩窩網(wǎng) Tracing 文章 http://www.cnblogs.com/zhengyun_ustc/p/55solution2.html[]

轉(zhuǎn)載于:https://www.cnblogs.com/tylercao/p/8400275.html

總結(jié)

以上是生活随笔為你收集整理的全链路设计与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。