作者｜涯海
全鍊路追蹤的價值
鍊路追蹤的價值在于“關聯”，終端使用者、後端應用、雲端元件（資料庫、消息等）共同構成了鍊路追蹤的軌迹拓撲大圖。這張拓撲覆寫的範圍越廣，鍊路追蹤能夠發揮的價值就越大。而全鍊路追蹤就是覆寫全部關聯 IT 系統，能夠完整記錄使用者行為在系統間調用路徑與狀态的最佳實踐方案。
完整的全鍊路追蹤可以為業務帶來三大核心價值：端到端問題診斷，系統間依賴梳理，自定義标記透傳。
- 端到端問題診斷：VIP 客戶下單失敗，内測使用者請求逾時，許多終端使用者的體驗問題，追根溯源就是由于後端應用或雲端元件異常導緻的。而全鍊路追蹤是解決端到端問題最有效的手段，沒有之一。
- 系統間依賴梳理：新業務上線，老業務裁撤，機房搬遷/架構更新，IT 系統間的依賴關系錯綜複雜，已經超出了人工梳理的能力範疇，基于全鍊路追蹤的拓撲發現，使得上述場景決策更加靈活、可信。
- 自定義标記透傳：全鍊路壓測，使用者級灰階，訂單追溯，流量隔離。基于自定義标記的分級處理&資料關聯，已經衍生出了一個繁榮的全鍊路生态。然而，一旦發生資料斷鍊、标記丢失，也将引發不可預知的邏輯災難。
全鍊路追蹤的挑戰與方案
全鍊路追蹤的價值與覆寫的範圍成正比，它的挑戰也同樣如此。為了最大程度地確定鍊路完整性，無論是前端應用還是雲端元件，無論是 Java 語言還是 Go 語言，無論是公有雲還是自建機房，都需要遵循同一套鍊路規範，并實作資料互聯互通。多語言協定棧統一、前/後/雲（多）端關聯、跨雲資料融合是實作全鍊路追蹤的三大挑戰，如下圖所示：
1、多語言協定棧統一
在雲原生時代，多語言應用架構越來越普遍，利用不同語言特性，實作最佳的性能和研發體驗成為一種趨勢。但是，不同語言的成熟度差異，使得全鍊路追蹤無法做到完全的能力一緻。目前業界的主流做法是，先保證遠端調用協定層格式統一，多語言應用内部自行實作調用攔截與上下文透傳，這樣可以確定基礎的鍊路資料完整。
但是，絕大部分線上問題無法僅通過鍊路追蹤的基礎能力就能夠有效定位并解決，線上系統的複雜性決定了一款優秀的 Trace 産品必須提供更加全面、有效的資料診斷能力，比如代碼級診斷、記憶體分析、線程池分析、無損統計等等。充分利用不同語言提供的診斷接口，最大化的釋放多語言産品能力是 Trace 能夠不斷向前發展的基礎。
- 透傳協定标準化：全鍊路所有應用需要遵循同一套協定透傳标準，保證鍊路上下文在不同語言應用間能夠完整透傳，不會出現斷鍊或上下文缺失的問題。目前主流的開源透傳協定包括 Jaeger、SkyWalking、ZipKin 等。
- 最大化釋放多語言産品能力：鍊路追蹤除了最基礎的調用鍊功能外，逐漸衍生出了應用/服務監控，方法棧追蹤，性能剖析等高階能力。但是不同語言的成熟度導緻産品能力差異較大，比如 Java 探針可以基于 JVMTI 實作很多高階的邊緣側診斷。優秀的全鍊路追蹤方案會最大化的釋放每種語言的差異化技術紅利，而不是一味的追求趨同平庸。感興趣的同學可以閱讀之前這篇文章 《開源自建/托管與商業化自研 Trace，如何選擇》 。
2、前後雲（多）端關聯
目前開源的鍊路追蹤實作主要集中于後端業務應用層，在使用者終端和雲端元件（如雲資料庫）側缺乏有效的埋點手段。主要原因是後兩者通常由雲服務商或三方廠商提供服務，依賴于廠商對于開源的相容适配性是否友好。而業務方很難直接介入開發。
上述情況的直接影響是前端頁面響應慢，很難直接定位到後端哪個應用或服務導緻的，無法明确給出确定性的根因。同理，雲端元件的異常也難以直接與業務應用異常劃等号，特别是多個應用共享同一個資料庫執行個體等場景下，需要更加迂回的手段進行驗證，排查效率十分低下。
為了解決此類問題，首先需要雲服務商更好的支援開源鍊路标準，添加核心方法埋點，并支援開源協定棧透傳與資料回流（如阿裡雲 ARMS 前端監控支援 Jaeger 協定透傳與方法棧追蹤）。
其次，由于不同系統可能因為歸屬等問題，無法完成全鍊路協定棧統一，為了實作多端關聯，需要由 Trace 系統提供異構協定棧的打通方案。
異構協定棧打通
為了實作異構協定棧（Jaeger、SkyWalking、Zipkin）的打通，Trace 系統需要支援兩項能力：一是協定棧轉換與動态配置，比如前端向下透傳了 Jaeger 協定，新接入的下遊外部系統使用的則是 ZipKin B3 協定。在兩者之間的 Node.js 應用可以接收 Jaeger 協定并向下透傳 ZipKin 協定，保證全鍊路标記透傳完整性。二是服務端資料格式轉換，可以将上報的不同資料格式轉換成統一格式進行存儲，或者在查詢側進行相容。前者維護成本相對較小，後者相容性成本更高，但相對更靈活。
3、跨雲資料融合
很多大型企業，出于穩定性或資料安全等因素考慮，選擇了多雲部署，比如國内系統部署在阿裡雲，海外系統部署在 AWS 雲，涉及企業内部敏感資料的系統部署在自建機房等。多雲部署已經成為了一種典型的雲上部署架構，但是不同環境的網絡隔離，以及基礎設施的差異性，也為運維人員帶來了巨大的挑戰。
由于雲環境間僅能通過公網通信，為了實作多雲部署架構下的鍊路完整性，可以采用鍊路資料跨雲上報、跨雲查詢等方式。無論哪種方式，目标都是實作多雲資料統一可見，通過完整鍊路資料快速定位或分析問題。
跨雲上報
鍊路資料跨雲上報的實作難度相對較低，便于維護管理，是目前雲廠商采用的主流做法，比如阿裡雲 ARMS 就是通過跨雲資料上報實作的多雲資料融合。
跨雲上報的優點是部署成本低，一套服務端便于維護；缺點是跨雲傳輸會占用公網帶寬，公網流量費用和穩定性是重要限制條件。跨雲上報比較适合一主多從架構，絕大部分節點部署在一個雲環境内，其他雲/自建機房僅占少量業務流量，比如某企業 toC 業務部署在阿x雲，企業内部應用部署在自建機房，就比較适合跨雲上報的方式，如下圖所示。
跨雲查詢
跨雲查詢是指原始鍊路資料儲存在目前雲網絡内，将一次使用者查詢分别下發，再将查詢結果聚合進行統一處理，減少公網傳輸成本。
跨雲查詢的優點就是跨網傳輸資料量小，特别是鍊路資料的實際查詢量通常不到原始資料量的萬分之一，可以極大地節省公網帶寬。缺點是需要部署多個資料處理終端，不支援分位數、全局 TopN 等複雜計算。比較适合多主架構，簡單的鍊路拼接、max/min/avg 統計都可以支援。
跨雲查詢實作有兩種模式，一種是在雲網絡内部搭建一套集中式的資料處理終端，并通過内網專線打通使用者網絡，可以同時處理多個使用者的資料；另一種是為每個使用者單獨搭建一套 VPC 内的資料處理終端。前者維護成本低，容量彈性更大；後者資料隔離性更好。
其他方式
除了上述兩種方案，在實際應用中還可以采用混合模式或僅透傳模式。
混合模式是指将統計資料通過公網統一上報，進行集中處理（資料量小，精度要求高），而鍊路資料采用跨雲查詢方式進行檢索（資料量大，查詢頻率低）。
僅透傳模式是指每個雲環境之間僅保證鍊路上下文能夠完整透傳，鍊路資料的存儲與查詢獨立實作。這種模式的好處就是實作成本極低，每朵雲之間僅需要遵循同一套透傳協定，具體的實作方案可以完全獨立。通過同一個 TraceId 或應用名進行人工串聯，比較适合存量系統的快速融合，改造成本最小。
全鍊路追蹤接入實踐
前文詳細介紹了全鍊路追蹤在各種場景下面臨的挑戰與應對方案，接下來以阿裡雲 ARMS 為例，介紹一下如何從 0 到 1 建構一套貫穿前端、網關、服務端、容器和雲元件的完整可觀測系統。
- Header 透傳格式：統一采用 Jaeger 格式，Key 為 uber-trace-id， Value 為 {trace-id}:{span-id}:{parent-span-id}:{flags} 。
- 前端接入：可以采用 CDN（Script 注入）或 NPM 兩種低代碼接入方式，支援 Web/H5、Weex 和各類小程式場景。
- 後端接入：
-
- Java 應用推薦優先使用 ARMS Agent，無侵入式埋點無需代碼改造，支援邊緣診斷、無損統計、精準采樣等高階功能。使用者自定義方法可以通過 OpenTelemetry SDK 主動埋點。
- 非 Java 應用推薦通過 Jaeger 接入，并将資料上報至 ARMS Endpoint，ARMS 會相容多語言應用間的鍊路透傳與展示。
阿裡雲 ARMS 目前的全鍊路追蹤方案是基于 Jaeger 協定，正在開發 SkyWalking 協定，以便支援 SkyWalking 自建使用者的無損遷移。前端、Java 應用與非 Java 應用全鍊路追蹤的調用鍊效果如下圖所示：
1、前端接入實踐
ARMS 前端監控支援 Web/H5、Weex、支付寶和微信小程式等，本文以 Web 應用通過 CDN 方式接入 ARMS 前端監控為例，簡要說明接入流程，詳細接入指南參考 ARMS 前端監控官網文檔。
- 登入 ARMS 控制台，在左側導航欄中單擊接入中心，點選選擇前端 Web/H5 接入。
- 輸入應用名稱，點選建立；勾選SDK擴充配置項區域需要的選項，快捷生成待插入頁面的BI探針代碼。
- 選擇異步加載，複制下面代碼并粘貼至頁面HTML中** **元素内部的第一行，然後重新開機應用。
<script>
!(function(c,b,d,a){c[a]||(c[a]={});c[a].config={pid:"xxx",imgUrl:"https://arms-retcode.aliyuncs.com/r.png?",
enableLinkTrace: true, linkType: 'tracing'};
with(b)with(body)with(insertBefore(createElement("script"),firstChild))setAttribute("crossorigin","",src=d)
})(window,document,"https://retcode.alicdn.com/retcode/bl.js","__bl");
</script> 為了實作前後端鍊路打通，上述探針代碼中必須包含以下兩個參數：
- enableLinkTrace:true // 表示開啟前端鍊路追蹤功能
- linkType: 'tracing' // 表示生成 Jaeger 協定格式的鍊路資料，Hearder 允許 uber-trace-id 透傳
另外，如果 API 與目前應用非同源，還需要添加 enableApiCors: true 這個參數，并且後端伺服器也需要支援跨域請求及自定義header 值，詳情參考前後端鍊路關聯文檔。如需驗證前後端鍊路追蹤配置是否生效，可以打開控制台檢視對應 API 請求的 Request Headers 中是否有 uber-trace-id 這個辨別。
2、Java 應用接入實踐
Java 應用推薦接入 ARMS JavaAgent，無侵入式探針開箱即用，無需修改業務代碼，詳細接入指南參考 ARMS 應用監控官網文檔。
- 登入 ARMS 控制台，在左側導航欄中單擊接入中心，點選選擇後端 Java 接入。
- 根據需要選擇手動安裝、腳本安裝和容器服務安裝任意方式。
- 根據操作指南確定探針下載下傳并解壓至本地，正确配置 appName、LicenseKey 和 javaagent 啟動參數後，重新開機應用。
3、非 Java 應用接入實踐
非 Java 應用可以通過開源 SDK（比如 Jaeger）将資料上報至 ARMS 接入點，詳細接入指南參考 ARMS 應用監控官網文檔。
- 登入 ARMS 控制台，在左側導航欄中單擊接入中心，點選選擇後端 Go/C++/.NET/Node.js 等接入方式。
- 根據操作指南替換接入點 ，配置完成後重新開機應用。
全鍊路追蹤隻是開始，不是結束
從 2010 年谷歌發表 Dapper 論文開始，鍊路追蹤已經發展了十多年。但是關于鍊路追蹤的書籍或深度文章一直都比較少，大部分部落格隻是簡單介紹一些開源的概念或 QuickStart，一個大型企業如何建設一套真正可用、好用、易用的鍊路追蹤系統，需要填哪些坑，避哪些雷，很難找到比較系統、全面的答案。
全鍊路追蹤接入隻是 Tracing 的起點，選擇适合自身業務架構的方案，可以避免一些彎路。但鍊路追蹤不僅僅隻是看看調用鍊和服務監控，如何向上賦能業務，衍生至業務可觀測領域輔助業務決策？如何向下與基礎設施可觀測關聯，提前發現資源類風險？後面還有很多的工作要做，期待更多同學一起加入分享。
相關連結：
1、 ARMS 前端監控官網文檔：
https://help.aliyun.com/document_detail/106086.html?spm=ata.21736010.0.0.5d3a7f117o1Lty2、 前後端鍊路關聯文檔：
https://help.aliyun.com/document_detail/91409.html#title-6rx-0lb-p1o3、ARMS 應用監控官網文檔：
https://help.aliyun.com/document_detail/97924.html4、ARMS 應用監控官網文檔：
https://help.aliyun.com/document_detail/118912.html5、ARMS 控制台：
https://arms.console.aliyun.com/?spm=ata.21736010.0.0.5d3a7f117o1Lty點選下方連結，立即體驗鍊路追蹤！
https://www.aliyun.com/product/xtrace?spm=5176.8140086.J_8058803260.58.4da02c90QhBtVo快速分析和診斷分布式應用架構下的性能瓶頸，提高微服務時代下的開發診斷效率。
近期熱門
#極客時間小蓋對話 RocketMQ 技術負責人隆基#
掃描下圖二維碼預約直播
10 月 13 日(周三)晚上 20:00，直播間不見不散~