微服務Zipkin鏈路追蹤原理(圖文超詳解)

微服務Zipkin鏈路追蹤原理(圖文超詳解)

隨著微服務系統拆分後,急需鏈路追蹤有故障的服務,今天就重點講解Zipkin鏈路追蹤的原理與使用@mikechen

微服務Zipkin鏈路追蹤原理(圖文超詳解)

Zipkin

Zipkin是一款開源的分散式實時資料追蹤系統(Distributed Tracking System),能夠收集服務間呼叫的時序資料,提供呼叫鏈路的追蹤。

Zipkin其主要功能是聚集來自各個異構系統的實時監控資料,在微服務架構下,十分方便地用於服務響應延遲等問題的定位。

Zipkin每一個呼叫鏈路透過一個trace id來串聯起來,只要你有一個trace id,就能夠直接定位到這次呼叫鏈路,並且可以根據服務名、標籤、響應時間等進行查詢,過濾那些耗時比較長的鏈路節點。

微服務Zipkin鏈路追蹤原理(圖文超詳解)

為什麼用 Zipkin?

大型網際網路公司為什麼需要分散式跟蹤系統?

隨著業務訪問量越來越大,比如:典型的淘寶從早期的單體開始往分散式微服務演變,系統也隨之進行各種拆分,看似簡單的一個應用,後臺可能有幾十個甚至幾百個服務在支撐。

一個前端的請求,比如:一次下訂單請求,可能需要多次的服務呼叫:商品、使用者、店鋪等系統呼叫過程,最後才能完成。

當請求變慢或者不可用時,我們無法得知是哪個後臺服務引起的,這時就需要解決如何快速定位服務故障點。

Zipkin分散式跟蹤系統就能很好的解決這樣的問題,

主要解決以下3點問題:

1。動態展示服務的鏈路;

2。分析服務鏈路的瓶頸並對其進行調優;

3。快速進行服務鏈路的故障發現。

這就是Zipkin服務跟蹤系統存在的目的和意義。

當然除了Zipkin分散式跟蹤系統,還有其他比較成熟的實現,例如:Naver的Pinpoint、Apache的HTrace、阿里的鷹眼Tracing、京東的Hydra、新浪的Watchman,美團點評的CAT,skywalking等。

今天我重點談談Zipkin鏈路追蹤原理機制@mikechen

1。ZipKin架構

ZipKin可以分為兩部分:

一部分是ZipKin Server:用來作為資料的採集儲存、資料分析與展示;

一部分是ZipKin Client:基於不同的語言及框架封裝的一些列客戶端工具,這些工具完成了追蹤資料的生成與上報功能。

整體架構如下:

微服務Zipkin鏈路追蹤原理(圖文超詳解)

2。Zipkin核心元件

zipkin(服務端)包含四個元件,分別是collector、storage、search、web UI。

微服務Zipkin鏈路追蹤原理(圖文超詳解)

1)collector(資訊收集器)

collector接受或者收集各個應用傳輸的資料。

2)storage(儲存元件)

zipkin 預設直接將資料存在記憶體中,此外支援使用Cassandra、ElasticSearch 和 Mysql。

3)search (查詢程序)

它提供了簡單的JSON API來供外部呼叫查詢。

4)web UI (服務端展示平臺)

主要是提供簡單的web介面,用圖表將鏈路資訊清晰地展示給開發人員。

3。Zipkin核心結構

當用戶發起一次呼叫時,Zipkin 的客戶端會在入口處為整條呼叫鏈路生成一個全域性唯一的 trace id,併為這條鏈路中的每一次分散式呼叫生成一個 span id。

一個 trace 由一組 span 組成,可以看成是由 trace 為根節點,span 為若干個子節點的一棵樹,如下圖所示:

微服務Zipkin鏈路追蹤原理(圖文超詳解)

4。Zipkin的工作流程

一個應用的程式碼發起HTTP get請求,經過Trace框架攔截,大致流程如下圖所示:

微服務Zipkin鏈路追蹤原理(圖文超詳解)

1)把當前呼叫鏈的Trace資訊新增到HTTP Header裡面;

2)記錄當前呼叫的時間戳;

3)傳送HTTP請求,把trace相關的header資訊攜帶上;

4)呼叫結束之後,記錄當前呼叫話費的時間;

5)然後把上面流程產生的 資訊彙集成一個span,把這個span資訊上傳到zipkin的Collector模組。

Zipkin的部署與執行

Zipkin的 github 地址:https://github。com/apache/incubator-zipkin

Docker 方式

docker run -d -p 9411:9411 openzipkin/zipkin

Jar 包方式(JDK8)

curl -sSL https://zipkin。apache。org/quickstart。sh | bash -sjava -jar zipkin。jar

注意:以上方式的 Zipkin 都是基於記憶體儲存,Zipkin 重啟後資料會丟失,建議測試環境使用。

Zipkin 支援的儲存型別有 inMemory、MySql、Cassandra、以及 ElasticsSearch 幾種方式。正式環境推薦使用 Cassandra 和 ElasticSearch。

微服務Zipkin鏈路追蹤原理(圖文超詳解)

Zipkin總結

以上我就重點講解了為什麼要使用Zipkin,以及Zipkin的架構,核心元件,以及Zipkin的工作流程,希望對大家掌握微服務有所幫助

@mikechen

以上!

閱讀更多架構技術合集

微服務Zipkin鏈路追蹤原理(圖文超詳解)

微服務Zipkin鏈路追蹤原理(圖文超詳解)

作者:陳睿|mikechen 10年+大廠架構經驗 mikechen的網際網路架構作者

本文由 @mikechen 原創釋出於mikechen的網際網路架構,未經許可,禁止轉載。