個(gè)推基于 Zipkin 的分布式鏈路追蹤實(shí)踐

作者：個(gè)推應(yīng)用平臺(tái)基礎(chǔ)架構(gòu)高級(jí)研發(fā)工程師 阿飛

01業(yè)務(wù)背景

隨著微服務(wù)架構(gòu)的流行，系統(tǒng)變得越來(lái)越復(fù)雜，單體的系統(tǒng)被拆成很多個(gè)模塊，各個(gè)模塊通過(guò)輕量級(jí)的通信協(xié)議進(jìn)行通訊，相互協(xié)作，共同實(shí)現(xiàn)系統(tǒng)功能。

單體架構(gòu)時(shí)，一個(gè)請(qǐng)求的調(diào)用鏈路很清晰，一般由負(fù)載均衡器將用戶(hù)請(qǐng)求轉(zhuǎn)發(fā)到后端服務(wù)，由后端服務(wù)進(jìn)行業(yè)務(wù)處理，需要的數(shù)據(jù)從外部的存儲(chǔ)中獲取，處理完請(qǐng)求后，再經(jīng)由負(fù)載均衡器返回給用戶(hù)。

而在微服務(wù)架構(gòu)中，一個(gè)請(qǐng)求往往需要多個(gè)模塊共同協(xié)作處理，不同模塊可能還依賴(lài)于不同的外部存儲(chǔ)，各個(gè)模塊的實(shí)現(xiàn)技術(shù)還不盡相同，一個(gè)請(qǐng)求是如何在整個(gè)系統(tǒng)不同模塊間進(jìn)行流轉(zhuǎn)，整個(gè)調(diào)用鏈上的各個(gè)模塊之間的調(diào)用關(guān)系如何，每個(gè)微服務(wù)處理的時(shí)間長(zhǎng)短，處理的結(jié)果是否正確，很難去進(jìn)行追蹤，而這些信息對(duì)于整個(gè)系統(tǒng)運(yùn)維、性能分析、故障追蹤都特別有幫助，也正因?yàn)榇耍庞辛烁鞣N分布式鏈路追蹤的技術(shù)。

02分布式鏈路追蹤現(xiàn)狀

分布式鏈路追蹤的技術(shù)有很多，有開(kāi)源的也有閉源的。開(kāi)源的有Jaeger、PinPoint、Zipkin、SkyWalking、CAT等，閉源的有Google Dapper、淘寶的鷹眼Tracing、新浪的Watchman、美團(tuán)的MTrace等。CNCF(Cloud Native Computing Foundation)為了解決業(yè)界分布式追蹤系統(tǒng)跨平臺(tái)兼容性問(wèn)題，設(shè)計(jì)了trace的標(biāo)準(zhǔn)，提出了分布式跟蹤系統(tǒng)產(chǎn)品的統(tǒng)一范式-OpenTracing，Zipkin也部分支持OpenTracing標(biāo)準(zhǔn)。

03選擇Zipkin的原因

在實(shí)踐的過(guò)程中，基于以下原因選擇了Zipkin來(lái)進(jìn)行鏈路追蹤：
? 開(kāi)源，社區(qū)活躍
? 支持多種語(yǔ)言，Nodejs，Lua，Java都有開(kāi)源實(shí)現(xiàn)，而我們的服務(wù)主要是這三種語(yǔ)言實(shí)現(xiàn)的
? 提供查詢(xún)API，方便二次開(kāi)發(fā)

04Zipkin的架構(gòu)介紹

Zipkin的整體架構(gòu)如下圖所示：

Zipkin的整體架構(gòu)
（引用自Zipkin官網(wǎng)：https://zipkin.io/pages/architecture.html）

