上一篇：《Spring Cloud入門教程(六)：API服務(wù)網(wǎng)關(guān)(Zuul) 下》

本人和同事撰寫的《Spring Cloud微服務(wù)架構(gòu)開發(fā)實戰(zhàn)》一書也在京東、當當?shù)葧晟霞埽蠹铱梢渣c擊這里前往購買，多謝大家支持和捧場！

Spring Cloud微服務(wù)架構(gòu)開發(fā)實戰(zhàn).png

當我們進行微服務(wù)架構(gòu)開發(fā)時，通常會根據(jù)業(yè)務(wù)來劃分微服務(wù)，各業(yè)務(wù)之間通過REST進行調(diào)用。一個用戶操作，可能需要很多微服務(wù)的協(xié)同才能完成，如果在業(yè)務(wù)調(diào)用鏈路上任何一個微服務(wù)出現(xiàn)問題或者網(wǎng)絡(luò)超時，都會導(dǎo)致功能失敗。隨著業(yè)務(wù)越來越多，對于微服務(wù)之間的調(diào)用鏈的分析會越來越復(fù)雜。

Spring Cloud Sleuth為服務(wù)之間調(diào)用提供鏈路追蹤。通過Sleuth可以很清楚的了解到一個服務(wù)請求經(jīng)過了哪些服務(wù)，每個服務(wù)處理花費了多長。從而讓我們可以很方便的理清各微服務(wù)間的調(diào)用關(guān)系。此外Sleuth可以幫助我們：

• 耗時分析: 通過Sleuth可以很方便的了解到每個采樣請求的耗時，從而分析出哪些服務(wù)調(diào)用比較耗時;
• 可視化錯誤: 對于程序未捕捉的異常，可以通過集成Zipkin服務(wù)界面上看到;
• 鏈路優(yōu)化: 對于調(diào)用比較頻繁的服務(wù)，可以針對這些服務(wù)實施一些優(yōu)化措施。

1. Sleuth+Log 示例代碼

我們先用最簡單的方式集成Sleuth，把Sleuth所跟蹤到的信息輸出到日志中。基礎(chǔ)代碼采用之前所構(gòu)建的商城項目。

1.1 改造Mall-Web

增加bootstrap.properties文件

為了能夠讓日志文件可以獲取到服務(wù)名稱，我們需要將原來配置在application.properties中的部分內(nèi)容移入到bootstrap.properties配置文件中，這是因為SpringBoot在啟動時會優(yōu)先掃描bootstrap配置源，從而能夠讓日志可以獲取到服務(wù)名稱。

server.port=8080

spring.application.name=MALL-WEB

修改application.properties文件

eureka.client.service-url.defaultZone=http://localhost:8260/eureka

logging.level.org.springframework=INFO
logging.level.org.springframework.web.servlet.DispatcherServlet=DEBUG

這里主要是把DispatcherServlet的日志級別修改為DEBUG。

修改Logback配文件

在resources目錄中增加一個名稱為: logback-spring.xml的文件，內(nèi)容如下：

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    ?
    <springProperty scope="context" name="springAppName" source="spring.application.name"/>

    <!-- Example for logging into the build folder of your project -->
    <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>?

    <property name="CONSOLE_LOG_PATTERN"
              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p})
            %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <Pattern>
                %d{yyyy-MM-dd HH:mm:ss SSS} [%thread] %-5level %logger{36} - %msg%n
            </Pattern>
        </layout>
    </appender>

    <!-- Appender to log to console -->
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <!-- Minimum logging level to be presented in the console logs-->
            <level>DEBUG</level>
        </filter>
        <encoder>
            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
            <charset>utf8</charset>
        </encoder>
    </appender>

    <!-- Appender to log to file -->?
    <appender name="flatfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_FILE}</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
            <maxHistory>7</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
            <charset>utf8</charset>
        </encoder>
    </appender>
    ?    ?
    <root level="INFO">
        <appender-ref ref="console"/>
        <!-- uncomment this to have also JSON logs -->
        <!--<appender-ref ref="logstash"/>-->
        <!--<appender-ref ref="flatfile"/>-->
    </root>
</configuration>

SpringCloud的參考手冊中提到：SLF4J MDC總是會自動進行設(shè)置，并且如果使用logback，那么trace/span的id則會立即顯示在日志中。其他的日志系統(tǒng)需要配置各自的格式來達到這樣的效果。默認的logging.pattern.level設(shè)置為%clr(%5p) %clr([${spring.application.name:},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}]){yellow} (這也是一個Spring Boot整合logback時有的特性)。 這就意味著，如果使用SLF4J時不需要手工配置該格式，而其它日志系統(tǒng)則必須手工進行配置，否則不會輸出。

修改POM文件

在pom.xml文件中增加如下依賴

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

1.2 改造Product-Service

改造方式與上面相同。

1.3 啟動測試

按照先后順序分別啟動Service-discovery、Product-Service和Mall-Web工程。然后在瀏覽器中輸入: http://localhost:8080/products。然后我們分別觀察Mall-Web和Product-Service控制臺中日志輸出，可以看到類似下面輸出：

