zipkin分佈式追蹤系統原理與實現

前言

傳統單機系統在使用過程中，如果某個請求響應過慢或是響應出錯，開發人員可以清楚知道某個請求出了問題，查看日誌可以定位到具體方法。但是在分佈式系統中，倘若客戶端一個請求到達服務器後，由多個服務協作完成。比如：服務A調用服務B，服務B又調用服務C和服務D，服務D又調用服務E，那麼想要知道是哪個服務處理時間過長或是處理異常導致這個請求響應緩慢或中斷的話，就需要開發人員一個服務接一個服務的去機器上查看日誌，先定位到出問題的服務，再定位出問題的具體地方。試想一下，隨着系統越來越壯大，服務越來越多，一個請求對應處理的服務調用鏈越來越長，這種排查方式何其艱難。爲了解決這種問題，便誕生了各種分佈式場景中追蹤問題的解決方案，zipkin就是其中之一。

整體結構長啥樣

一個獨立的分佈式追蹤系統，客戶端存在於應用中（即各服務中），應具備追蹤信息生成、採集發送等功能，而服務端應該包含以下基本的三個功能：

• 信息收集：用來收集各服務端採集的信息，並對這些信息進行梳理存儲、建立索引。
• 數據存儲：存儲追蹤數據。
• 查詢服務：提供查詢請求鏈路信息的接口。

zipkin 整體結構圖如下：

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

• collector 就是信息收集器,作爲一個守護進程，它會時刻等待客戶端傳遞過來的追蹤數據，對這些數據進行驗證、存儲以及創建查詢需要的索引。
• storage 是存儲組件。zipkin 默認直接將數據存在內存中，此外支持使用Cassandra、ElasticSearch 和 Mysql。
• search 是一個查詢進程，它提供了簡單的JSON API來供外部調用查詢。
• web UI 是zipkin的服務端展示平臺，主要調用search提供的接口，用圖表將鏈路信息清晰地展示給開發人員。

zipkin的客戶端主要負責根據應用的調用情況生成追蹤信息，並且將這些追蹤信息發送至zipkin由收集器接收。各語言支持均不同，具體可以查看zipkin官網,java語言的支持就是brave。上面結構圖中，有追蹤器就是指集成了brave。

基本概念瞭解下

在使用zipkin之前，先了解一下Trace和Span這兩個基本概念。一個請求到達應用後所調用的所有服務所有服務組成的調用鏈就像一個樹結構（如下圖），我們追蹤這個調用鏈路得到的這個樹結構可以稱之爲Trace。

在一次Trace中，每個服務的每一次調用，就是一個基本工作單元，就像上圖中的每一個樹節點，稱之爲span。每一個span都有一個id作爲唯一標識，同樣每一次Trace都會生成一個traceId在span中作爲追蹤標識，另外再通過一個parentId標明本次調用的發起者（就是發起者的span-id）。當span有了上面三個標識後，就可以很清晰的將多個span進行梳理串聯，最終歸納出一條完整的跟蹤鏈路。此外，span還會有其他數據，比如：名稱、節點上下文、時間戳以及K-V結構的tag信息等等（Zipkin v1核心註解如“cs”和“sr”已被Span.Kind取代，詳情查看zipkin-api，本文會在入門的demo介紹完後對具體的Span數據模型進行說明）。

具體怎麼追蹤的

追蹤器位於應用程序上，負責生成相關ID、記錄span需要的信息，最後通過傳輸層傳遞給服務端的收集器。我們首先思考下面幾個問題：

• 每個span需要的基本信息何時生成？
• 哪些信息需要隨着服務調用傳遞給服務提供方？
• 什麼時候發送span至zipkin 服務端？
• 以何種方式發送span?

