隨着業務的發展,系統規模愈來愈大,各微服務直接的調用關係也變得愈來愈複雜。一般一個由客戶端發起的請求在後端系統中會通過多個不一樣的微服務調用協同產生最後的請求結果,幾乎每個前端請求都會造成一條複雜的分佈式服務調用鏈路,對每一個請求實現全鏈路跟蹤,能夠幫助咱們快速發現錯誤根源以及監控分析每條請求鏈路上性能瓶頸。
針對分佈式服務跟蹤,Spring Cloud Sleuth提供了一套完整的解決方案。html
參考《SpringCloud微服務實戰》第11章。
先查看跟蹤日誌瞭解每項的含義前端
2019-02-27 20:40:56.419 INFO [service-a,e79b41414a56743d,e79b41414a56743d,true] 8276 --- [nio-9001-exec-5] cn.sp.controller.ServiceController : ==<Call Service-a>==
這個以前的文章有,故省略java
1.建立項目引入依賴git
其實spring-cloud-starter-zipkin中已經有了sleuth的依賴,spring-cloud-starter-sleuth能夠省略。
2. 啓動類github
@EnableEurekaClient
@SpringBootApplication
public class ServiceAApplication {
public static void main(String[] args) {
SpringApplication.run(ServiceAApplication.class, args);
}
@Bean
@LoadBalanced
RestTemplate restTemplate(){
return new RestTemplate();
}
}
@RestController
public class ServiceController {
private final Logger logger = LoggerFactory.getLogger(this.getClass());
@Autowired
private RestTemplate restTemplate;
@GetMapping("/service-a")
public String test(){
logger.info("==<Call Service-a>==");
return restTemplate.getForEntity("http://service-b/test",String.class).getBody();
}
}
這裏的url(http://service-b/test)用的是服務名當虛擬域名而不是ip+端口號的形式,至於爲何能夠訪問能夠查看這篇文章【Spring Cloud中restTemplate是如何經過服務名主求到具體服務的】。web
4.配置文件application.ymlspring
1.建立項目引入依賴pom文件同上
2.啓動類添加註解 @EnableEurekaClient
3.ServiceController後端
@RestController
public class ServiceController {
private final Logger logger = LoggerFactory.getLogger(this.getClass());
@GetMapping("/test")
public String test(){
logger.info("==<Call Service-b>==");
return "OK";
}
}
4.配置文件application.ymlbash
2.啓動類添加註解 @EnableZipkinServer
注意: 這裏我排除了log4j的依賴,由於已經有了相同的類文件啓動會報錯。微信
2019-02-27 21:18:05.119 INFO [service-a,3e487761c9b13a2e,3e487761c9b13a2e,true] 8276 --- [nio-9001-exec-9] cn.sp.controller.ServiceController : ==<Call Service-a>==
服務B的日誌以下:
2019-02-27 21:18:05.128 INFO [service-b,3e487761c9b13a2e,8d49352c6645c6f9,true] 13860 --- [nio-9002-exec-8] cn.sp.controller.ServiceController : ==<Call Service-b>==
點擊查找,服務名選擇service-a便可看到最近的統計數據,還能夠根據條件進行篩選。
點擊依賴,依賴分析就能夠看到服務以前的依賴關係。
完整代碼地址。
基本是根據《SpringCloud微服務實戰》這本書來的,可是中間仍是踩了幾個坑,好比開始報No instances available for service-b的時候我一直覺得是代碼哪裏出了問題,浪費了不少時間。
SpringCloudSleuth除了把請求鏈路數據整合到Zipkin中外,還能夠保存到消息隊列,ELK等,還算比較強大。可是除了HTTP請求,不知道對於GRPC這樣的通訊方式是否也能實現鏈路跟蹤。
查了下資料支持Grpc的,demo地址:https://github.com/tkvangorder/sleuth-grpc-sample
官方文檔:https://cloud.spring.io/spring-cloud-sleuth/single/spring-cloud-sleuth.html#_grpc