摘要：一個客戶端請求從發出到被響應經歷了哪些組件哪些微服務請求總時長每個組件所花時長等信息我們有必要了解和收集，以幫助我們定位性能瓶頸進行性能調優，因此監控整個微服務架構的調用鏈十分有必要，本文將闡述如何使用搭建微服務調用鏈追蹤中心。

一個完整的微服務系統包含多個微服務單元，各個微服務子系統存在互相調用的情況，形成一個 調用鏈。一個客戶端請求從發出到被響應 經歷了哪些組件、哪些微服務、請求總時長、每個組件所花時長 等信息我們有必要了解和收集，以幫助我們定位性能瓶頸、進行性能調優，因此監控整個微服務架構的調用鏈十分有必要，本文將闡述如何使用 Zipkin 搭建微服務調用鏈追蹤中心。

注： 本文首發于 My 公眾號 CodeSheep ，可 長按 或 掃描 下面的 小心心 來訂閱 ↓ ↓ ↓

正如 Ziplin官網 所描述，Zipkin是一款分布式的追蹤系統，其可以幫助我們收集微服務架構中用于解決延時問題的時序數據，更直白地講就是可以幫我們追蹤調用的軌跡。

Zipkin的設計架構如下圖所示：

要理解這張圖，需要了解一下Zipkin的幾個核心概念：

Reporter

在某個應用中安插的用于發送數據給Zipkin的組件稱為Report，目的就是用于追蹤數據收集

Span

微服務中調用一個組件時，從發出請求開始到被響應的過程會持續一段時間，將這段跨度稱為Span

Trace

從Client發出請求到完成請求處理，中間會經歷一個調用鏈，將這一個整個過程稱為一個追蹤（Trace）。一個Trace可能包含多個Span，反之每個Span都有一個上級的Trace。

Transport

一種數據傳輸的方式，比如最簡單的HTTP方式，當然在高并發時可以換成Kafka等消息隊列

看了一下基本概念后，再結合上面的架構圖，可以試著理解一下，只有裝配有Report組件的Client才能通過Transport來向Zipkin發送追蹤數據。追蹤數據由Collector收集器進行手機然后持久化到Storage之中。最后需要數據的一方，可以通過UI界面調用API接口，從而最終取到Storage中的數據。可見整體流程不復雜。

Zipkin官網給出了各種常見語言支持的OpenZipkin libraries：

本文接下來將 構造微服務追蹤的實驗場景 并使用 Brave 來輔助完成微服務調用鏈追蹤中心搭建！

利用Docker來部署Zipkin服務再簡單不過了：

docker run -d -p 9411:9411 
--name zipkin 
docker.io/openzipkin/zipkin

完成之后瀏覽器打開：localhost:9411可以看到Zipkin的可視化界面：

我們來構造一個如下圖所示的調用鏈：

圖中包含 一個客戶端 + 三個微服務：

Client：使用/servicea接口消費ServiceA提供的服務

ServiceA：使用/serviceb接口消費ServiceB提供的服務，端口8881

ServiceB：使用/servicec接口消費ServiceC提供的服務，端口8882

ServiceC：提供終極服務，端口8883

為了模擬明顯的延時效果，準備在每個接口的響應中用代碼加入3s的延時。

簡單起見，我們用SpringBt來實現三個微服務。

ServiceA的控制器代碼如下：

@RestController
public class ServiceAContorller {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/servicea”)
    public String servicea() {
        try {
            Thread.sleep( 3000 );
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return restTemplate.getForObject("http://localhost:8882/serviceb", String.class);
    }
}

ServiceB的代碼如下：

@RestController
public class ServiceBContorller {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/serviceb”)
    public String serviceb() {
        try {
            Thread.sleep( 3000 );
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return restTemplate.getForObject("http://localhost:8883/servicec", String.class);
    }
}

ServiceC的代碼如下：

@RestController
public class ServiceCContorller {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/servicec”)
    public String servicec() {
        try {
            Thread.sleep( 3000 );
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "Now, we reach the terminal call: servicec !”;
    }
}

我們將三個微服務都啟動起來，然后瀏覽器中輸入localhost:8881/servicea來發出請求，過了9s之后，將取到ServiceC中提供的微服務接口所返回的內容，如下圖所示：

很明顯，調用鏈可以正常work了！

那么接下來我們就要引入Zipkin來追蹤這個調用鏈的信息！

從Zipkin官網我們可以知道，借助OpenZipkin庫Brave，我們可以開發一個封裝Brave的公共組件，讓其能十分方便地嵌入到ServiceA，ServiceB，ServiceC服務之中，完成與Zipkin的通信。

為此我們需要建立一個新的基于Maven的Java項目：ZipkinTool

