概述
首先同步下項目概況：
上篇文章分享了，路由中間件 - 捕獲異常，這篇文章咱們分享：路由中間件 - 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：https://www.jaegertracing.io
- Zipkin：https://zipkin.io/
- Appdash：https://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 還沒寫完...
下篇文章再給大家分享。
源碼地址
https://github.com/xinliangno...
