分布式應?架構雖然滿?了應?橫向擴展的需求，但是運維和診斷的過程變得越來越復雜，例如會遇到接?診斷困難、應?性能診斷復雜、架構分析復雜等難題，傳統(tǒng)的監(jiān)控?具并?法滿?，分布式鏈路系統(tǒng)由此誕?。

01 鏈路追蹤介紹

1.1 微服務鏈路追蹤介紹

一個完整的微服務系統(tǒng)一般由成百上千，甚至幾萬、幾十萬個服務實例構成。拋兩個常?的問題：

• 微服務調(diào)?鏈路出現(xiàn)了問題怎么快速排查？

• 微服務調(diào)?鏈路耗時?怎么定位是哪個服務？

分布式鏈路追蹤（Distributed Link Tracking），就是將一次分布式請求還原成調(diào)用鏈路，進行日志記錄，性能監(jiān)控并將一次分布式請求的調(diào)用情況集中展示。比如各個服務節(jié)點上的耗時、請求具體到達哪臺機器上、每個服務節(jié)點的請求狀態(tài)等等。

所以，需要用鏈路跟蹤工具來監(jiān)控微服務狀態(tài)，當出現(xiàn)問題時能及時定位問題點，快速解決問題。

1.2 微服務鏈路追蹤產(chǎn)品

在分布式系統(tǒng)中，鏈路追蹤的解決方案有很多產(chǎn)品。具體介紹見下：

• log4j是Spring Cloud提供的分布式系統(tǒng)中鏈路追蹤解決方案。

• Cat由大眾點評開源，基于Java開發(fā)的實時應用監(jiān)控平臺，包括實時應用監(jiān)控，業(yè)務監(jiān)控。集成方案是通過代碼埋點的方式來實現(xiàn)監(jiān)控。

• Pinpoint專注于鏈路和性能監(jiān)控，韓國研發(fā)團隊開源，埋點無侵入，UI功能較強。但畢竟是小團隊，不知道會不會一直維護著，目前版本仍在更新中。

• SkyWalking是本土開源的基于字節(jié)碼注入的調(diào)用鏈分析，以及應用監(jiān)控分析工具。特點是支持多種插件，UI功能較強，接入端無代碼侵入。目前已加入Apache孵化器。SkyWalking專為微服務、云原生架構和基于容器（Docker、K8s、Mesos）架構而設計。

• Zipkin由Twitter公司開源，開放源代碼分布式的跟蹤系統(tǒng)，用于收集服務的定時數(shù)據(jù)，以解決微服務架構中的延遲問題，包括數(shù)據(jù)的收集、存儲、查找和展現(xiàn)圖形化。該產(chǎn)品結合Spring Cloud Sleuth使用較為簡單，集成很方便，但是功能較簡單。

注意：Spring Cloud Alibaba技術棧中并沒有提供自己的鏈路追蹤技術的，我們可以采用Sleuth + Zipkin來做鏈路追蹤解決方案。

02 Spring Cloud Sleuth概述

2.1 Spring Cloud Sleuth介紹

Spring Cloud Sleuth為Spring Cloud的分布式跟蹤解決方案提供API。它與OpenZipkin Brave集成。

Spring Cloud Sleuth能夠跟蹤您的請求和消息，以便您可以將該通信與相應的日志條目相關聯(lián)。您還可以將跟蹤信息導出到外部系統(tǒng)以可視化延遲。Spring Cloud Sleuth直接支持OpenZipkin兼容系統(tǒng)。

2.2 Spring Cloud Sleuth術語

Spring Cloud Sleuth借用了Dapper的術語。

Span

代表了一組基本工作單元。為了統(tǒng)計各處理單元的延遲，當請求到達各個服務組件的時候，也通過一個唯一標識（Span Id）來標記它的開始、具體過程和結束。通過Span Id的開始和結束時間戳，就能統(tǒng)計該span的調(diào)用時間，除此之外，我們還可以獲取如事件的名稱，請求信息等元數(shù)據(jù)。