其中：
? Instrumented client和Instrumented server需要集成在分布式系統(tǒng)的具體服務(wù)中，采集跟蹤信息，調(diào)用Transport，把跟蹤信息發(fā)送給Zipkin的Server。
? Transport是Zipkin對(duì)外提供的接口，支持HTTP、Kafka、Scribe等通信方式。
? Zipkin即Zipkin server，主要包括四個(gè)模塊：
Collector: 用于接收各個(gè)應(yīng)用服務(wù)傳輸?shù)淖粉櫺畔ⅲ?br/>Storage：Zipkin的后端存儲(chǔ)，支持In-Memory、MySql、Elasticsearch和Cassandra；
API：提供對(duì)外的查詢(xún)接口；
UI：提供對(duì)外的Web界面。

Http Tracing的時(shí)序圖
（引用自Zipkin官網(wǎng)：https://zipkin.io/pages/architecture.html）

以上是Http Tracing的時(shí)序圖，用戶(hù)的請(qǐng)求/foo首先被Trace Instrumentationlan攔截，記錄下Tags，時(shí)間戳，同時(shí)在Header里增加Trace信息，然后再流轉(zhuǎn)到后端服務(wù)進(jìn)行處理，處理完成后，正常響應(yīng)，Trace Instrumentationlan攔截響應(yīng)，記錄處理延時(shí)后，將Response正常返回給調(diào)用方，同時(shí)異步地將Trace的Span發(fā)送給Zipkin Server。Span中的traceId是在整個(gè)調(diào)用鏈路上唯一的ID，用于唯一標(biāo)識(shí)一條調(diào)用鏈。

05個(gè)推的Zipkin實(shí)踐

個(gè)推的微服務(wù)是基于Kubernetes和Docker進(jìn)行部署的，每個(gè)微服務(wù)對(duì)應(yīng)于Kubernetes中的一組Pod。

在整個(gè)微服務(wù)體系中，API網(wǎng)關(guān)是基于Openresty開(kāi)發(fā)的，主要使用Lua進(jìn)行開(kāi)發(fā)；后端服務(wù)主要使用Node.js和Java進(jìn)行開(kāi)發(fā)實(shí)現(xiàn)。在對(duì)接Zipkin時(shí)，不同的微服務(wù)采用不同的方式進(jìn)行實(shí)現(xiàn)。

API網(wǎng)關(guān)主要通過(guò)增加網(wǎng)關(guān)插件（主要參考了Kong的Zipkin插件實(shí)現(xiàn)）來(lái)實(shí)現(xiàn)與Zipkin的對(duì)接；Node.js實(shí)現(xiàn)的服務(wù)主要使用了中間件實(shí)現(xiàn)與Zipkin的對(duì)接；Java服務(wù)使用了spring-cloud-sleuth來(lái)與Zipkin對(duì)接。 整體的架構(gòu)如下圖所示：

個(gè)推基于Zipkin的分布式鏈路追蹤系統(tǒng)的整體架構(gòu)

其中，Zipkin也容器化部署在Kubernetes集群中，簡(jiǎn)化了Zipkin的搭建和部署。如下圖所示，通過(guò)Zipkin可以很方便地追蹤請(qǐng)求的調(diào)用鏈路，整個(gè)調(diào)用鏈上各個(gè)服務(wù)的處理耗時(shí)，響應(yīng)狀態(tài)，服務(wù)間的調(diào)用關(guān)系都可以方便地在Zipkin中進(jìn)行查詢(xún)。Zipkin對(duì)于分析整個(gè)系統(tǒng)的性能瓶頸，定位故障也都有很大的幫助。

Zipkin的Web界面

06總結(jié)

Zipkin作為一個(gè)分布式鏈路追蹤系統(tǒng)，有著應(yīng)用侵入較小、社區(qū)活躍度較高、支持多種語(yǔ)言等優(yōu)勢(shì)，一般基于開(kāi)源的實(shí)現(xiàn)稍做修改就可以實(shí)現(xiàn)與Zipkin的對(duì)接。因此個(gè)推在微服務(wù)架構(gòu)中也引入了Zipkin，用Zipkin來(lái)追蹤微服務(wù)的調(diào)用關(guān)系，對(duì)微服務(wù)進(jìn)行性能分析和故障診斷。未來(lái)，個(gè)推會(huì)基于Zipkin做二次開(kāi)發(fā)，提供更為友好的界面。