spring-cloud-sleuth+zipkin追蹤服務實現(二)
在上一節《spring-cloud-sleuth+zipkin追蹤服務實現(一)》中,我們使用zipkin-server、provider、consumer三個程序實現了使用http方式進行通信,數據持久化到數據庫中的服務調用鏈路追蹤實現。針對其中存在的影響性能和可能丟失數據的缺陷,在這一節我們使用spring-cloud的為我們提供的實現的方式來測試這種情況。
我們還是使用之前上一節中的三個程序做修改,方便大家看到對比不同點。
一、zipkin-server
要將http方式改為通過MQ通信,我們要將依賴的原來依賴的io.zipkin.java:zipkin-server換成spring-cloud-sleuth-zipkin-stream和spring-cloud-starter-stream-rabbit,並且移除zipkin-autoconfigure-storage-mysql,因為spring-cloud-sleuth-zipkin-stream會自動為我們引入,全部maven依賴如下:
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<!--zipkin依賴-->
<!--此依賴會自動引入spring-cloud-sleuth-stream並且引入zipkin的依賴包-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
<scope>runtime</scope>
</dependency>
<!--保存到數據庫需要如下依賴-->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
</dependencies>
添加以上maven依賴後,我們將啟動類ZipkinServer中@EnableZipkinServer注解替換成@EnableZipkinStreamServer
@SpringBootApplication
@EnableDiscoveryClient //注冊到eureka
@EnableZipkinStreamServer //使用Stream方式啟動ZipkinServer
public class ZipkinServer {
public static void main(String[] args) {
SpringApplication.run(ZipkinServer.class, args);
}
}
點擊@EnableZipkinStreamServer注解的源碼我們可以看到它也引入了@EnableZipkinServer注解,同時還創建了一個rabbit-mq的消息隊列監聽器。
以方便接收從消息客戶端收集發過來的mq消息。由於使用了消息中間件rabbit-mq,所以我們還需要在配置文件中配置我們的MQ連接配置
#rabbitmq配置
spring.rabbitmq.host=127.0.0.1
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest
為了避免http通信的幹擾,我們將原來的監聽端口有9411更改為9412,啟動程序,未報錯且能夠看到rabbit連接日誌,說明程序啟動成功。
二、provider和consumer
與上一節中的配置一樣,客戶端的配置也非常簡單,maven依賴隻需要將原來的spring-cloud-starter-zipkin替換為如下兩個依賴即可
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>
此外,在配置文件中也加上連接MQ的配置
#rabbitmq配置
spring.rabbitmq.host=127.0.0.1
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest
在第一節中,客戶端連接zipkin-server是使用的配置
spring.zipkin.base-url=https://127.0.0.1:9411, 由於不再使用這種方式,我們將它取消掉。同時,我們將數據庫中的數據也清空。
我們如上一節《spring-cloud-sleuth+zipkin追蹤服務實現(一)》中一樣,訪問consumer的外部http地址("https://127.0.0.1:10001/add/被加數/加數") 。然後我們訪問zipkin-server的地址“https://127.0.0.1:9412/” ,我們可以看到如下的效果,說明rabbit-mq方式通信的sleuth功能已經生效了。
我們多次訪問consumer的地址可以看到日誌中,請求的耗時時間不會再次出現突然耗時特長的情況。
為了體驗MQ通信給我們帶來的數據不丟失的特點,我們將數據庫中的數據清空,然後刷新zipkin-server的界麵,可以看到不再有數據
然後我們將zipkin-server程序想關閉,然後再多次訪問consumer的地址,之後,我們重啟zipkin-server程序,啟動成功後訪問UI界麵
很快看到Span Name選項有數據可以選擇了,同時數據庫中的記錄條數也不再是之前的0條了
如此說明我們的zipkin重啟後,從MQ中成功獲取出了在關閉這段時間裏provider和consumer產生的信息數據。這樣我們使用spring-cloud-sleuth-stream+zipkin方式的rest服務調用追蹤功能就OK了。
注意:
測試時請將consumer訪問地址中的“被加數”和“加數”替換為兩個整數。
**參考文檔:
**
https://github.com/spring-cloud/spring-cloud-sleuth
菜鳥學文,望大俠指正。
最後更新:2017-05-05 17:34:53