[系列] - go-gin-api 路由中間件 - Jaeger 鏈路追蹤（五）

概述

首先同步下項目概況：

上篇文章分享了，路由中間件 - 捕獲異常，這篇文章我們分享：路由中間件 - Jaeger 鏈路追蹤。

啥是鏈路追蹤？

我理解鏈路追蹤實際上是爲微服務架構提供服務的，當一個請求中，請求了多個服務單元，若是請求出現了錯誤或異常，很難去定位是哪一個服務出了問題，這時就須要鏈路追蹤。

我們先看一張圖：

這張圖的調用鏈還比較清晰，我們想象一下，隨着服務的愈來愈多，服務與服務之間調用關係也愈來愈多，可能就會發展成下圖的狀況。

這調用關係真的是... 看到這，個人心裏是崩潰的。

那麼問題來了，這種狀況下怎麼快速定位問題？

如何設計日誌記錄？

咱們本身也能夠設計一個鏈路追蹤，好比當發生一個請求，我們記錄它的：

• 請求的惟一標識
• 請求了哪些服務？
• 請求的服務依次順序？
• 請求的 Request 和 Response 日誌？
• 對日誌進行收集、整理，並友好展現

怎麼去實現請求的惟一標識？

以 Go 爲例 寫一箇中間件，在每次請求的 Header 中包含：X-Request-Id，代碼以下：

func SetUp() gin.HandlerFunc {
	return func(c *gin.Context) {
		requestId := c.Request.Header.Get("X-Request-Id")
		if requestId == "" {
			requestId = util.GenUUID()
		}
		c.Set("X-Request-Id", requestId)
		c.Writer.Header().Set("X-Request-Id", requestId)
		c.Next()
	}
}
複製代碼

每一個 Request 和 Response 日誌中都要包含 X-Request-Id。

問題又來了，每次調用都記錄日誌，當調用的服務過多時，頻繁的記錄日誌，就會有性能問題呀，腫麼辦？

哎，這麼麻煩，看看市面上有沒有一些開源工具呢？

開源工具

• Jaeger：www.jaegertracing.io
• Zipkin：zipkin.io/
• Appdash：about.sourcegraph.com/

這個就很少作介紹了，基本上都能知足需求，至於優缺點，你們能夠挨個去瞅瞅，喜歡哪一個就用哪一個？

我爲何選擇 Jaeger ？

由於我目前只會用這個，其餘還不會 ...

我們一塊兒看下 Jaeger 是怎麼回事吧。

Jaeger 架構圖

圖片來源於官網。

簡單介紹下上圖三個關鍵組件：

Agent

Agent是一個網絡守護進程，監聽經過UDP發送過來的Span，它會將其批量發送給collector。按照設計，Agent要被部署到全部主機上，做爲基礎設施。Agent將collector和客戶端之間的路由與發現機制抽象了出來。

Collector

Collector從Jaeger Agent接收Trace，並經過一個處理管道對其進行處理。目前的管道會校驗Trace、創建索引、執行轉換並最終進行存儲。存儲是一個可插入的組件，如今支持Cassandra和elasticsearch。

Query

Query服務會從存儲中檢索Trace並經過UI界面進行展示，該UI界面經過React技術實現，其頁面UI以下圖所示，展示了一條Trace的詳細信息。

其餘組件，你們能夠了解下並選擇性使用。

Jaeger Span

圖片來源於官網。

怎麼操做 Span 呢？Span 有哪些能夠調用的 API ？

Jaeger 部署

All in one

爲了方便你們快速使用，Jaeger 直接提供一個 All in one 包，咱們能夠直接執行，啓動一套完整的 Jaeger tracing 系統。

啓動成功後，訪問 http://localhost:16686 就能夠看到 Jaeger UI。

獨立部署

• jaeger-agent
• jaeger-collector
• jaeger-query
• jaeger-ingester
• jaeger-operator
• jaeger-cassandra-schema
• jaeger-es-index-cleaner
• spark-dependencies

能夠自由搭配，組合使用。

Jaeger 端口

• 端口：6831

• 協議：UDP

• 所屬模塊：Agent

• 功能：經過兼容性 Thrift 協議，接收 Jaeger thrift 類型數據

• 端口：14267

• 協議：HTTP

• 所屬模塊：Collector

• 功能：接收客戶端 Jaeger thrift 類型數據

• 端口：16686

• 協議：HTTP

• 所屬模塊：Query

• 功能：客戶端前端界面展現端口

Jaeger 採樣率

分佈式追蹤系統自己也會形成必定的性能低損耗，若是完整記錄每次請求，對於生產環境可能會有極大的性能損耗，通常須要進行採樣設置。

固定採樣

（sampler.type=const）

• sampler.param=1 全採樣，
• sampler.param=0 不採樣；

按百分比採樣

（sampler.type=probabilistic）

• sampler.param=0.1 則隨機採十分之一的樣本；

採樣速度限制

（sampler.type=ratelimiting）

• sampler.param=2.0 每秒採樣兩個traces；

動態獲取採樣率

（sampler.type=remote）

• 這個是默認配置，能夠經過配置從 Agent 中獲取採樣率的動態設置。

Jaeger 缺點

• 接入過程有必定的侵入性；
• 自己缺乏監控和報警機制，須要結合第三方工具來實現，好比配合Grafana 和 Prometheus實現；

看到這，說的都是理論，你們的內心話多是：

實戰

• Jaeger 部署
• Jaeger 在 Gin 中使用
• Jaeger 在 gRPC 中使用

關於實戰的分享，我準備整理出 4 個服務，而後實現服務與服務之間進行相互調用，目前 Demo 還沒寫完...

下篇文章再給你們分享。

源碼地址

github.com/xinliangnot…

go-gin-api 系列文章

• 1. 使用 go modules 初始化項目
• 2. 規劃項目目錄和參數驗證
• 3. 路由中間件 - 日誌記錄
• 4. 路由中間件 - 捕獲異常