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

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

1. rabbitmq

   • RabbitMQ是實現了高級消息隊列協議（AMQP）的開源消息代理軟件（亦稱面向消息的中間件）。RabbitMQ服務器是用Erlang語言編寫的，而羣集和故障轉移是構建在開放電信平臺框架上的。全部主要的編程語言均有與代理接口通信的客戶端庫。

2. 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中的一些術語

1. Span：基本工做單元，例如，在一個新建的span中發送一個RPC等同於發送一個迴應請求給RPC，span經過一個64位ID惟一標識，trace以另外一個64位ID表示，span還有其餘數據信息，好比摘要、時間戳事件、關鍵值註釋(tags)、span的ID、以及進度ID(一般是IP地址) ,span在不斷的啓動和中止，同時記錄了時間信息，當你建立了一個span，你必須在將來的某個時刻中止它。
2. Trace：一系列spans組成的一個樹狀結構，例如，若是你正在跑一個分佈式工程，你可能須要建立一個trace。
3. 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個部分的值，它們的含義以下：

1. system微服務的名稱，與spring.application.name對應；
2. 72bb0469bee07104稱爲Trace ID，在一條完整的請求鏈路中，這個值是固定的。觀察上面的日誌便可證明這一點；
3. 43597a6edded6f2e稱爲Span ID，它表示一個基本的工做單元；
4. 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/連接,而後點擊圖中所示

查看依賴關係：

查看數據表，看是否存儲了信息：

---

公衆號：良許Linux

有收穫？但願老鐵們來個三連擊，給更多的人看到這篇文章