[學習微服務-第4天]ServiceComb+Zipkin使用篇

時間 2019-11-06

標籤學習微服 4天 servicecomb+zipkin servicecomb zipkin 使用简体版

原文原文鏈接

分佈式調用鏈追蹤能有效地監控服務間的網絡延時並可視化微服務中的數據流轉。ServiceComb擴展了zipkin的接口提供了服務內部的鏈路調用信息，能提供更完整的調用鏈路信息，更容易定位問題和潛在性能問題。html

本文將介紹ServiceComb 提供的分佈式調用鏈追蹤能力及使用指導。java

一. 異常場景示例git

咱們將使用ServiceComb的入門案例BMI（體質指數應用），展現ServiceComb的調用鏈追蹤和自定義調用鏈追蹤能力。BMI應用程序包含體質指數計算calculator和服務網關webapp兩個服務。github

參見ServiceComb的入門案例BMI指導web

http://servicecomb.apache.org/cn/docs/quick-start/apache

咱們給BMI的體質計算服務增長了異常代碼，以下。瀏覽器

參見BMI程序使用指導1微信

http://servicecomb.apache.org/cn/docs/quick-start/，運行bmi程序，出現以下異常結果。網絡

二. 使用Zipkin定位服務級別異常app

以上的BMI示例還未開啓調用鏈追蹤，下面咱們將使用ServiceComb提供的分佈式調用鏈追蹤能力定位分析BMI應用的哪一個服務發生了異常。

首先須要給BMI程序配置zipkin調用鏈追蹤能力，只需添加兩個配置便可。可參考分佈式追蹤2和Distributed Tracing with ServiceComb and Zipkin3。

1.添加依賴

在 calculator微服務的pom.xml文件中添加依賴項：

在 webapp微服務的pom.xml文件中添加依賴項：

2 .配置跟蹤處理程序
在 calculator微服務的microservice.yaml文件中添加分佈式追蹤的處理鏈：

到此已配置完畢，您只需執行如下幾步便可運行↓↓↓

使用Docker運行Zipkin分佈式追蹤服務：

重啓 calculator 微服務：

重啓 webapp 微服務：

打開瀏覽器訪問 http://localhost:9411 ，查看調用鏈追蹤狀況，結果以下。能夠看到gateway服務在1.7S時就返回給了用戶失敗結果，而calculator服務卻運行了5S的時間，但calculator爲藍色（並不是內部錯誤），能夠肯定calculator 服務超時致使gateway超時異常。

咱們經過在後臺服務打印程序調用棧日誌能夠看到，異常是因爲socket讀取超時，能夠印證咱們在Zipkin中看到的結果。

3、使用自定義追蹤功能定位到函數級別

以上已肯定致使超時返回的是calculator服務，在服務應用代碼較大時，會較難找到具體出現異常的地點，ServiceComb支持能夠在服務內部進行函數級別的調用鏈打點追蹤，這將能夠幫助咱們解決這個問題。

配置BMI程序的自定義追蹤功能，只需三步便可。

↓↓↓

參考java-chassis使用手冊—自定義調用鏈打點4

https://docs.servicecomb.io/java-chassis/zh_CN/general-development/customized-tracing.html

在體質指數計算器的pom.xml文件中添加依賴項：

在程序入口或者配置處添加 @EnableZipkinTracing 註解

在服務程序中的調用方法處添加 @Span 註解

至此，自定義函數級別打點配置完成。
運行程序，從Zipkin界面以下：

能夠看到，調用鏈中新增長了calculate函數這個Span（上圖紅圈處），耗時5S。
點開該Span，能夠查看該函數的詳細信息，咱們能夠根據該信息準確查找到對應的源碼進行修正。