本文為博主原創文章，未經博主允許不得轉載。
在上篇隨筆后，分布式鏈路在緩慢推進。一直沒什么興致寫，zipkin使用elasticsearch作為數據完全是可行的。但是揉合這兩者，就存在兩種方案：
第一種，保持zipkin，替換掉存儲。即保持zipkin架構，替換掉默認數據存儲，改用elasticsearch作為存儲。這完全是可行的，但是做出來的也僅僅是一個分布式鏈路追蹤系統。zipkin官方有相應的多數據源的實現源碼，有興趣大家可以自行去git上看。
由於我們想要的不只是分布式鏈路追蹤系統，我們往往要的是一套完善的日志分析、監控和分布式鏈路追蹤於一身的系統。ELK實現日志分析，在此我們能否用ELK進行擴展，實現自己的調用鏈追蹤。從方案上來看完全是可行的，我們可以利用zipkin的數據存儲結構進行對接，使用zipkin查詢elasticsearch數據作為調用鏈展示。
當然我們也可以利用自己收集的數據，自己根據google dapper自己寫一套查詢 分析展示調用鏈，不一定需要跟zipkin一致。
所以第二種方案脫離zipkin，擴展ELK實現自己的分布式鏈路追蹤系統。根據google dapper思想，與zipkin大同小異，實現tracing service服務。架構簡圖如圖：
Tracing服務通過elasticsearch暴露的API，查詢出我們需要的數據。然后數據分析成調用鏈結構，展示到UI層。這里Tracing作為一個服務暴露出去。
方案暫時如此，能否走通還需要時間驗證。難免采坑，如：日志埋點現在的設計就比zipkin的粒度更細，所帶來的問題也就越多。
也看了一些方案，其實都差不多，都是基於google dapper的想法，只是數據和實現效果上有所區別。
這里可以推薦大家去看的方案有:zipkin(twitter)、鷹眼(阿里)、hydra(京東)、tracing(窩窩)。