首先我們要明白一點，我們為什麼要使用鏈路跟蹤？ 當我們微服務之間調用的時候可能會出錯，但是我們不知道是哪個服務的問題，這時候就可以通過日誌鏈路跟蹤發現哪個服務出錯。 它還有一個好處：當我們在企業中，可能每個人都負責一個服務，我們可以通過日誌來檢查自己所負責的服務不會出錯，當調用其它服務時，這時候出現 ...
首先要明白一點，為什麼要使用鏈路跟蹤？
當我們微服務之間調用的時候可能會出錯，但是我們不知道是哪個服務的問題，這時候就可以通過日誌鏈路跟蹤發現哪個服務出錯。
它還有一個好處：當我們在企業中，可能每個人都負責一個服務，我們可以通過日誌來檢查自己所負責的服務不會出錯，當調用其它服務時，這時候出現錯誤，那麼就可以判定出不是自己的服務出錯，從而也可以發現責任不是自己的。
基於微服務之間的調用開始，如果看不懂的小伙伴，請先參考我上篇博客：spring cloud中微服務之間的調用以及eureka的自我保護機制
首先，我們先在project-solr和project-shopping-mall裡加配置：
project-solr中的application.yml：
logging:
path: D:\work\logs\project-solr #列印存放日誌的路徑
level:
com.gaofei: info #包名下日誌的級別
project-shopping-mall中的application.yml：
logging:
path: D:\work\logs\project-shopping-mall #列印存放日誌的路徑
level:
com.gaofei: info #包下麵日誌級別
大家可以看出我兩個服務里的日誌存放的路徑不一樣，這樣也便於區分
在project-solr里的constroller里：
@RestController//這裡使此Constroller中所有的方法返回的不是頁面
public class SolrSearchConstroller {
public static Logger logger=LoggerFactory.getLogger(SolrSearchConstroller.class);
@RequestMapping("/SolrSearch")
public String SolrSearch(){
logger.info("Solr被調用");
return "這裡是Solr";
}
}
在project-shopping-mall里的constroller：
@Controller
public class PageController {
public static Logger logger=LoggerFactory.getLogger(PageController.class);
@Autowired
private RestTemplate restTemplate;
@RequestMapping("/toIndex")
public String toIndex(Model model){
logger.info("執行調用");
String msg=restTemplate.getForEntity("http://project-solr/SolrSearch",String.class).getBody();//project-solr是調用註冊中心裡的名字
logger.info("調用結束");
model.addAttribute("msg",msg);
return "/index";
}
}
接下來執行：
在這裡如果沒有logs後面的目錄它會自動創建
點開兩個日誌文件：
這裡因為我運行刷新了3次，所以執行了3次，而兩個日誌里也對應了三次
如果其中一條報錯那麼也很快可以找到答案，並且知道哪個日誌里報錯，也就對應了哪個服務報錯
那麼問題來了，如果我們在開發中，一天可能會運行n次，那麼其中某次運行報錯，我們就要在n次調用時來找對應的服務，那麼怎麼辦，我們不可能一一對應查找
這時候我們可以進行鏈路追蹤，只需要在對應的伺服器build.gradle加上Spring Cloud Sleuth依賴
//分散式鏈路依賴
compile group: 'org.springframework.cloud', name: 'spring-cloud-starter-sleuth'
這裡我只用到了兩個服務project-solr和project-shopping-mall，所以這裡就在這兩個服務build.gradle中添加
之後執行，打開存放的日誌：
這裡我運行刷新了n次，那麼怎麼在另一個服務找到對應的調用呢？大家仔細看一下紅塊中的鏈路是不是對應相應的服務
我隨便拿一個進行查找
通過查找可以發現，可以找到對應的鏈路，那麼也就是每次運行都會出現一個鏈路，可以來查找相應服務的操作是否執行成功，那麼這也就是鏈路追蹤
下一篇我會寫分散式服務整合zipkin的鏈路跟蹤