一個 span 表示一次服務調用，那麼追蹤器必定是被服務調用發起的動作觸發，生成基本信息，同時爲了追蹤服務提供方對其他服務的調用情況，便需要傳遞本次追蹤鏈路的traceId和本次調用的span-id。服務提供方完成服務將結果響應給調用方時，需要根據調用發起時記錄的時間戳與當前時間戳計算本次服務的持續時間進行記錄，至此這次調用的追蹤span完成，就可以發送給zipkin服務端了。但是需要注意的是，發送span給zipkin collector不得影響此次業務結果，其發送成功與否跟業務無關，因此這裏需要採用異步的方式發送，防止追蹤系統發送延遲與發送失敗導致用戶系統的延遲與中斷。下圖就表示了一次http請求調用的追蹤流程（基於zipkin官網提供的流程圖）：

可以看出服務A請求服務B時先被追蹤器攔截，記錄tag信息、時間戳，同時將追蹤標識添加進http header中傳遞給服務B，在服務B響應後，記錄持續時間，最終採取異步的方式發送給zipkin收集器。span從被追蹤的服務傳送到Zipkin收集器有三種主要的傳送方式：http、Kafka以及Scribe（Facebook開源的日誌收集系統）。

1分鐘安裝zipkin

上文對基於zipkin實現分佈式追蹤系統的原理做了全面的說明，這裏簡單介紹一下zipkin的安裝方法，下載jar包，直接運行。簡單粗暴，但要注意必須jdk1.8及以上。其餘兩種安裝方式見官方介紹。

wget -O zipkin.jar 'https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec'
java -jar zipkin.jar

啓動成功後，打開瀏覽器訪問zipkin的webUI，輸入http://ip:9411/,顯示頁面如下圖。具體使用後面介紹。

寫個Demo用起來（Spring Boot整合zipkin）

java版客戶端 Brave的官方文檔很少，都在github裏。小白當時找的那叫個頭疼啊，網上各路大神寫的博客中的代碼你扒下來換最新的依賴後都會顯示那些類被標記爲過時，不建議使用。

• brave 源碼地址：github.com/openzipkin/…
• 官方demo地址：github.com/openzipkin/…
• 友情提示：本節代碼較多，註釋還算詳細，介紹文字偏少。 小白寫的demo結構如下圖，分別創建了service1、service2、service3三個boot應用，將brave整合部分單獨作爲一個module，這樣可以嵌入服務中複用，避免重複編碼。

maven 依賴（zipkin_client）

