Leoncom » 分佈式服務的Trace——Google Da

對於分佈式在線服務，一個請求須要通過系統中多個模塊，上百臺機器的協做完成單次請求，典型場景就是Search Engine的一次用戶檢索，單靠人力沒法掌握整個請求中各個階段的性能開銷，更沒法快速的定位系統中性能瓶頸。Google Dapper文章描述了普遍用於Google內部服務的Trace Infrastruce—Dapper(原文地址見這裏，譯文地址見這裏)，文章自己的很易懂，沒有複雜、精巧的實現機制(好像也是g公司publish出來的文章的特色)，有一些分佈式在線服務經驗的程序員均可以很好的理解(英文版)，這裏就只抽一些點出來記錄。而Zipkin是Twitter開源出來的一個Trace系統組件，實現中就參考了Google Dapper，項目主頁見http://twitter.github.io/zipkin/。

Google Dapper

目標: 無所不在的持續跟蹤(ubiquitous deployment,and continuous monitoring)，只有無所不在和持續，才能保證全部的問題都能被跟蹤到，由於服務也是7*24的。爲了作到這兩點，Dapper對於這個Tracing組件，拆分出以下幾個目標。

• 低消耗(Low overhead): 分佈式在線系統對於性能、資源要求都很嚴格，Trace組件必須對服務影響足夠小，不然必定不會被啓用。
• 應用層透明(Application-Level Transparency): 應用層開發者不須要對Trace組件關心，Trace嵌入到基礎通用庫中，提供高穩定性，而若是Trace須要應用開發者配合，那可能會引入額外的bug致使Trace系統更加脆弱。
• 擴展性(Scalability): Google的服務在線集羣數量可想而知，一次檢索就可能跨越上百臺甚至成千臺機器，所以這個Trace Infrastructure的擴展性也很重要。
• 快速的數據分析(Analysis Quickly): 數據快速導出和分析，可以快速的定位系統的異常，及時應對，提高系統的穩定性。

典型檢索場景：單次user檢索貫串先後端多個模塊，模塊之間使用rpc進行通訊，以下圖，request須要系統中由不一樣團隊、不一樣語言構成的多個模塊通訊協做完成，典型的一個自上而下的調用序列。Dapper的採集方式基於這種調用序列構成的樹，拆分爲不一樣的span(一次rpc遠程調用)，經過全局惟一的Trace Id串起來，span指向本身的parent span。

Trace組件的實踐經驗：

• 低採樣率：在保證數據偏差的狀況下，Dapper儘量採用低的採樣率來保證Trace的low overhead，一方面會給應用層本身的Annotation標記留出更多的性能空間，也能夠在硬盤上保存更長時間的數據。
• 帶外數據收集(out-of-band)：Trace組件將span信息落地到本機，使用守護進程進行帶外收集，能夠避免Trace數據佔用檢索帶寬。同時，並非全部的調用過程都是完美的嵌套(prefect nested)，有些組件會在下游返回結果前先向上游彙報一些結果，不適合將Trace結果與檢索數據綁定。
• 數據隱私：Trace系統僅面向的是系統的性能開銷診斷，考慮到隱私，Dapper只記錄RPC的名稱和性能開銷，對於一些策略和業務數據，能夠考慮使用相似Online Debug的系統實現，引入權限控制。
• 精簡的基礎lib：Dapper基礎代碼庫很精簡，便於植入各個通用庫，保證穩定性和性能開銷，在大部分控制流的基礎庫上進行了默認植入，來記錄各個span的開銷，其中C++的代碼實現不到1000行。
• 控制Dapper數據採集守護進程的資源消耗：機器上的一些例行任務，例如數據統計腳本運行、外部數據的自動更新等，也會對部署在機器上的進程產生性能影響。所以，Dapper守護進程的性能數據採集，對使用的網絡、CPU都很是謹慎，Dapper守護進程爲內核scheduler最低的優先級。
• 開放API和易用的UI：方便的DAPI來訪問導入到Bigtable中的採集數據，其餘使用方可使用API來構建web應用、可執行的command等(根據經驗，RESTFul是一個不錯的選擇)，而且默認提供一個良好的UI，便於查詢。

Twitter Zipkin

Zipkin的項目主頁上說到——Zipkin is a distributed tracing system that helps us gather timing data for all the disparate services at Twitter. It manages both the collection and lookup of this data through a Collector and a Query service. We closely modelled Zipkin after the Google Dapper paper。看Zipkin的Architecture文檔，描述上也都實現了一些Dapper文章中核心的描述。

Zipkin Infrastructure

• Trace數據的收集系統，使用了Facebook開源的Scribe做爲日誌傳輸通路，將不一樣service上的Trace數據傳輸到Zipkin/Hadoop。
• Zipkin的Storage系統最早使用的是Cassandra，後來加入了Redis, HBase, MySQL, PostgreSQL, SQLite, and H2等存儲系統的支持，猜想這個也是Twitter當時放棄Cassandra轉回MySQL有關。
• Twitter中普遍使用了一個叫作Finagle的Java Async RPC服務，將trace library嵌入到這個Finagle中就成爲支持系統跟蹤的一個天然而然的選項。這個Library也是基於Dapper文章中的幾個概念(Annotation—包含host、時間戳的key/value；Span—一次特定的rpc調用，包含多個Annotation；Trace—由一組span組成，共享一個root span)。
• Client和Server在通訊時，會在tracing header信息中加上TraceId(標識整個trace)、SpanId(獨立的RPC request)、可選的Parent SpanId(一個服務會調用多個下游RPC服務)以及Sample boolean變量(標識本次是否採集)。
• 經過Thrift Api來提供數據的訪問查詢功能，並搭建本身的UI(基於Rails，使用了d3js)。

按照主頁上描述，Server接收到Client請求後，解析Trace頭的處理邏輯流程圖，本身畫的簡易流程圖(字很醜- -)。

不管是Dapper的文章，仍是Zipkin的主頁，對於分佈式系統中Trace Infrastructure的描述都比較簡單，只提到了一些必須的基礎組件，以及每一個組件須要關注的問題。但結合實際工做中經驗，這樣完備的Trace系統對分佈式在線服務的異常診斷、性能優化有很是大的幫助，而這樣的Trace組件又對各個基礎組件的要求很是高。健壯、完備的基礎組件對於這樣系統的搭建是很是有益的。