傳送門
Spring Cloud Alibaba系列之nacos：(1)安裝
Spring Cloud Alibaba系列之nacos：(2)單機模式支持mysql
Spring Cloud Alibaba系列之nacos：(3)服務注冊發現
Spring Cloud 系列之OpenFeign：(4)集成OpenFeign
Spring Cloud 系列之OpenFeign：(5)OpenFeign的高級用法
Spring Cloud 系列之OpenFeign：(6)OpenFeign的鏈路追蹤
關于鏈路追蹤
?在前面一節Spring Cloud 系列之OpenFeign：(6)OpenFeign的鏈路追蹤中，通過MDC實現了一個簡易的鏈路追蹤服務：
?
里面對于鏈接追蹤沒有過多的討論，所以這里還是要先對它是什么，有什么作用，常用實現方式再做一次探討！
為什么需要鏈路追蹤
鏈路追蹤這個名詞也是17年初的時候才接觸，當時入職一家做互聯網金融的公司（以前都是在傳統軟件公司做企業級金融系統開發）。公司據說不久前融資了一筆錢，招兵買馬準備大干一場。那時候公司在推行微服務，框架就是Spring Cloud套件，也就接觸了zipkin這個概念，當時很經過一番名詞轟炸，還是帶來了不小的震撼：微服務，Springboot，注冊中心Eureka，配置中心Config，網關Zuul，斷路器，負載Ribbon，以及鏈路追蹤的Sleuth（Springboot3已經被Micrometer Tracing項目取代）甚至是JAVA8的Lambda，還入手了一本翟永超的《Spring Cloud微服務實戰》。
?被名詞轟炸的一個背后原因是在開發toB系統的那些年，系統基本都是單體的，所有的功能都在一個項目代碼里面，包括前端/后端（那時候也不流行前后端分離）：
- 銀行/機構的大部分管理系統（甚至核心系統）都是內網專線，即所謂的私部署，不像toC這樣面對互聯網開放
- toB的系統并發雖然業務相對復雜，但并發不高，對分布式沒有強烈的需求
- 最后一點，不一味追求新技術，穩定成熟才是首要考慮需求
在單體系統時代出了問題或者要排查問題，基本在本系統排查就夠了，一般不超出關聯上下游2-3個系統：
- 查詢本系統的相關日志即可，排查比較方便，內容項也不多：應用日志/數據庫
- 或者人肉聯系上下游系統相關負責人去查下，范圍也不擴大
但是在分布式系統架構下，這個方式就有點困難了：
- 隨著系統的調用鏈路變長依賴系統增多，查詢日志就顯得不那么容易了：幾個十幾個系統要逐個排查日志，可能每個系統的日志規范還不一樣，中間要是哪個漏了還查不出來，難以定位
- 微服務架構下，多半組織架構也不一樣了：會按照微服務來劃分不同的開發團隊，溝通成本幾何增加，要是每個問題都人肉拉群處理，那很快就大家不用干活了
所以分布式系統架構對于統一的服務調用請求追蹤就顯示很有必要了：一個鏈路追蹤需要達到至少2方面的要求：
- 從調用過程角度看：從客戶端發起請求開始，記錄請求流經的每一個服務，直到向客戶端返回響應為止
- 從記錄過程角度看：能夠記錄具體調用了哪些服務，以及調用的順序、開始時點、執行時長等信息
)
