3 服務追蹤系統實作
- 服務追蹤系統的架構
-
阿裡百度華為等大廠是如何追蹤微服務調用的?（下）3 服務追蹤系統實作 - 服務追蹤系統可以分為三層：
- 資料采集層，負責資料埋點并上報
- 資料處理層，負責資料的存儲與計算
- 資料展示層，負責資料的圖形化展示
3.1 資料采集層
在系統的各個不同子產品中進行埋點，采集資料并上報給資料處理層進行處理。
那麼該如何進行資料埋點呢？結合下面這張圖來了解一下資料埋點的流程。
以紅色方框裡圈出的A調用B的過程為例，一次RPC請求可以分為四個階段。
CS（Client Send）階段 : 用戶端發起請求，并生成調用的上下文
SR（Server Recieve）階段 : 服務端接收請求，并生成上下文
SS（Server Send）階段 : 服務端傳回請求，這個階段會将服務端上下文資料上報，下面這張圖可以說明上報的資料有：traceId=123456，spanId=0.1，appKey=B，method=B.method，start=103，duration=38。
CR（Client Recieve）階段 : 用戶端接收傳回結果，這個階段會将用戶端上下文資料上報，上報的資料有：traceid=123456，spanId=0.1，appKey=A，method=B.method，start=103，duration=38。
3.2 資料處理層
把資料采集層上報的資料按需計算，然後落地存儲供查詢使用。
據我所知，資料處理的需求一般分為兩類，一類是實時計算需求，一類是離線計算需求。
實時計算需求對計算效率要求比較高，一般要求對收集的鍊路資料能夠在秒級别完成聚合計算，以供實時查詢。而離線計算需求對計算效率要求就沒那麼高了，一般能在小時級别完成鍊路資料的聚合計算即可，一般用作資料彙總統計。針對這兩類不同的資料處理需求，采用的計算方法和存儲也不相同。
實時資料處理
針對實時資料處理，一般采用Storm或者Spark Streaming來對鍊路資料進行實時聚合加工，存儲一般使用OLTP資料倉庫，比如HBase，使用traceId作為RowKey，能天然地把一整條調用鍊聚合在一起，提高查詢效率。
離線資料處理
針對離線資料處理，一般通過運作MapReduce或者Spark批處理程式來對鍊路資料進行離線計算，存儲一般使用Hive。
3.3 資料展示層
資料展示層的作用就是将處理後的鍊路資訊以圖形化的方式展示給使用者。
主要用到如下兩種圖形展示：
調用鍊路圖
- Zipkin的調用鍊路圖
-
阿裡百度華為等大廠是如何追蹤微服務調用的?（下）3 服務追蹤系統實作 - 通過該圖可以看出：
服務整體情況
服務總耗時、服務調用的網絡深度、每一層經過的系統，以及多少次調用。上圖的一次調用總共耗時209.323ms，經過5個不同的系統子產品，調用深度為7層，共發生了24次系統調用。
每一層的情況
每一層發生了幾次調用，以及每一層調用的耗時。
調用鍊路圖在實際項目中，主要是被用來做故障定位，比如某一次使用者調用失敗了，可以通過調用鍊路圖查詢這次使用者調用經過了哪些環節，到底是哪一層的調用失敗所導緻。
調用拓撲圖
- Pinpoint的調用拓撲圖，通過這張圖可以看出系統内都包含哪些應用，它們之間是什麼關系，以及依賴調用的QPS、平均耗時情況
-
阿裡百度華為等大廠是如何追蹤微服務調用的?（下）3 服務追蹤系統實作 - 調用拓撲圖是一種全局視野圖，在實際項目中，主要用作全局監控，用于發現系統中異常的點，進而快速做出決策。比如，某一個服務突然出現異常，那麼在調用鍊路拓撲圖中可以看出對這個服務的調用耗時都變高了，可以用紅色的圖樣标出來，用作監控報警。
參考
http://bigbully.github.io/Dapper-translation/ https://tech.meituan.com/2016/10/14/mt-mtrace.html