2017-07-10 21:36:24.802 DEBUG [MALL-WEB,e23abdb6268af95d,e23abdb6268af95d,false] [MALL-WEB,e23abdb6268af95d,e23abdb6268af95d,,false] 92827 --- [nio-8080-exec-4] o.s.web.servlet.DispatcherServlet        : DispatcherServlet with name 'dispatcherServlet' processing GET request for [/products]

2017-07-10 21:36:24.838 DEBUG [PRODUCT-SERVICE,e23abdb6268af95d,c68a9b1c2ab8a025,false] [PRODUCT-SERVICE,e23abdb6268af95d,c68a9b1c2ab8a025,e23abdb6268af95d,false] 92782 --- [nio-2100-exec-3] o.s.web.servlet.DispatcherServlet        : DispatcherServlet with name 'dispatcherServlet' processing GET request for [/products]

日志中類似 [MALL-WEB,e23abdb6268af95d,e23abdb6268af95d,false]、[PRODUCT-SERVICE,e23abdb6268af95d,c68a9b1c2ab8a025,false] 的日志內(nèi)容它們的格式為： [appname,traceId,spanId,exportable]，也就是Sleuth的跟蹤數(shù)據(jù)。其中：

• appname: 為微服務(wù)的服務(wù)名稱;
• traceId\spanId: 為Sleuth鏈路追蹤的兩個術(shù)語，后面我們再仔細介紹;
• exportable 是否是發(fā)送給Zipkin。

2. Sleuth術(shù)語

因為Sleuth是根據(jù)Google的Dapper’s論文而來的，所以在術(shù)語上也借鑒了Dapper。

• Span: 最基本的工作單元。例如: 發(fā)送一個RPC就是一個新的span，同樣一次RPC的應(yīng)答也是。Span通過一個唯一的，長度為64位的ID來作為標識，另外，再使用一個64位ID用于服務(wù)調(diào)用跟蹤。Span也可以帶有其他數(shù)據(jù)，例如：描述，時間戳，鍵值對標簽，起始Span的ID，以及處理ID（通常使用IP地址）等等。 Span有起始和結(jié)束，它們用于跟蹤時間信息。Span應(yīng)該都是成對出現(xiàn)的，有始必有終，所以一旦創(chuàng)建了一個span，那就必須在未來某個時間點結(jié)束它。

提示： 起始的Span通常被稱為:root span。它的id通常也被作為一個跟蹤記錄的id。

• Trace: 一個樹結(jié)構(gòu)的Span集合。例如：在分布式大數(shù)據(jù)存儲中，可能每一次請求都是一次跟蹤記錄。
• Annotation: 用于記錄一個事件的時間信息。一些基礎(chǔ)核心的Annotation用于記錄請求的起始和結(jié)束時間，例如：
  • cs: 客戶端發(fā)送(Client Sent的縮寫)。這個annotation表示一個span的起始;
  • sr: 服務(wù)端接收(Server Received的縮寫)。表示服務(wù)端接收到請求，并開始處理。如果減去cs的時間戳，則可以計算出網(wǎng)絡(luò)傳輸耗時。
  • ss: 服務(wù)端完成請求處理，應(yīng)答信息被發(fā)回客戶端(Server Sent的縮寫)。如果減去sr的時間戳，則可以計算出服務(wù)端處理請求的耗時。
  • cr: 客戶端接收(Client Received的縮寫)。標志著Span的結(jié)束。客戶端成功的接收到服務(wù)端的應(yīng)答信息。如果減去cs的時間戳，則可以計算出請求的響應(yīng)耗時。

下圖，通過可視化的方式描述了Span和Trace的概念：

trace-id

圖中每一個顏色都表示著一個span（總共7個span，從A到G）。它們都有以下這些數(shù)據(jù)信息：

Trace Id = X
Span Id = D
Client Sent

表示該Span的Trace-Id為X，Span-Id為D。相應(yīng)的事件為Client Sent。

這些Span的上下級關(guān)系可以通過下圖來表示：

parents

3. 整合Zipkin服務(wù)

Zipkin是一個致力于收集分布式服務(wù)的時間數(shù)據(jù)的分布式跟蹤系統(tǒng)。其主要涉及以下四個組件：

• collector: 數(shù)據(jù)采集;
• storage: 數(shù)據(jù)存儲;
• search: 數(shù)據(jù)查詢;
• UI: 數(shù)據(jù)展示.

Zipkin提供了可插拔數(shù)據(jù)存儲方式：In-Memory、MySql、Cassandra以及Elasticsearch。接下來的測試為方便直接采用In-Memory方式進行存儲，個人推薦Elasticsearch，特別是后續(xù)當我們需要整合ELK時。

ZipKin在Github源碼地址為:https://github.com/openzipkin/zipkin。

ZipKin運行環(huán)境需要Jdk8支持。

在本篇中我們僅通過Http的方式向Zipkin提供跟蹤數(shù)據(jù)，關(guān)于使用stream的方式后續(xù)講到Spring Cloud Bus的時候再說明。我們所要搭建的系統(tǒng)架構(gòu)如下(做了精簡)：

zipkin-070

3.1 構(gòu)建Zipkin-Server