` com.ycg zipkin_client 1.0-SNAPSHOT zipkin_client

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>6</source>
                <target>6</target>
            </configuration>
        </plugin>
    </plugins>
</build>
<packaging>jar</packaging>

<properties>
    <java.version>1.8</java.version>
    <spring-boot.version>2.1.1.RELEASE</spring-boot.version>
    <brave.version>5.6.0</brave.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>io.zipkin.brave</groupId>
            <artifactId>brave-bom</artifactId>
            <version>${brave.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.apache.httpcomponents</groupId>
        <artifactId>httpclient</artifactId>
    </dependency>

    <!-- zipkin客戶端依賴 -->
    <dependency>
        <groupId>io.zipkin.brave</groupId>
        <artifactId>brave</artifactId>
    </dependency>
    <dependency>
        <groupId>io.zipkin.reporter2</groupId>
        <artifactId>zipkin-sender-okhttp3</artifactId>
    </dependency>

    <!-- 添加記錄MVC的類、方法名到span的依賴 -->
    <dependency>
        <groupId>io.zipkin.brave</groupId>
        <artifactId>brave-instrumentation-spring-webmvc</artifactId>
    </dependency>
    <!-- 添加brave的httpclient依賴 -->
    <dependency>
        <groupId>io.zipkin.brave</groupId>
        <artifactId>brave-instrumentation-httpclient</artifactId>
    </dependency>
    <!-- 集成Brave上下文的log -->
    <dependency>
        <groupId>io.zipkin.brave</groupId>
        <artifactId>brave-context-slf4j</artifactId>
    </dependency>
</dependencies>

配置類編寫（zipkin_client）

package com.ycg.zipkin_client;

import brave.CurrentSpanCustomizer;
import brave.SpanCustomizer;
import brave.Tracing;
import brave.context.slf4j.MDCScopeDecorator;
import brave.http.HttpTracing;
import brave.httpclient.TracingHttpClientBuilder;
import brave.propagation.B3Propagation;
import brave.propagation.ExtraFieldPropagation;
import brave.propagation.ThreadLocalCurrentTraceContext;
import brave.servlet.TracingFilter;
import brave.spring.webmvc.SpanCustomizingAsyncHandlerInterceptor;
import org.apache.http.impl.client.CloseableHttpClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.boot.web.client.RestTemplateCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.web.client.RestTemplate;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
import zipkin2.Span;
import zipkin2.reporter.AsyncReporter;
import zipkin2.reporter.Sender;
import zipkin2.reporter.okhttp3.OkHttpSender;

import javax.servlet.Filter;

/**
 * 針對mvc controller 和 restTemplate 的 zipkin客戶端配置
 */
@Configuration
@Import(SpanCustomizingAsyncHandlerInterceptor.class)
public class ZipkinClientConfiguration implements WebMvcConfigurer {

    /**
     * 配置如何向 zipkin 發送 span
     */
    @Bean
    Sender sender() {
        // 注意這裏更換爲自己安裝的zipkin所在的主機IP
        return OkHttpSender.create("http://10.150.27.36:9411/api/v2/spans");
    }

    /**
     * 配置如何把 span 緩衝到給 zipkin 的消息
     */
    @Bean
    AsyncReporter<Span> spanReporter() {
        return AsyncReporter.create(sender());
    }

    /**
     * 配置跟蹤過程中的Trace信息
     */
    @Bean
    Tracing tracing(@Value("${spring.application.name}") String serviceName) {
        return Tracing.newBuilder()
                .localServiceName(serviceName)  // 設置節點名稱
                .propagationFactory(ExtraFieldPropagation.newFactory(B3Propagation.FACTORY, "user-name"))
                .currentTraceContext(ThreadLocalCurrentTraceContext.newBuilder()
                        .addScopeDecorator(MDCScopeDecorator.create()) // puts trace IDs into logs
                        .build()
                )
                .spanReporter(spanReporter()).build();
    }

    /** 注入可定製的Span */
    @Bean
    SpanCustomizer spanCustomizer(Tracing tracing) {
        return CurrentSpanCustomizer.create(tracing);
    }

    /** 決定如何命名和標記span。 默認情況下，它們的名稱與http方法相同 */
    @Bean
    HttpTracing httpTracing(Tracing tracing) {
        return HttpTracing.create(tracing);
    }

    /** 導入過濾器，該過濾器中會爲http請求創建span */
    @Bean
    Filter tracingFilter(HttpTracing httpTracing) {
        return TracingFilter.create(httpTracing);
    }

    /**
     * 導入 zipkin 定製的 RestTemplateCustomizer
     */
    @Bean
    RestTemplateCustomizer useTracedHttpClient(HttpTracing httpTracing) {
        final CloseableHttpClient httpClient = TracingHttpClientBuilder.create(httpTracing).build();
        return new RestTemplateCustomizer() {
            @Override public void customize(RestTemplate restTemplate) {
                restTemplate.setRequestFactory(new HttpComponentsClientHttpRequestFactory(httpClient));
            }
        };
    }

    @Autowired
    SpanCustomizingAsyncHandlerInterceptor webMvcTracingCustomizer;

    /** 使用應用程序定義的Web標記裝飾服務器span */
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(webMvcTracingCustomizer);
    }
}

boot 服務模塊

1. maven依賴：boot+web起步依賴，另引入上面封裝的zipkin_client模塊依賴。

<dependency>
    <groupId>com.ycg</groupId>
    <artifactId>zipkin_client</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

2. 啓動類導入 zipkin_client模塊 的配置類 ZipkinClientConfiguration。

@SpringBootApplication
@Import(ZipkinClientConfiguration.class)
public class Service1Application {
    public static void main(String[] args) {
        SpringApplication.run(Service1Application.class, args);
    }
}

3. 編寫Controller，service2和service3的代碼類似。由於zipkin配置類那邊向IOC容器注入zipkin定製的RestTemplateCustomizer,注意這裏使用注入的RestTemplateBuilder創建restTemplate。

@EnableAutoConfiguration
@RestController
public class Service1Controller {
private RestTemplate restTemplate;

@Autowired Service1Controller(RestTemplateBuilder restTemplateBuilder) {
    this.restTemplate = restTemplateBuilder.build();
}

@GetMapping(value = <span class="hljs-string">"/service1"</span>)
public String <span class="hljs-function"><span class="hljs-title">getService</span></span>() {
    try {
        Thread.sleep(100);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    <span class="hljs-built_in">return</span> <span class="hljs-string">"service1 sleep 100ms -&gt;"</span> + restTemplate.getForObject(<span class="hljs-string">"http://localhost:8882/service2"</span>,String.class);
}

}

設置三個boot服務的內置tomcat端口號分別爲8881、8882、8883。

啓動驗證

到這裏，就完成了一個springboot整合zipkin簡單的demo，分別啓動三個boot應用後，在瀏覽器訪問http://localhost:8881/service1，瀏覽器顯示如下圖：

打開zipkin-webUI,點擊查詢，便可以查到剛纔請求的追蹤鏈路，如下圖。

繼續點擊查到的鏈路信息，便可查看該條追蹤鏈路的詳細信息。這裏採用縮進的形式展示了整條調用鏈路，並且再每個調用後表明了所花費時間。點擊右上角json按鈕，便能看到本次trace的json數據。

span數據結構詳解

json結構概覽與各字段含義

一次追蹤鏈路會包含很多個span,因此一個trace便是一個數組，其標準的json結構如下：

[
  {
    "traceId": "string",    // 追蹤鏈路ID
    "name": "string",       // span名稱，一般爲方法名稱
    "parentId": "string",   // 調用者ID
    "id": "string",         // spanID
    "kind": "CLIENT",       // 替代zipkin v1的註解中的四個核心狀態，詳細介紹見下文
    "timestamp": 0,         // 時間戳，調用時間
    "duration": 0,          // 持續時間-調用的服務所消耗的時間
    "debug": true,          
    "shared": true,
    "localEndpoint": {      // 本地網絡節點上下文
      "serviceName": "string",
      "ipv4": "string",
      "ipv6": "string",
      "port": 0
    },
    "remoteEndpoint": {    // 遠端網絡節點上下文
      "serviceName": "string",
      "ipv4": "string",
      "ipv6": "string",
      "port": 0
    },
    "annotations": [      // value通常是縮寫代碼，對應的時間戳表示代碼標記事件的時間
      {
        "timestamp": 0,
        "value": "string"
      }
    ],
    "tags": {        // span的上下文信息，比如：http.method、http.path
      "additionalProp1": "string",
      "additionalProp2": "string",
      "additionalProp3": "string"
    }
  }
]

再看Demo中追蹤鏈路的JSON數據

相信看到這裏的小夥伴回頭再看demo中鏈路的json數據，應該可以明白具體的意思了。這裏再梳理一下。追蹤鏈路的JSON數據如下（建議直接跳過數據看下面分析）：

[
  {
    "traceId": "3857b4a56c99e9f8",
    "parentId": "7dd11a047eb02622",
    "id": "e5427222edb62a7c",
    "kind": "SERVER",
    "name": "get /service3",
    "timestamp": 1547458424863333,
    "duration": 409599,
    "localEndpoint": {
      "serviceName": "server3",
      "ipv4": "172.30.22.138"
    },
    "remoteEndpoint": {
      "ipv4": "127.0.0.1",
      "port": 52845
    },
    "tags": {
      "http.method": "GET",
      "http.path": "/service3",
      "mvc.controller.class": "Service3Controller",
      "mvc.controller.method": "getService"
    },
    "shared": true
  },
  {
    "traceId": "3857b4a56c99e9f8",
    "parentId": "7dd11a047eb02622",
    "id": "e5427222edb62a7c",
    "kind": "CLIENT",
    "name": "get",
    "timestamp": 1547458424756985,
    "duration": 520649,
    "localEndpoint": {
      "serviceName": "server2",
      "ipv4": "172.30.22.138"
    },
    "tags": {
      "http.method": "GET",
      "http.path": "/service3"
    }
  },
  {
    "traceId": "3857b4a56c99e9f8",
    "parentId": "3857b4a56c99e9f8",
    "id": "7dd11a047eb02622",
    "kind": "SERVER",
    "name": "get /service2",
    "timestamp": 1547458424446556,
    "duration": 880044,
    "localEndpoint": {
      "serviceName": "server2",
      "ipv4": "172.30.22.138"
    },
    "remoteEndpoint": {
      "ipv4": "127.0.0.1",
      "port": 52844
    },
    "tags": {
      "http.method": "GET",
      "http.path": "/service2",
      "mvc.controller.class": "Service2Controller",
      "mvc.controller.method": "getService"
    },
    "shared": true
  },
  {
    "traceId": "3857b4a56c99e9f8",
    "parentId": "3857b4a56c99e9f8",
    "id": "7dd11a047eb02622",
    "kind": "CLIENT",
    "name": "get",
    "timestamp": 1547458424271786,
    "duration": 1066836,
    "localEndpoint": {
      "serviceName": "server1",
      "ipv4": "172.30.22.138"
    },
    "tags": {
      "http.method": "GET",
      "http.path": "/service2"
    }
  },
  {
    "traceId": "3857b4a56c99e9f8",
    "id": "3857b4a56c99e9f8",
    "kind": "SERVER",
    "name": "get /service1",
    "timestamp": 1547458424017344,
    "duration": 1358590,
    "localEndpoint": {
      "serviceName": "server1",
      "ipv4": "172.30.22.138"
    },
    "remoteEndpoint": {
      "ipv6": "::1",
      "port": 52841
    },
    "tags": {
      "http.method": "GET",
      "http.path": "/service1",
      "mvc.controller.class": "Service1Controller",
      "mvc.controller.method": "getService"
    }
  }
]

我們從下往上看，這纔是請求最開始的地方。首先看最下面的span（3857b4a56c99e9f8）。請求（http://localhost:8881）是由瀏覽器發出,那麼當請求到達服務1時，作爲服務端便會生成kind爲SERVER的span，其中duration便是本次請求到後端後的淨處理時間，localEndpoint是server1的節點信息，remoteEndpoint的調用方也就是瀏覽器的節點信息。

接着服務1需要調用服務2的服務，這時服務1是作爲客戶端發出請求的。因此會記錄出從下往上第二個span(7dd11a047eb02622),一個客戶端span,也就是kind=CLIENT。localEndpoint還是自己，同時tag裏添加了發出的請求信息，duration表示發出/service2的請求後，到接收到server2的響應所消耗的時間。再往上span(7dd11a047eb02622)，就是server2接收到server1的請求後記錄的SERVER span。剩下的同理，小白就不多說了。

結束語

到這裏就介紹完了基於zipkin實現分佈式追蹤系統的基本原理與實現，當然這只是一個入門，追蹤信息是全量收集還是採樣收集，設置什麼樣的採樣頻率，異步發送span使用http還是kafka，這些問題都是需要在生產環境中根據實際場景綜合考量的。就本文而言，小白覺得只要你仔細閱讀了，認真思考了，一定還是收穫不少的，當然有深入研究的小夥伴除外。後續小白會深入Brave的源碼瞭解具體的追蹤實現，如有錯誤，也請多多拍磚多多交流。

參考

zipkin官網

zipkin-api

官方示例：brave-webmvc-example