rabbitmq+sleuth+zinkip 分散式鏈路追蹤

我們都知道，微服務之間通過feign傳遞，在複雜的微服務架構系統中，幾乎每一個前端請求都會形成一個複雜的分散式服務調用鏈路，在每條鏈路中任何一個依賴服務出現延遲超時或者錯誤都有可能引起整個請求最後的失敗。當業務流程足夠複雜時，一個完整的HTTP請求調用鏈一般會經過多個微服務系統，要通過日誌來跟蹤一整 ...

我們都知道，微服務之間通過feign傳遞，在複雜的微服務架構系統中，幾乎每一個前端請求都會形成一個複雜的分散式服務調用鏈路，在每條鏈路中任何一個依賴服務出現延遲超時或者錯誤都有可能引起整個請求最後的失敗。當業務流程足夠複雜時，一個完整的HTTP請求調用鏈一般會經過多個微服務系統，要通過日誌來跟蹤一整個調用鏈變得不再那麼簡單。通過sleuth可以很方便的看出每個採集請求的耗時情況，分析出哪些服務調用比較耗時，當服務調用的耗時隨著請求量的增大而增大時，可以針對業務做一些優化措施。所以我們可以通過我們可以通過Spring Cloud Sleuth來解決這個問題。這裡我們將演示如何通過Spring Cloud Sleuth來追蹤這個過程，並藉助Zipkin以圖形化界面的方式展示。展示之前，分別介紹一下rabbitmq、sleuth、zinkip。

rabbitmq
- RabbitMQ是實現了高級消息隊列協議（AMQP）的開源消息代理軟體（亦稱面向消息的中間件）。RabbitMQ伺服器是用Erlang語言編寫的，而群集和故障轉移是構建在開放電信平臺框架上的。所有主要的編程語言均有與代理介面通訊的客戶端庫。
sleuth和zinkip
- sleuth 是spring cloud的組成部分之一，為springcloud應用實現了一種分散式追蹤解決方案，其相容了zinkip,HTrace和log-based追蹤
- Zipkin 是一款開源的分散式實時數據追蹤系統（Distributed Tracking System），基於 Google Dapper 的論文設計而來，由 Twitter公司開發貢獻。其主要功能是聚集來自各個異構系統的實時監控數據，用來追蹤微服務架構下的系統延時問題。Zipkin 的用戶界面可以呈現一幅關聯圖表，以顯示有多少被追蹤的請求通過了每一層應用。Zipkin 以 Trace 結構表示對一次請求的追蹤，又把每個 Trace 拆分為若幹個有依賴關係的 Span。在微服務架構中，一次用戶請求可能會由後臺若幹個服務負責處理，那麼每個處理請求的服務就可以理解為一個 Span（可以包括 API 服務，緩存服務，資料庫服務以及報表服務等）。當然這個服務也可能繼續請求其他的服務，因此 Span 是一個樹形結構，以體現服務之間的調用關係。Zipkin 的用戶界面除了可以查看 Span 的依賴關係之外，還以瀑布圖的形式顯示了每個 Span 的耗時情況，可以一目瞭然的看到各個服務的性能狀況。

sleuth中的一些術語

Span：基本工作單元，例如，在一個新建的span中發送一個RPC等同於發送一個回應請求給RPC，span通過一個64位ID唯一標識，trace以另一個64位ID表示，span還有其他數據信息，比如摘要、時間戳事件、關鍵值註釋(tags)、span的ID、以及進度ID(通常是IP地址) ,span在不斷的啟動和停止，同時記錄了時間信息，當你創建了一個span，你必須在未來的某個時刻停止它。

Trace：一系列spans組成的一個樹狀結構，例如，如果你正在跑一個分散式工程，你可能需要創建一個trace。

Annotation：用來及時記錄一個事件的存在，一些核心annotations用來定義一個請求的開始和結束

cs - Client Sent -客戶端發起一個請求，這個annotion描述了這個span的開始

sr - Server Received -服務端獲得請求並準備開始處理它，如果將其sr減去cs時間戳便可得到網路延遲

ss - Server Sent -註解表明請求處理的完成(當請求返回客戶端)，如果ss減去sr時間戳便可得到服務端需要的處理請求時間

cr - Client Received -表明span的結束，客戶端成功接收到服務端的回覆，如果cr減去cs時間戳便可得到客戶端從服務端獲取回覆的所有所需時間

接下來就開始搭建
這裡cloud版本用的Greenwich.SR1，boot使用的是2.1.6

1.在pom.xml中引入sleuth依賴

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

2.模擬兩個日誌這兩個服務之間通過feign調用，由test調用system，這裡本來有一個註冊中心，這裡就不在演示了

test模塊

@Slf4j
@RestController
public class TestController {

	@Autowired
	private IHelloService helloService;

	@GetMapping("hello")
	public String hello(String name) {
    log.info("Feign調用system的/hello服務");
    return this.helloService.hello(name);
   }
}

在test模塊的service包下創建IHelloService

@FeignClient(value = "system",contextId = "helloServiceClient")
public interface IHelloService {
	@GetMapping("hello")
	String hello(@RequestParam("name") String name);
}

system 模塊

@Slf4j
@RestController
public class TestController {