pom.xml中加入如下依賴：

    4.0.0

    com.hansonwang99
    ZipkinTool
    1.0-SNAPSHOT
    
        
            
                org.apache.maven.plugins
                maven-compiler-plugin
                
                    6
                    6
                
            
        
    
    jar

    
        
            org.springframework.boot
            spring-boot
            2.0.1.RELEASE
            provided
        
        
            org.springframework
            spring-webmvc
            4.3.7.RELEASE
            provided
        
        
            io.zipkin.brave
            brave-spring-web-servlet-interceptor
            4.0.6
        
        
            io.zipkin.brave
            brave-spring-resttemplate-interceptors
            4.0.6
        
        
            io.zipkin.reporter
            zipkin-sender-okhttp3
            0.6.12
        
        
            org.projectlombok
            lombok
            RELEASE
            compile
        
    

編寫ZipkinProperties類

其包含endpoint和service兩個屬性，我們最后是需要將該兩個參數提供給ServiceA、ServiceB、ServiceC微服務作為其application.properties中的Zipkin配置

@Data
@Component
@ConfigurationProperties("zipkin")
public class ZipkinProperties {
    private String endpoint;
    private String service;
}

用了lombok之后，這個類異常簡單！

【注意：關于lombok的用法，可以看這里】

編寫ZipkinConfiguration類

這個類很重要，在里面我們將Brave的BraveClientHttpRequestInterceptor攔截器注冊到RestTemplate的攔截器調用鏈中來收集請求數據到Zipkin中；同時還將Brave的ServletHandlerInterceptor攔截器注冊到調用鏈中來收集響應數據到Zipkin中

上代碼吧：

@Configuration
@Import({RestTemplate.class, BraveClientHttpRequestInterceptor.class, ServletHandlerInterceptor.class})
public class ZipkinConfiguration extends WebMvcConfigurerAdapter {

    @Autowired
    private ZipkinProperties zipkinProperties;

    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    private BraveClientHttpRequestInterceptor clientInterceptor;

    @Autowired
    private ServletHandlerInterceptor serverInterceptor;

    @Bean
    public Sender sender() {
        return OkHttpSender.create( zipkinProperties.getEndpoint() );
    }

    @Bean
    public Reporter reporter() {
        return AsyncReporter.builder(sender()).build();
    }

    @Bean
    public Brave brave() {
        return new Brave.Builder(zipkinProperties.getService()).reporter(reporter()).build();
    }

    @Bean
    public SpanNameProvider spanNameProvider() {
        return new SpanNameProvider() {
            @Override
            public String spanName(HttpRequest httpRequest) {
                return String.format(
                        "%s %s",
                        httpRequest.getHttpMethod(),
                        httpRequest.getUri().getPath()
                );
            }
        };
    }

    @PostConstruct
    public void init() {
        List interceptors = restTemplate.getInterceptors();
        interceptors.add(clientInterceptor);
        restTemplate.setInterceptors(interceptors);
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(serverInterceptor);
    }
}

ZipkinTool完成以后，我們需要在ServiceA、ServiceB、ServiceC三個SpringBt項目的application.properties中加入Zipkin的配置：

以ServiceA為例：

server.port=8881
zipkin.endpoint=http://你Zipkin服務所在機器的IP:9411/api/v1/spans
zipkin.service=servicea

我們最后依次啟動ServiceA、ServiceB、和ServiceC三個微服務，并開始實驗來收集鏈路追蹤數據 ！

瀏覽器打開Zipkin的UI界面，可以查看 依賴分析：

圖中十分清晰地展示了ServiceA、ServiceB和ServiceC三個服務之間的調用關系！
注意，該圖可縮放，并且每一個元素均可以點擊，例如點擊 ServiceB這個微服務，可以看到其調用鏈的上下游！

接下來我們看一下調用鏈相關，點擊 服務名，可以看到Zipkin監控到個所有服務：

同時可以查看Span，如以ServiceA為例，其所有REST接口都再下拉列表中：

以ServiceA為例，點擊 Find Traces，可以看到其所有追蹤信息：

點擊某個具體Trace，還能看到詳細的每個Span的信息，如下圖中，可以看到 A → B → C 調用過程中每個REST接口的詳細時間戳：

點擊某一個REST接口進去還能看到更詳細的信息，如查看/servicec這個REST接口，可以看到從發送請求到收到響應信息的所有詳細步驟：

作者更多的原創文章在此，歡迎觀賞

My Personal Blog

作者更多的SpringBt實踐文章在此：

Spring Boot應用監控實戰

SpringBoot應用部署于外置Tomcat容器

ElasticSearch搜索引擎在SpringBt中的實踐

初探Kotlin+SpringBoot聯合編程

Spring Boot日志框架實踐

SpringBoot優雅編碼之：Lombok加持

如果有興趣，也可以抽點時間看看作者一些關于容器化、微服務化方面的文章：

利用K8S技術棧打造個人私有云 連載文章

從一份配置清單詳解Nginx服務器配置

Docker容器可視化監控中心搭建

利用ELK搭建Docker容器化應用日志中心

RPC框架實踐之：Apache Thrift

RPC框架實踐之：Google gRPC

微服務調用鏈追蹤中心搭建

Docker容器跨主機通信

Docker Swarm集群初探

高效編寫Dockerfile的幾條準則