現代微服務架構由於業務系統模型日趨複雜，分佈式系統中需要一套鏈路追蹤系統來幫助我們理解系統行爲，明確服務間調用。最近作者請到了 Zipkin 項目的主要開發維護人員 Adrian Cole 來介紹有關 Zipkin 項目的細節內容，可以讓大家瞭解到如何在分佈式追蹤系統中用好 Zipkin。
Adrian 一直在從事雲計算相關開源項目的開發，是開源項目 Apache jclouds 和 OpenFeign 的創始人。最近幾年，他專注於分佈式跟蹤領域，是 OpenZipkin 項目的主要開發維護人員。Adrian 目前在 Pivotal Spring Cloud OSS 團隊工作。在加入 Pivotal 之前，他還在 Twitter，Square，Netflix 工作過。
總所周知 Zipkin 項目起源於 Twitter， 您能給我們介紹一下項目的相關背景嗎？
Adrian：Zipkin 是由 Twitter 內部構建的分佈式追蹤項目，於 2012 年開源。它最初被稱爲 BigBrotherBird，因此即使在今天，http 標頭也被命名爲“B3”。Twitter 早期因爲業務發展迅猛，經常會出現系統過載情況。每當出現這種情況時，用戶會看到一條擱淺的鯨魚顯示在頁面上。Zipkin 這個名字也與鯨魚有關，因爲 Zipkin 是魚叉的意思，構建初衷是爲了追蹤“擱淺的鯨魚”相關的系統延遲問題。Zipkin 的成功除了和 Twitter 的的品牌加持有關，其他因素也起到很大作用：一是 Zipkin 包含了客戶端、服務器、用戶界面等所有你需要的部分；此外，Twitter Engineering 上一篇介紹 Zipkin 的博客也引起了轟動。隨着時間的推移，Zipkin 成爲了數十種可觀察性工具之一。
分佈式調用追蹤對微服務監控有什麼價值，爲什麼大家要爲微服務建這樣的追蹤系統？
Adrian：這裏我想引用 Netflix 的局點文檔（Zipkin 的用戶使用報告）中的描述來總結分佈式追蹤系統的價值：
其商業價值在於爲系統提供了一個操作層面的可視化界面，同時提升開發人員的生產效率。
對於微服務系統來說，如果沒有分佈式追蹤工具的幫助，要了解各個服務之間的調用關係是相當困難的。即使對於非常資深的工程師來說，如果只依靠追蹤日誌，分析系統監控信息，也是很難快速定位和發現微服務系統問題的。分佈式調用追蹤系統可以幫助開發人員或系統運維人員及時瞭解應用程序及其底層服務的執行情況，以識別和解決性能問題或者是發現錯誤的根本原因。分佈式追蹤系統可以在請求通過應用系統時提供端到端的視圖，並顯示應用程序底層組件相關調用關係，從而幫助開發人員分析和調試生產環境下的分佈式應用程序。
在業界已經大量採用微服務架構的今天，Zipkin 在工業界微服務系統問題追蹤方面扮演了很重要的角色，您能給我們介紹一下業界是如何使用 Zipkin 項目的嗎？
Adrian：在回答這個問題之前，我們先簡單介紹一下 Zipkin 的系統架構。Zipkin 包含了前端收集以及後臺存儲展示兩部分。爲了追蹤應用的調用情況，我們需要在應用內部設置相關的追蹤器來記錄調用執行的時間以及調用操作相關的元數據信息。一般來說這些追蹤器都是植入到應用框架內部的，用戶應用程序基本感知不到它的存在。如下圖所示當被監控的客戶端向被監控的服務器端發送消息時，被監控客戶端和被監控服務器端的追蹤器會分別生成一個叫做 Span 的信息通過報告器（Report）發送到 Zipkin 後臺。一次跨多個服務的調用會包含多個 Span 信息，這些 Span 信息是通過客戶端與服務器之間傳輸的消息頭進行關聯的。 後臺會通過收集器（collector）接收 Span 消息，並進行相關分析關聯，然後將數據通過存儲模塊存儲起來供 UI 展示。
Zipkin 在項目開源之初就包含了一個完整的追蹤解決方案方便大家上手，同時通過傳輸協議以及相關消息頭開源，幫助 Zipkin 很容集地成到用戶的監控系統中。這讓 Zipkin 能夠在衆多的追蹤系統中脫穎而出，成爲工業界最常用的追蹤工具。
在 2015 年的時候我們發現不是所有人都有分佈調用追蹤的系統使用經驗，他們不太瞭解如何成功搭建分佈式追蹤系統。因此我們整理了很多業界使用 Zipkin 的相關資料，並在 Google Drive 上創建了相關文檔目錄存放這些資料。考慮到大家訪問 Google Drive 可能會不太方便，後來我們創建了 wiki 來分享如何使用 Zipkin，讓更多人瞭解其他人是如何使用 Zipkin 來解決追蹤系統中存在的問題的。
在這裏你可以看到像 Netflix 這樣的大廠是如何使用 Zipkin 以及 Elasticsearch 處理每天高達 5TB 的追蹤數據，Ascend Money 是如何將公有云和私有云結合在一起使用 Zipkin，Line 是如何將 Zipkin 與 armeria 結合進行異步調用追蹤的，以及 Sound Cloud 是如何結合 Kubernetes Pod 的元數據信息改善 Zipkin 追蹤的。這裏我們也歡迎更多的中國用戶能夠在此分享你們使用 Zipkin 的經驗。
對了，如果你是 Zipkin 用戶, 記着給我們的代碼倉庫加星，這是對我們最大的鼓勵。
我們知道 Zipkin 項目目前在生產環境中大量使用，他們是直接使用這些項目還是依據自己的需要對項目進行了相關的修改？
Adrian：因爲 Zipkin 項目運作是建立在用戶吃自己的狗糧 (使用自己開發的軟件）的基礎上， 很多新工具都是先在用戶內部使用，然後開源變成通用項目。例如 zipkin-forwarder 這個項目就是 Ascend 結合自己的業務需要實現的跨多個數據中心轉發數據實驗性項目。Yelp 實現了一個 Zipkin 代理用來讀取多個 Zipkin 集羣的數據。LINE 在內部開發了一個代號爲“project lens”的項目來替換 Zipkin UI。
現在 Zipkin 的使用案例很多，不同使用案例對應的架構也不相同。這並不是說用戶沒有直接採用 OpenZipkin 組織下面的項目。例如 Mediata 就在他們的局點文檔中描述了他們直接使用 Zipkin 的發行版，沒有進行任何修改。
Zipkin 項目缺省是支持中等規模的使用場景， 爲了支持更大規模的使用場景，我們需要做些什麼？
Adrian：大規模的使用場景意味着更多的數據量，大規模用戶通常會從成本以及處理或清理數據的能力來考慮這個問題。例如，SoundCloud 實現了基於 kubernetes 元數據清理數據的工具。以往幾乎所有 Zipkin 大型局點都將追蹤數據存儲在 Cassandra。現在，Netflix 等大型局點採用 Elasticsearch 也能取得成功。 幾乎所有大型局點都使用 Kafka 來進行更大的數據傳輸。出於效率的原因，較小的站點會採用不同的傳輸方式。例如，Infostellar 使用 Armeria （一個類似於 gRPC 的異步效 RPC 庫）來傳輸數據。
大多數成熟局點也會擔心數據大小而使用採樣的方式來解決問題。因爲我們很難爲不同類型的局點設計一個通用工具，Zipkin 爲大家提供了多種採樣選擇，其中包括基於 http 請求的表達式來進行配置，也有新的開發客戶端速率限制採樣器。例如，使用 Spring 的局點有時會使用配置服務器實時推送採樣率。這樣可以在不干擾通常的低採樣率的情況下抓取有趣的痕跡。
大多數局點使用客戶端採樣來避免啓動無用的跟蹤。例如，spring cloud sleuth 的默認策略不會爲健康檢查等管理流量創建跟蹤。這些是通過 http 路徑表達式完成的。一些基於百分比的採樣（例如 1％或更少的流量）在數據激增時仍然存在問題。即使採樣率爲 1％，當流量達到 1000％的時候也可能會出現問題。因此，我們始終建議對系統進行冗餘配置，也就是說不僅要爲正常流量分配帶寬和存儲空間，還要提供一定的餘量。但這不是一個最好的解決方案，我們開玩笑的將其稱爲 OPP （over-provision and pray，美國流行歌曲名），通過冗餘保障還有祈禱來幫我們應對數據激增的問題。
值得注意的是許多局點站並不打算“演進”到自適應（自動）採樣。例如，Yelp 在定製的無索引的廉價存儲中進行 100％的數據消費。這樣可以在不干擾通常的低採樣率的情況下直接抓取有趣的痕跡。在 Zipkin 社區中有相關自適應採樣配置的設計討論，以突出問題區域而不會增加基本採樣率的複雜性。自適應是一個有趣的選擇，絕對可以應對數據激增問題，但大家通常會用不同的方法來實現自適應。
目前 Zipkin 在線局點日常處理 span 的數據流大概是多少？ Zipkin 缺省能支持存儲一個月的數據嗎？在 Zipkin 的存儲方面你有什麼好的建議？
Adrian：Yelp 處理的 Span 數據可能是最多的，因爲它們會將 100％的數據集中到專用存儲羣集中。但是他們也沒有公佈數字。Netflix 的系統大約會將 240 MB / 秒的 span 數據推送到後臺（大家可以算算這裏有多少條 span 信息），一般來說一條 Span 數據通常不會超過 1KiB，甚至遠遠低於 1KiB。
關於數據存儲，大多數網站出於成本的考慮只保留數天的數據。不過有些用戶自己提供“最喜歡的追蹤”功能來長時間保留追蹤數據。關於 Span 大小，我們建議大家使用 brave 或 zipkin-go 等工具中自帶的默認值，然後根據大家的具體需求添加一些數據標籤（決定是否保留數據）來提升資源利用率。
我們也不建議把 span 作爲日誌記錄器。 OpenTracing 開了這個壞頭，他們把日誌工具和分佈式追蹤 API 相混淆，甚至在 Span 中的 API 定義了“microlog”。據我所知沒有一個追蹤系統能在系統內部把常規日誌記錄工作做得很好的，因爲追蹤系統和常規日誌記錄系統是兩個完全不同的系統， 這樣做只會損害追蹤系統運行效率。
我們建議大家根據自己的需要選擇最佳的存儲方式。 例如，Infostellar 直接將追蹤數據轉發到 Google Stackdriver 上進行存儲。 如果你更熟悉 Elasticsearch 而不是 Cassandra，那麼請使用 Elasticsearch，反之亦然。 但是我們建議大家不要使用 MySQL，因爲我們的 MySQL 架構不是爲了高性能而編寫的。
Zipkin 是如何對接分析系統（如 Amazon X-Ray, Apache SkyWalking 以及 Expedia HayStack）的？對此你有什麼好的建議？
Adrian：你提到的所有項目都是通過接收 Zipkin 數據實現集成的，Infostellar 在這方面有比較好的網站文檔可以參考。
Skywalking 也提供了接入 Zipkin 數據的集成方式。 Skywalking 可以接受 Zipkin 格式的數據，這樣無論是 Zipkin 的探針，還是其他工具，如 Jaeger，只要使用相同格式的工具都可以接入到 Skywalking 中。需要指出的是現在很多追蹤工具都支持 Zipkin 格式，通過支持 Zipkin 格式可以很容易完成對其他追蹤系統的集成工作。
我對 Haystack 與 Zipkin 集成工作的有一定的瞭解。他們通過 Hotels.com 提供的 Pitchfork 這個工具，將數據分別發送給 Zipkin 和 Haystack。Haystack 的系統可以對 Zipkin 數據進行服務圖聚合等處理，這樣就不需要使用 Zipkin 的 UI 來處理數據了。
OpenZipkin 是什麼？這些年 Zipkin 社區是怎麼發展起來的？如何加入到 Zipkin 社區中？
Adrian：2015 年，社區有人呼籲把項目遷移到一個更開放的地方，以便更快地發展項目。我們經過三個月的努力，於 2015 年 7 月在 Github 上成立了“OpenZipkin”小組。社區在此之後快速發展，大量用戶在社區中交流他們在構建分佈式追蹤系統所遇到的問題和挑戰。當社區決定把首選語言定爲 Java 而不是 Scala 後，我們重新編寫了服務器。我們有許多示例項目幫助大家上手，而且我們認爲與他人交流是最好的學習方式。如果你不熟悉追蹤，最容易參與的方法就是參與到我們的 gitter 討論中來。
Zipkin 最近加入 ASF 孵化器，這對於 Zipkin 來說意味着什麼？
Adrian：Zipkin 發展了一段時間後，CNCF 聯繫我們加入，而我們考慮的是加入阿帕奇軟件基金會（ASF) 或者什麼也不加入。當時的社區看不到加入基金會的好處，我們當時選擇了什麼不加入基金會。然而，社區不斷髮展壯大，我們也有責任成長。特別是當我們通過 SkyWalking 的在 ASF 孵化對 ASF 有了更深入的瞭解。 因爲基金會要求旗下項目站在廠商中立的角度來考慮問題的，這樣可以幫助 Zipkin 站在社區的角度上考慮如何獨立發展。ASF 的文化和我們也更匹配，因此 Zipkin 於今年 8 月份剛成爲 Apache 孵化器項目。
作者簡介
姜寧，華爲開源能力中心技術專家，前紅帽軟件首席軟件工程師，Apache 軟件基金會 Member，有十餘年企業級開源中間件開發經驗，有豐富的 Java 開發和使用經驗，函數式編程愛好者。從 2006 年開始一直從事 Apache 軟基金會開源中間件項目的開發工作，先後參與 Apache CXF， Apache Camel，Apache ServiceMix，Apache ServiceComb 的開發。對微服務架構，WebServices，Enterprise Integration Pattern，SOA， OSGi 有比較深入的研究。
微博 ID：https://weibo.com/willemjiang
個人博客地址 ：https://willemjiang.github.io/