鏈路追蹤技術應用場景
在大型系統的微服務化構建中，一個系統被拆分成了許多模塊。這些模塊負責不同的功能，組合成系統，最終可以提供豐富的功能。在這種架構中，一次請求往往需要涉及到多個服務。互聯網應用構建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千台服務器，橫跨多個不同的數據中心，也就意味着這種架構形式也會存在一定問題：
如何快速發現問題？如何判斷故障影響范圍？如何梳理服務依賴以及依賴的合理性？如何分析鏈路性能問題以及實時容量規划？
常見的鏈路追蹤技術
cat
由大眾點評開源，基於java開發的實時應用監控平台，包括實時應用監控，業務監控。繼承方案是通過代碼埋點的方式來實現監控，比如：攔截器，過濾器等。對代碼的入侵性很大，集成成本較高，風險較大。
zipkin
由Twitter公司開源，開放源代碼分布式的跟蹤系統，用於手機服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展現。該產品結合spring-cloud-sleuth使用較為簡單，集成很方便，但功能較簡單。
pinpoint
由韓國人開源的基於字節碼注入的調用鏈分析，以及應用監控分析工具，特點是支持多種插件，UI功能較強，接入端無代碼入侵。
skywalking
是本土開源的基於字節碼注入的調用鏈分析，以及應用監控分析工具。特點和pinpoint差不多。
Sleuth
SpringCloud提供的分布式系統中鏈路追蹤解決方案。
Sleuth
SpringCloud Sleuth主要功能是在分布式系統中提供鏈路追蹤解決方案，它大量借用了Google Dapper的設計，SpringCloud Alibaba技術棧中並沒有提供自己的鏈路追蹤技術，於是我們使用Sleuth+Zipkin來做鏈路追蹤解決方案。
Trace
由一組Trace Id相同的Span串聯形成一個樹狀結構。為了實現請求跟蹤，當請求到達分布式系統的入口端點時，只需要服務跟蹤框架為該請求創建一個唯一標志（即TraceId），同時在分布式系統內部流轉的時候，框架始終保持傳遞該唯一值，直到真個請求的串聯起來，形成一條完整的請求鏈路。
Span
代表了一組基本的工作單元，為了統計各處理單元的延遲，當請求到達各個服務組件的時候，也通過一個唯一標志（SpanId）來標志它的開始、具體過程和結束。通過SpanId的開始和結束時間戳，能夠統計該span的調用時間，除此之外，我們還可以獲取如事件名稱、請求信息等元數據。
Annotation
它用於記錄一段時間內的事件，內部使用的重要注釋。
cs（Client Send）客戶端發出一個請求，開始一個請求生命。
sr（Server Received）服務端接受到請求開始處理，sr - cs = 網絡延遲（服務調用的時間）
ss（Server Send）服務端處理完畢准備發送到客戶端，ss - sr = 服務器上處理請求的時間
cr（Client Received）客戶端接收到服務端的響應，請求結束。cr - sr = 請求的總時間
Zipkin
zipkin致力於收集服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展現。我們可以使用它來收集各個服務器上的跟蹤數據，並通過它提供的REST API接口來輔助我們查詢跟蹤數據以實現對分布式的監控程序，從而及時的發現系統中出現的延遲升高問題並找出系統性能瓶頸的根源。
除了面向開發的API接口之外，它也提供了方便的UI組件來幫助我們直觀的搜索信息和分析請求鏈路明細，比如：可以查詢某段時間內個用戶請求的處理時間等。
Zipkin提供了可插拔數據存儲方式：in-Memory、Mysql、Cassandra以及Elasticsearch。