Trace

由一組Trace Id相同的Span串聯(lián)形成一個樹狀結構。為了實現(xiàn)請求跟蹤，當請求到達分布式系統(tǒng)的入口端點時，只需要服務跟蹤框架為該請求創(chuàng)建一個唯一的標識（即Trace Id），同時在分布式系統(tǒng)內(nèi)部流轉的時候，框架始終保持傳遞該唯一值，直到整個請求的返回。那么我們就可以使用該唯一標識將所有的請求串聯(lián)起來，形成一條完整的請求鏈路。

Annotation/Event

用它記錄一個完成請求的4個事件，內(nèi)部使用的重要注釋。

• cs：Client Sent。客戶端已經(jīng)發(fā)出了一個請求。描述的是一個Span的開始。

• sr：Server Received。服務器端收到請求并開始處理。從這個時間戳中減去cs時間戳可以顯示網(wǎng)絡延遲（sr－cs = 網(wǎng)絡延遲，即服務調(diào)用的時間）。

• ss：Server Sent。服務端處理完畢，當響應被發(fā)送回客戶端時。從這個時間戳中減去sr時間戳可以揭示服務器端處理請求所需的時間（ss - sr = 服務器上的請求處理時間）。

• cr：Client Reveived?？蛻舳艘殉晒κ盏椒掌鞫说捻憫?，標志著請求結束。從該時間戳中減去cs時間戳，即可顯示客戶端從服務器接收響應所需的全部時間（cr - cs = 請求的總時間）。

下圖顯示了Span和Trace在系統(tǒng)中的樣子：

上圖中的每一種顏色都表示一個Span（從A到G有七個Span）?？紤]以下注意事項：

此注釋表明，當前跨度將Trace Id設置為X，Span Id設置為D。此外，從RPC的角度來看，發(fā)生了Client Sent事件。

讓我們考慮更多的注意事項：

您可以繼續(xù)使用已創(chuàng)建的Span（例如，no custom span指示），也可以手動創(chuàng)建子Span（例如，custom span指示）。下圖顯示了Span的親子關系：

2.3 Spring Cloud Sleuth特點

Spring Cloud Sleuth有以下幾個特點。

03 Zipkin概述

3.1 Zipkin介紹

Spring Cloud Sleuth對于分布式鏈路的跟蹤僅僅是生成一些數(shù)據(jù)，這些數(shù)據(jù)不便于人類閱讀，因此我們一般把這種跟蹤數(shù)據(jù)上傳到Zipkin Server，由Zipkin通過UI頁面統(tǒng)一進行數(shù)據(jù)的展示。那什么是Zipkin呢？Zipkin是Twitter的一個開源項目，它基于Google Dapper實現(xiàn)，它致力于收集服務的定時數(shù)據(jù)，以解決微服務架構中的延遲問題，包括數(shù)據(jù)的收集、存儲展現(xiàn)、查找和我們可以使用它來收集各個服務器上請求鏈路的跟蹤數(shù)據(jù)，并通過它提供的REST API接口來輔助我們查詢跟蹤數(shù)據(jù)以實現(xiàn)對分布式系統(tǒng)的監(jiān)控程序，從而及時地發(fā)現(xiàn)系統(tǒng)中出現(xiàn)的延遲升高問題并找出系統(tǒng)性能瓶頸的根源，除了面向開發(fā)的API接口之外，它也提供了方便的UI組件來幫助我們直觀的搜索跟蹤信息和分析請求鏈路明細，比如：可以查詢某段時間內(nèi)各用戶請求的處理時間等。

Zipkin提供了可插拔數(shù)據(jù)存儲方式：In-Memory、MySQL、Cassandra以及Elasticsearch。

上圖展示了Zipkin的基礎架構，它主要由4個核心組件構成：

