Sleuth Zipkin

日誌的重要性不言而喻，幫助我們在異常發生的時候很好的定位到問題所在。

但是微服務這種問題就大了。

拿本次我們要舉的例子來說，我們有：網關微服務（Zuul）、服務間調用（Feign）、訂單服務（Order），調用的時候出問題了（返回錯誤信息、響應變慢），你說會是誰的問題？

這三個微服務可能是部門三個不同的開發組，或者是公司的三個部門在做。各有各的日誌，誰知道日誌記錄的異常是哪次調用的？

這不像單體應用，Controller-Service-Mapper，在IDE里一點就跳進去了，微服務各組之間也拿不到其他組的源代碼。

這就需要服務追蹤Sleuth組件。理論的東西不談，你平時網購時看的那個快遞物流跟蹤單，能理解這個就能理解Sleuth。

如果把Sleuth比喻成純純的物流信息，我們最起碼也需要一個展示的頁面吧，這就需要Zipkin了。

Zipkin服務端

進入http://start.spring.io 如下圖一樣構建：

http://start.spring.io

一定得1.5.X版本，我一開始用最新的2.0.0.M3，估計是依賴包不兼容，沒法用。pom.xml增加如下依賴包：

pom.xml

application.yml：

application.yml

代碼：

代碼

代碼增加@EnableZipkinServer即可。

啟動Eureka註冊中心，Zipkin服務，訪問http://localhost:9411 如下圖：

Zipkin監控頁面

沒有服務，所以頁面是空的。

各服務修改

使用我之前構建的Zuul、Feign、Order三個服務。

相關文章請參閱：

0、《Spring boot+MyBatis+PageHelper+JSON》

1、《極簡Spring Boot搭建、開發、部署》

2、《Spring Cloud註冊中心——Eureka&集群》

3、《Spring Cloud網關Zuul&過濾器&集群方案》

4、《Spring Cloud網關與負載均衡Zuul與Ribbon》

5、《Spring Cloud服務間調用Feign》

6、《Spring Cloud斷路器Hystrix》

7、《Spring Cloud分散式配置中心Config》

給三個服務增加如下依賴：

pom.xml

每個服務都增加Zipkin服務的URL：

application.yml

結果

依次啟動Eureka、Zipkin、Order、Feign、Zuul，如下圖：

通過Zuul訪問Feign，Feign調用Order，結果如下圖：

Zuul Feign Order

多刷新幾次，再進入Zipkin的監控頁面，在紅框A處選擇要查詢的Service，點擊紅框B，就能看到請求調用鏈的相關信息。紅框C可以自己點點看。

Zipkin監控頁面

下一篇講啥呢？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！