Blog.6 分佈式會話跟蹤系統架構設計與實踐

調用鏈trace系統能夠幫助技術人員快速的定位問題，查看整個請求的調用鏈路，及各個鏈路的耗時狀況。方便技術人員針對性的對服務進行性能優化。

概念

參考調用鏈trace的設計分析的介紹，trace系統的要素包括：traceId、spanId、annotation。

1. traceId：貫穿整個調用鏈路，經過traceId來關聯鏈路的全部相關日誌
2. spanId：標識單次請求調用
3. annotation：記錄請求調用的附加信息

簡化trace日誌設計

在調用鏈trace的設計分析文章中，系統log設計相對複雜，先從最簡單的入手開始瞭解。

微服務A、B、C之間存在相互調用關係，咱們爲每次請求記錄一條log。經過log中的parnetID來肯定調用的層級關係，經過spanID來惟標識一個獨立請求，經過traceID來收斂全部相關日誌。最終就能夠肯定請求的調用層級結構。

從SERVER-C能夠看出，日誌記錄在C服務的總處理時間。在結合SERVER-B的發起請求時間，能夠初略得出span2的網絡耗時。

特別注意一下span的變化。當向下遊服務發起請求時，須要生成一個新的span，並將該span的父節點設置成上一步生成的span。SERVER-B請求SERVER-C描述的就是這個過程。

而當服務收到一個請求時，只有當請求沒有關聯新的span時，才須要生成一個span。SERVER-C收到SERVER-B的請求，描述的是這種狀況。

Other日誌設計

調用鏈trace的設計分析文章又是如何實現的呢？文章給出的調用關係以下：

二者的區別在於：肯定層級的方式不一樣。這裏經過span值的建立規則來肯定調用的層級。而前者是經過藉助parentID來肯定層級。

Annotation

經過基於Zipkin的Thrift服務RPC調用鏈跟蹤文章瞭解到，存儲span信息能夠經過Annotation和BinaryAnnotation來實現。

Annotation用於記錄某個時間點發生的event，對event的觸發時間、類型有明確規定。而BinaryAnnotation則用來記錄用戶自定義的信息。也就是說：前者是公用的，後者是我的用的。

由於反向代理路徑重寫的緣由，客戶端請求的path和服務端提供服務的path可能不相同，若是你想在系統中定位這種狀況，那麼你就能夠將http.url追加到BinaryAnnotaion屬性中。

瞭解一下BinaryAnnotation日誌存儲的數據內容：

{
    "app": "app", //所屬應用
    "ip": "ip", //ip地址,冗餘信息
    "key": "key", //key, 能夠設爲存儲用戶session的key, 若是是用來傳遞用戶session信息的, 能夠統一約定爲: session_id
    "mname": "mname",  //方法名
    "pid": "10000", //進程id,冗餘信息
    "sid": "sid", //spanId
    "sname": "sname", //服務名
    "tid": "tid", //traceId
    "timestamp": 1449038780194, //產生的時間戳, 長整型, 精確到毫秒
    "type": "type", //類型,用來區分是記錄異常的仍是業務流程的等等, 默認是'common'便可
    "value": "value" //若是是傳遞用戶session信息 ,能夠直接寫在該字段中.
}

參考地址：

1. 調用鏈trace的設計分析
2. 分佈式會話跟蹤系統架構設計與實踐
3. 基於Zipkin的Thrift服務RPC調用鏈跟蹤