• Collector：收集器組件，它主要用于處理從外部系統(tǒng)發(fā)送過來的跟蹤信息，將這些信息轉換為Zipkin內(nèi)部處理的Span格式，以支持后續(xù)的存儲、分析、展示等功能。

• Storage：存儲組件，它主要對處理收集器接收到的跟蹤信息，默認會將這些信息存儲在內(nèi)存中，我們也可以修改此存儲策略，通過使用其他存儲組件將跟蹤信息存儲到數(shù)據(jù)庫中。

• RestFul API：API組件，它主要用來提供外部訪問接口。比如給客戶端展示跟蹤信息，或是外接系統(tǒng)訪問以實現(xiàn)監(jiān)控等。

• Web UI：UI組件，基于API組件實現(xiàn)的上層應用。通過UI組件用戶可以方便而又直觀地查詢和分析跟蹤信息。

Zipkin分為兩端，一個是Zipkin服務端，一個是Zipkin客戶端，介紹見下：

• Zipkin客戶端：指微服務應用，客戶端會配置服務端的URL地址，一旦發(fā)生服務間的調(diào)用的時候，會被配置在微服務里面的Sleuth的監(jiān)聽器監(jiān)聽，并生成相應的Trace和Span信息發(fā)送給服務端，發(fā)送的方式主要有兩種，一種是HTTP報文的方式，還有一種是消息總線的方式如RabbitMQ。

• Zipkin服務端：服務端負責將接收到的消息根據(jù)Trace Id和Span Id整理成一個完整的Request時序鏈路，并通過Web頁面直觀的展示出來。

3.2 Zipkin服務端安裝

Zipkin的服務端（Zipkin Server），在使用Spring Boot 2.x版本后，官方就不推薦自行定制編譯了，反而是直接提供了編譯好的jar包來給我們使用。

1.下載Zipkin的jar包。訪問ZipKin官網(wǎng)https://zipkin.io/pages/quickstart.html，點擊【latest release】鏈接進行下載。

2.進入命令行終端，輸入下面的命令啟動Zipkin Server服務。

3.啟動Zipkin Server服務成功后，命令行終端輸出如下的日志信息。

4.通過瀏覽器訪問http://127.0.0.1:9411地址，打開Zipkin Dashboard控制面板。

04 Sleuth鏈路追蹤搭建

1.在micro-service-cloud-seata-storage-8006、micro-service-cloud-seata-account-8007和micro-service-cloud-seata-order-8008三個項目的pom.xml文件中分別都添加sleuth和sleuth-zipkin依賴。

說明：spring-cloud-starter-zipkin的最新版本是2.2.8.RELEASE，之后就沒有更新了。較新版本的Spring Cloud已經(jīng)不再支持spring-cloud-starter-zipkin依賴，取而代之的是spring-cloud-sleuth-zipkin依賴。

2.在micro-service-cloud-seata-storage-8006、micro-service-cloud-seata-account-8007和micro-service-cloud-seata-order-8008三個項目的application.yml文件中分別都添加sleuth和zipkin的配置，具體的配置在spring節(jié)點下添加如下子節(jié)點信息。

屬性spring.zipkin.sender.type=web的含義是通過HTTP的方式發(fā)送數(shù)據(jù)到Zipkin Server，如果請求量比較大，這種方式其實性能是比較低的，一般情況下我們都是通過消息中間件來發(fā)送，比如RabbitMQ；這種方式就是讓服務將Sleuth收集的日志推給MQ，讓Zipkin去監(jiān)控MQ的信息，通過MQ的隊列獲取到服務的信息，這樣就提高了性能。如果日志數(shù)據(jù)量比較大，一般推薦擁有更高吞吐量的Kafka來進行日志推送。而日志的存儲則可以采用Elasticsearch對數(shù)據(jù)進行持久化，這樣可以保證Zipkin重啟后，鏈路信息不會丟失。這種解決方案在本章節(jié)中僅作了解，具體實現(xiàn)不在這里展開介紹。

