Trace 的由來

Trace 并不是一個新的概念，隨著軟件商業化伊始，如何迅速定位生產環境是工程師們不斷探索的方向。早期的軟件架構大多為 CS 結構（Client and Server）。每個語言為了提供方便快捷的方式讓工程師解決問題，在 Log，Debug 和 Trace 上一直沒少下功夫。

大家最熟悉的 Java 代碼里 printStackTrace() 就是標準的追蹤邏輯，把調用關系和順序整理的明明白白。隨著 SOA（Service Oriented Architecture）的普及，標準化的服務間交互機制逐步建立起來，但大多數的應用還是跑在單體結構上，所以對于追蹤和排障并沒有帶來巨大的變化。

緊接著發生的互聯網的興起和流量的幾何級數暴增，服務之間的解耦，模塊獨立擴展性和業務團隊的組織結構的變化，讓軟件體系結構發生了本質變化。打散了原有的單體應用，微服務幾乎成為剛需。微服務的構架形態打亂了原本向對簡單的在單體開發下的鏈路追蹤和排障邏輯。

在這個背景下，分布式鏈路追蹤應運而生成為了大部分公司業務監控和故障定位的強需求。這里就引出了我們下面要討論的話題，也是目前業界最火的鏈路追蹤項目之一的 OpenTelemetry。

要說 OpenTelemetry 的故事，我們還要回顧一下過去5年的一些重要事件。

2016年的12月25日圣誕節，OpenTracing 發布了1.0的版本，提供了面向 Tracing 的規范用于兼容微服務調用之間不同平臺的中立 API，之后的2年里，各種外部組件，各種語言，各種框架，不斷的貢獻到了 OpenTracing 的生態里來，OpenTracing 也成為了 CNCF incubating 的項目。

看起來如此符合主流需求的項目卻在2018年受到了來自谷歌的挑戰。2018年的1月17日，谷歌發布 OpenCencus（微軟在2018年6月加入） ，作為一款獨立于廠商的，面向微服務架構的性能采集和鏈路追蹤平臺。

從定位上來說，OpenCencus 不僅僅提供 Tracing 標準和 API 規范，還自集成了性能采集的組建，目標是打造一個集性能監控和鏈路追蹤為一體的方案。而在生態上，OpenCensus 直接提供了大部分語言所對應的 SDK 和普遍使用的 Framework 的支持。從此開始，業界對于到底使用 OpenTracing 還是 OpenCensus 開始了一輪又一輪的討論。

終于在2019年的5月21日，一條來自谷歌的官方聲明傳來，OpenCensus 和 OpenTracing 被并入到新的 CNCF 項目，新項目的名字叫OpenTelemetry。而 OpenTelemetry 不僅僅做 Tracing，Metrics，還要針對 Logging 實現類似的中立解決方案，這個方案基本上吃下了排障流程的上中下游，致力于打造全方位的排障定位的規范。

目前 OpenTelemetry 是 CNCF 旗下的 SandBox 項目，同在 SandBox 下的比較有特色的幾個項目包括 Chaos Mesh，Cert Manager 和 K3s。OpenTelemetry 對于 OpenTracing 和 OpenCensus 是全面兼容的，會制定出更加全面的規范，并且很多規范會貢獻到類似于 W3C 當中去。

當前，業界最火熱的幾個鏈路追蹤社區，如 Apache SkyWalking，Zipkin，Jaeger 都是基于 OpenTracing 發展起來的，也有逐步向 OpenTelemetry 拓展的趨勢。這些開源組建一般都是從客戶端接入開始，同時提供數據收集的方案（Data Collector）和數據處理的方案（Data Aggregator），最后把數據倒入到其他開源組建中，比如 Elasticsearch 和 Cassandra 等。對于大部分需要使用的客戶來說，自建其實是比較麻煩的事情。比如 Jaeger 提供的實例構架圖如下：

圖一

為了達到一個理想的效果，這里需要客戶自建的東西太多了，Kafka/ Flink/ DB/ Jaeger 組建。所以客戶在大部分場景下希望云廠商提供一站式的服務，而不是讓客戶自己去拼裝整個方案。

下面我們用騰訊云提供的TSW（Tencent Service Watcher）組建舉例，看看云上大廠們是如何幫助客戶接入 OpenTracing 和 OpenTelemetry 生態和方案的。

基于 OpenTracing 的云上鏈路追蹤基礎設施 TSW

TSW 是 Tencent Service Watcher 的簡寫。是騰訊云提供的分布式全鏈路追蹤的解決方案。TSW 的設計理念是擁抱開源和提供全鏈路解決問題的能力。

這里我們先談一下擁抱開源，當前 OpenTelemtry 還處于 SandBox 項目階段，所以 TSW 當前的數據協議是基于 OpenTracing 來設計的，全面兼容 Apache Skywalking，Zipkin 和 Jaeger 的客戶端上報，為微服務體系的客戶端 Tracing 上報選型提供的極大的便利。

隨著 OpenTelemetry 的逐漸成熟，全面兼容 OpenTelemetry 的數據類型和功能也已經在 TSW 的排期中。這種設計為那些在十字路口徘徊的公司提供了最大的便利，不需要考慮客戶端未來的兼容問題。而完全自研的后端體系，借鑒了 Jaeger 和 Skywalking 的設計，使用計算存儲分離和多層查詢的機制，提供了非常優秀的性能輸出。

圖二

除了提供鏈路拓撲的靈活視圖和和調用鏈路的查詢分析機制，TSW 還針對服務調用的上下游關系做了深度聚合，可以更直觀的切分和對比同一調用在不同鏈路下的成功率和響應。

圖四

為了提供給研發團隊最大的排障便利，TSW 目前在和云監控和日志服務做深度整合，未來會提供一站式的排障工作體驗，避免了一個問題開多個頁面的困擾和搜索不斷要復制黏貼關鍵詞的麻煩，旨在打造云上排障的一站式工作站。