微服務-服務追蹤系統

微服務-服務追蹤系統

在一個龐大的微服務系統架構下，若是某一次服務請求出現了問題，那麼咱們如何定位是哪臺機器又或是哪一個接口出現了問題。

這時候，咱們就須要服務追蹤系統來查詢。

服務追蹤的做用：

1.定位請求出錯的位置

2.優化系統調用瓶頸，能夠分析每個接口的調用延時，從而優化相應的接口。

3.優化請求鏈路調用，在服務追蹤系統中，咱們能夠看到每一個接口調用另外一個接口的信息，查看在逐個調用中是否存在着不合理的跨區域的調用。

4.生成網絡拓撲圖，經過網絡拓撲圖，能夠分析出整個RPC的架構和性能信息。

5.透明傳輸數據，作A/B測試。

注：什麼是A/B測試？同時發佈兩個版本的內容供用戶使用，調研這兩個版本哪一個更受用戶歡迎及採用哪一個版本。

服務追蹤系統的原理

最原始的是由Google發表的Dapper論文。

核心理念是產生一個請求的完整調用鏈，經過一個在請求的第一層產生一個全局的ID，在整個請求過程當中傳遞，最後經過ID還原出整個的請求鏈路。

有名的服務追蹤系統：Zipkin；鷹眼；MTrace。

三個基礎概念：

traceId：用於表示某一個請求在全局的惟一ID。由請求在RPC調用網絡中的第一層生成。

spanId：用於標識一次RPC調用在分佈式請求中的位置，調用了哪臺機器的哪一個接口。

annotation：業務自定義的埋點，上傳在請求處理過程當中，須要後臺記錄的信息。

服務追蹤系統架構

一. 數據採集層

在業務的代碼中進行埋點，並將數據進行上報。

二. 數據處理

數據處理分爲兩類：實時計算需求，離線計算需求

1. 實時計算需求

通常採用Storm或者Spark Streaming進行流式處理方式進行實時的聚合加工，採用OLTP數據倉庫(HBase)。

2. 離線數據處理

採用MapReduce或者Spark批處理程序計算，採用Hive存儲。

三. 數據展現

兩種方式：調用連路圖，調用拓撲圖。

 

追問：實時監控系統和服務追蹤系統，這兩個系統的相同點和區別？

兩個系統均由數據採集、數據處理、數據展現三部分。

服務追蹤系統是幫助程序員在查看快速定位請求出錯在全局的位置，是哪一個接口出現問題。

實時監控系統是幫助程序員查看出錯接口的具體數據是多少。