說明：關于Sleuth的其他相關配置屬性，可查看官網(wǎng)：https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/appendix.html#appendix。

3.啟動micro-service-cloud-seata-storage-8006、micro-service-cloud-seata-account-8007和micro-service-cloud-seata-order-8008三個微服務項目，使用ApiPost工具訪問http://127.0.0.1:8008/order/create/1/1/10/200地址，產(chǎn)生鏈路信息。

4.如果在啟動以上三個微服務項目時，提示如下錯誤，原因是把base-url的值聲明成了http://127.0.0.1:9411，改寫成http://localhost:9411即可解決該問題。如果沒有以下的異常信息，則忽略此步驟。

5.使用瀏覽器訪問http://127.0.0.1:9411網(wǎng)頁，在【找到一個痕跡】選項下點擊【RUN QUERY】按鈕，查找請求信息，結果見下。

6.點擊【micro-service-cloud-seata-order-8008: get /order/create/{userid}/{productid}/{count}/{money}】這條記錄后的【SHOW】按鈕，可以查閱一次訪問的詳細線路。結果見下。

7.也可以點擊上圖又上角的【SPAN TABLE】選項，以表格的形式展示Span的詳情信息，結果見下。

8.在Zipkin主頁選擇【依賴】選項，然后可以根據(jù)時間段查詢運行的服務信息，選擇“開始時間”和“終止時間”段，然后點擊【RUN QUERY】選項查詢運行的服務。結果見下。

9.使用鼠標點擊下圖中的任意一個服務，在控制臺的右側將展示該服務的使用情況。

10.使用ApiPost工具訪問http://127.0.0.1:8008/order/create/1/1/10/2000接口，提交的2000超出賬戶的可用總金額，因此后端業(yè)務代碼會報錯。再次進入到Zipkin。

05 Zipkin數(shù)據(jù)持久化

Zipkin Server默認會將追蹤數(shù)據(jù)信息保存到內(nèi)存，但這種方式不適合生產(chǎn)環(huán)境，一旦Zipkin Server關閉重啟或者服務崩潰，就會導致歷史數(shù)據(jù)消失。Zipkin支持修改存儲策略使用其他存儲組件，支持MySQL數(shù)據(jù)庫、Cassandra（Cassandra是一套開源分布式NoSQL數(shù)據(jù)庫系統(tǒng)）和Elasticsearch（Elasticsearch是一個分布式、高擴展、高實時的搜索與數(shù)據(jù)分析引擎）等。

1.在MySQL數(shù)據(jù)庫中，新建一個名為zipkin的數(shù)據(jù)庫實例，并選中該數(shù)據(jù)庫。

2.并通過以下SQL語句在zipkin子庫中創(chuàng)建3張表：zipkin_spans表、zipkin_annotations表和zipkin_dependencies表。

說明：Zipkin數(shù)據(jù)持久化的建表語句由Zipkin官方提供，通過訪問Github的https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql地址來獲取數(shù)據(jù)庫腳本。

3.先關閉Zipkin服務，重新進入命令行終端，輸入以下命令來啟動Zipkin Server服務，同時在啟動ZipKin Server服務的時候，指定數(shù)據(jù)保存的MySQL的信息。

通過命令啟動Zipkin Server服務的參數(shù)說明：

4.啟動Zipkin Server服務成功后，命令行終端輸出如下的日志信息。

5.先使用ApiPost工具訪問http://127.0.0.1:8008/order/create/1/1/10/200接口產(chǎn)生一個請求，然后查看zipkin中的zipkin_annotations表，發(fā)現(xiàn)已經(jīng)將鏈路追蹤信息存放到MySQL數(shù)據(jù)庫中。

6.再次打開訪問Zipkin的UI界面，鏈路信息將不會消失。至此，我們便完成了Zipkin數(shù)據(jù)持久化到MySQL數(shù)據(jù)庫中的操作。

今天的內(nèi)容，你學會了嗎？關注「袁庭新」，干貨天天都不斷！