當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

全链路设计与实践

發(fā)布時間：2025/3/15 编程问答 56 豆豆

生活随笔收集整理的這篇文章主要介紹了全链路设计与实践小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

背景

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

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

設(shè)計目標(biāo)

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

實現(xiàn)功能

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

設(shè)計思路

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

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

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

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

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

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

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

技術(shù)選型

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

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

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

系統(tǒng)設(shè)計

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

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

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

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

目前支持的中間件有：

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

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

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

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è)務(wù)加載超時。

解決方案

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