	@GetMapping("hello")
	public String hello(String name) {
   		log.info("/hello服務被調用");
    	return "hello" + name;
	}
}

3.訪問介面 localhost:8202/test/hello?name=sleuth：會出現兩個我們自定義的日誌

啟動的時候查看test模塊產生的

2019-08-23 14:22:51.774  INFO [test,72bb0469bee07104,72bb0469bee07104,false] 22728 --- [nio-8202-exec-1] c.m.f.s.test.controller.TestController   : Feign調用system的/hello服務

啟動的時候查看system模塊產生的

2019-08-23 14:22:52.469  INFO [system,72bb0469bee07104,43597a6edded6f2e,false] 812 --- [nio-8201-exec-2] c.m.f.s.s.controller.TestController      : /hello服務被調用

可以看到，日誌里出現了[Test,72bb0469bee07104,72bb0469bee07104,false]信息，這些信息由Spring Cloud Sleuth生成，用於跟蹤微服務請求鏈路。這些信息包含了4個部分的值，它們的含義如下：

system微服務的名稱，與spring.application.name對應；
72bb0469bee07104稱為Trace ID，在一條完整的請求鏈路中，這個值是固定的。觀察上面的日誌即可證實這一點；
43597a6edded6f2e稱為Span ID，它表示一個基本的工作單元；
false表示是否要將該信息輸出到Zipkin等服務中來收集和展示，這裡我們還沒有集成Zipkin，所以為false。

下麵我們來整合Zipkin

在整合Zipkin之前，我們需要先搭建RabbitMQ。RabbitMQ用於收集Sleuth提供的追蹤信息，然後Zipkin Server從RabbitMQ里獲取，這樣可以提升性能。

在安裝RabbitMQ之前，需要先安裝Erlang/OTP，下載地址為：http://www.erlang.org/downloads/，下載exe文件安裝即可。
安裝完畢後，下載RabbitMQ，下載地址為：
http://www.rabbitmq.com/install-windows.html，下載exe文件安裝即可。

安裝完RabbitMQ之後，我們到RabbitMQ安裝目錄的sbin下執行如下命令

rabbitmq-plugins enable rabbitmq_management

然後在瀏覽器中輸入http://localhost:15672，預設用戶名和密碼都是guest，登錄後可看到:

點擊Admin Tab頁面，新增一個用戶：

用戶名為febs，密碼為123456，角色為管理員。新添加的用戶還是No access狀態，需要進一步對該用戶進行授權後，方可以遠程通過該用戶名訪問。點擊該新增用戶名。進入授權頁面，點擊Set permission按鈕，進行用戶授權操作。
安裝好RabbitMQ後，我們開始整合Zipkin。在較低版本的Spring Cloud中，我們可以自己搭建Zipkin Server，現在我們只能使用官方搭建好的Zipkin Server，地址為：https://github.com/openzipkin/zipkin

在cmd視窗下運行下麵這條命令（windows下沒有curl環境的話，可以在git bash中運行這條命令），下載zipkin.jar：

curl -sSL https://zipkin.io/quickstart.sh | bash -s

如果下載速度極慢，可以複製鏈接到迅雷下載中下載，下載後重命名為zipkin.jar即可。

zipkin支持將追蹤信息保存到MySQL資料庫，所以在運行zipkin.jar之前，我們先準備好相關庫表，SQL腳本地址為：

https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql。

庫表準備好後，運行下麵這條命令啟動zipkin.jar：

java -jar zipkin.jar --server.port=8402 --zipkin.storage.type=mysql --zipkin.storage.mysql.db=febs_cloud_base --zipkin.storage.mysql.username=root --zipkin.storage.mysql.password=123456 --zipkin.storage.mysql.host=localhost --zipkin.storage.mysql.port=3306 --zipkin.collector.rabbitmq.addresses=localhost:5672 --zipkin.collector.rabbitmq.username=febs --zipkin.collector.rabbitmq.password=123456

上面命令指定了資料庫鏈接和RabbitMQ鏈接信息。更多可選配置可以解壓zipkin.jar，查看zipkin\BOOT-INF\classes路徑下的zipkin-server-shared.yml配置類源碼。

啟動好zipkin.jar後，在對應模塊的pom里引入如下依賴：

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

修改對應模塊的application.yml

spring:
  zipkin:
    sender:
  	  type: rabbit
  sleuth:
    sampler:
      probability: 1
  rabbitmq:
    host: localhost
    port: 5672
    username: febs
    password: 123456

spring.zipkin.sender.type指定了使用RabbitMQ收集追蹤信息；

spring.sleuth.sampler.probability預設值為0.1，即採樣率才1/10，發送10筆請求只有一筆會被採集。為了測試方便，我們可以將它設置為1，即100%採樣；

spring.rabbitmq用於配置RabbitMQ連接信息，你可能會問，為什麼剛剛RabbitMQ埠是15672，這裡卻配置為5672，是不是寫錯了呢？其實不是，15672是RabbitMQ的管理頁面埠，5672是AMPQ埠。

添加好配置後，啟動system和test模塊，發送一筆localhost:8202/test/hello?name=夏天請求後，使用瀏覽器訪問http://localhost:8402/zipkin/鏈接,然後點擊圖中所示