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

一個看起來很簡單的應用，可能需要數十或數百個服務來支撐，一個請求就要多次服務呼叫。

當請求變慢、或者不能使用時，我們是不知道是哪個後臺服務引起的。

這時，我們使用 Zipkin 就能解決這個問題。

由於業務存取量的增大，業務複雜度增加，以及微服務架構和容器技術的興起，要對系統進行各種拆分。

微服務系統拆分後，我們可以使用 Zipkin 鏈路，來快速定位追蹤有故障的服務點。

今天重點講解 Zipkin 鏈路追蹤的原理與使用 @mikechen

Zipkin 基本概述

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

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

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

 

為什麼用 Zipkin ？

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

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

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

當請求變慢、或者不能正常使用時，我們不知道是哪個後臺服務引起的，這時，我們就要想辦法快速定位服務故障點。

Zipkin 分散式跟蹤系統就能非常好地解決該問題，主要解決以下3點問題：

1.  動態展示服務的鏈路；

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

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

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

當然了，除了 Zipkin 分散式跟蹤系統以外，我們還可以使用其他比較成熟的實現，例如：

• Naver 的 Pinpoint
• Apache 的 HTrace
• 阿里的鷹眼 Tracing
• 京東的 Hydra
• 新浪的 Watchman
• 美團點評的 CAT
• skywalking
• ......

知道了 Zipkin 的使用原因、使用場景和作用，接下來，我們來了解 Zipkin 的原理。

 

Zipkin 的原理

1. ZipKin 架構

ZipKin 可以分為兩部分：

• ZipKin Server ：用來作為資料的採集儲存、資料分析與展示；
• ZipKin Client ：基於不同的語言及框架封裝的一些列使用者端工具，這些工具完成了追蹤資料的生成與上報功能。

整體架構如下：

2. Zipkin 核心元件

Zipkin (伺服器端)包含四個元件，分別是 collector、storage、search、web UI。

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 為若干個子節點的一棵樹，如下圖所示：

4. Zipkin 的工作流程

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

1）把當前呼叫鏈的 Trace 資訊，新增到 HTTP Header 裡面；

2）記錄當前呼叫的時間戳；

3）傳送 HTTP 請求，把 trace 相關的 header 資訊攜帶上；

4）呼叫結束之後，記錄當前呼叫話費的時間；

5）把上面流程產生的資訊，彙整合一個 span，再把這個 span 資訊上傳到 zipkin 的 Collector 模組。

 

Zipkin 的部署與執行

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

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

 

總結

通過本文，我們知道了 Zipkin 的作用、使用場景、架構、核心元件，以及 Zipkin 的工作流程等，希望對大家掌握微服務有所幫助。

 

作者簡介

陳睿 | mikechen , 10年+大廠架構經驗,「mikechen 的網際網路架構」系列文章作者，專注於網際網路架構技術。