編寫pom.xml文件

還是繼承自我們之前的parent：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>twostepsfromjava.cloud</groupId>
        <artifactId>twostepsfromjava-cloud-parent</artifactId>
        <version>1.0.0-SNAPSHOT</version>
        <relativePath>../parent</relativePath>
    </parent>
    
    <artifactId>zipkin-server</artifactId>
    <name>Spring Cloud Sample Projects: Zipkin Server</name>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>io.zipkin.java</groupId>
            <artifactId>zipkin-server</artifactId>
        </dependency>
        <dependency>
            <groupId>io.zipkin.java</groupId>
            <artifactId>zipkin-autoconfigure-ui</artifactId>
            <scope>runtime</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

這里需要說明的時zipkin-autoconfigure-ui包提供了可視化界面。

編寫啟動類

/**
 * TwoStepsFromJava Cloud -- Zipkin Server Project
 *
 * @author CD826(CD826Dong@gmail.com)
 * @since 1.0.0
 */
@SpringBootApplication
@EnableZipkinServer
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

}

這里在Application的注解中增加@EnableZipkinServer，開啟Zipkin服務(wù)。

編寫bootstrap.properties配置文件

server.port=8240

spring.application.name=ZIPKIN-SERVER

我們把Zipkin服務(wù)的端口設(shè)置為：8240。

3.2 修改Mall-Web工程

修改pom.xml文件

在pom文件中增加以下依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

同時可以刪除之前的：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

應(yīng)為，在spring-cloud-starter-zipkin中已經(jīng)包含了對spring-cloud-starter-sleuth的依賴。

修改application.properties配置文件

在application.properties增加以下內(nèi)容：

spring.zipkin.base-url=http://localhost:8240
spring.sleuth.sampler.percentage=1.0

spring.zipkin.base-url指定了Zipkin服務(wù)器的地址，spring.sleuth.sampler.percentage將采樣比例設(shè)置為1.0，也就是全部都需要。關(guān)于采樣可以參考下面的說明。

3.3 修改Product-Service工程

改造方式與上面相同。

3.4 啟動測試

按照先后順序分別啟動Service-discovery、Zipkin-Server、Product-Service和Mall-Web工程。

查看Zipkin服務(wù)器

啟動后我們可以訪問：http://localhost:8240，可以看到如下界面：

zipkin-010

說明Zipkin服務(wù)器啟動成功。

訪問幾次Mall-Web所提供的服務(wù)

我們在瀏覽器中訪問幾次Mall-Web所提供的服務(wù)，然后轉(zhuǎn)到Zipkin服務(wù)器，可以看到如下界面：

zipkin-020

可以看到，Zipkin已經(jīng)獲取到幾次服務(wù)的調(diào)用跟蹤信息了。我們可以點擊其中的一個請求，可以看到如下界面：

zipkin-030

該界面對本次請求進行了更詳細的展現(xiàn)。同樣我們還可以再點擊，以查看更為詳細的數(shù)據(jù)，可以看到如下界面：

zipkin-040

在該界面中我們可以看到之前所講的各個時間跟蹤信息。

在Zipkin界面中我們還可以點擊[Dependencies]查看各服務(wù)之間的依賴關(guān)系，如下圖：

zipkin-050

錯誤信息

Zipkin可以在跟蹤記錄中顯示錯誤信息。當異常拋出并且沒有捕獲，Zipkin就會自動的換個顏色顯示。在跟蹤記錄的清單中，當看到紅色的記錄時，就表示有異常拋出了。如上面圖中的第一個根據(jù)數(shù)據(jù)就顯示了錯誤信息。我們還可以點擊進去以獲取更詳細的錯誤信息。

3.5 采樣率

在生成環(huán)境中，由于業(yè)務(wù)量比較大，所產(chǎn)生的跟蹤數(shù)據(jù)可能會非常大，如果全部采集一是對業(yè)務(wù)有一定影響，二是對存儲壓力也會比較大，所以采樣變的很重要。一般來說，我們也不需要把每一個發(fā)生的動作都進行記錄。

Spring Cloud Sleuth有一個Sampler策略，可以通過這個實現(xiàn)類來控制采樣算法。采樣器不會阻礙span相關(guān)id的產(chǎn)生，但是會對導(dǎo)出以及附加事件標簽的相關(guān)操作造成影響。 Sleuth默認采樣算法的實現(xiàn)是Reservoir sampling，具體的實現(xiàn)類是PercentageBasedSampler，默認的采樣比例為: 0.1(即10%)。不過我們可以通過spring.sleuth.sampler.percentage來設(shè)置，所設(shè)置的值介于0.0到1.0之間，1.0則表示全部采集。

也可以通過實現(xiàn)bean的方式來設(shè)置采樣為全部采樣(AlwaysSampler)或者不采樣(NeverSampler)：如

@Bean public Sampler defaultSampler() {
    return new AlwaysSampler();
}

這也是為何之前我們需要修改Mall-Web和Product-Service中的spring.sleuth.sampler.percentage配置，如果是默認值很可能我們在Zipkin服務(wù)器上根本看不到。

你可以到這里下載本篇的代碼。