分散式跟蹤系統——產品對比

cdh0805010118發表於2018-06-27

分散式跟蹤系統設計目標

低侵入性
靈活的應用策略；(可以 [最好隨時] 決定所收集資料的範圍和粒度)
時效性；從 agent 取樣，到 collect、storage 和 display 儘可能快
決策支援；
視覺化是王道；(豐富的資料包表)
低消耗；在 web 請求鏈路中，對請求的響應影響儘可能小
延展性；隨著業務量暴增，分散式跟蹤系統的高可用、和高效能表現依然好

分散式跟蹤系統標準——OpenTracing

為了規範業界的分散式跟蹤系統產品的統一正規化，CNCF(大名鼎鼎的 Cloud Native Computing Foundation) 設計了 trace 標準，目前 uber、apple 等知名公司完全遵循該標準設計 trace 系統。

各大廠商 trace 系統對比

分散式跟蹤系統各類產品，根據設計目標和標準形成綜合對比：

產品名稱	廠商	開源	OpenTracing 標準	侵入性	應用策略	時效性	決策支援	視覺化	低消耗	延展性
jaeger	uber	開源	完全支援	部分侵入	策略靈活	時效性高， UDP 協議傳輸資料 (在 Uber 任意給定的一個 Jaeger 安裝可以很容易地每天處理幾十億 spans)	決策支援較好，並且底層支援 metrics 指標	報表不豐富，UI 比較簡單	消耗低	jaeger 比較複雜，使用框架較多，比如：rpc 框架採用 thrift 協議，不支援 pb 協議之類。後端儲存比較複雜。但經過 uber 大規模使用，延展性好
zipkin	twitter	開源	部分支援	侵入性強	策略靈活	時效性好	決策一般 (功能單一，監控維度和監控資訊不夠豐富。沒有告警功能)	豐富的資料包表	系統開銷小	延展性好
CAT	大眾點評吳其敏	開源	-	侵入性強	策略靈活	時效性較好，rpc 框架採用 tcp 傳輸資料	決策好	報表豐富，滿足各種需求	消耗較低，國內很多大廠都在使用	-
Appdash	sourcegraph	開源	部分支援	侵入性較弱	取樣率支援 (粒度：不能根據流量取樣，只能依賴於請求數量)；沒有 trace 開關	時效性高	決策支援低	視覺化太弱，無報表分析	消耗方面。不支援大規模部署, 因為 appdash 主要依賴於 memory，雖然可以持久化到磁碟，以及記憶體儲存支援 hash 儲存、帶有效期的 map 儲存、以及不加限制的記憶體儲存，前者儲存量過小、後者單機記憶體儲存無法滿足	延展性差
MTrace	美團	不開源	-	-	-	-
CallGraph	京東	不開源	-
Watchman	sina 微博	不開源	-
EagleEye	淘寶	不開源	-
skywalking	華為吳晟	開源	完全支援	侵入性很低	策略靈活	時效性較好	由於呼叫鏈路的更細化，但是作者在效能和追蹤細粒度之間保持了比較好的平衡。決策好	豐富的資料包表	消耗較低	延展性非常好，水平理論上無限擴充套件

綜合來說，

1. jaeger對於go開發者來說，可能比較合適一些，但是入手比較困難。它的rpc框架採用thrift協議，現在主流grpc並不支援。後端豐富儲存，社群正在積極適配
2. appdash對於go開發者想搭建一個小型的trace比較合適，不適合大規模使用
3. zipkin專案，github很活躍，star數量很多，屬於java系。很多大廠使用
4. CAT專案也屬於java系, github不活躍，已不太更新了。不過很多大廠使用，平安、大眾點評、攜程...
5. skywalking專案, 也屬於java系。目前已成為Apache下的專案了，github活躍，作者也非常活躍，噹噹、華為正在使用。
6. appdash專案，go語言開發，因為視覺化過於簡單、且完全記憶體儲存，不太適合大規模專案使用。

所以選擇的話，可以從skywalking、cat、jaeger和zipkin中選擇。