微服務之間進行呼叫 那麼如果我負責乙個模組 別人負責另乙個模組 我呼叫了他的方法 測試那邊卻報了錯 那是我的問題還是他的問題
這個時候大家應該就能想到日誌可以解決這個問題
如何使用日誌呢 先在配置檔案中加
logging:
path:d:\logs\poppy-mall#日誌的存放位址最好再加個專案名的資料夾可以更容易的區分
level:
org.poppy.mall:info#日誌的級別org.poppy.mall是你的包名
然後就可以在你想新增日誌的類中寫上
publicstaticloggerlogger=logge***ctory.getlogger(類名.class);
之後就在你想加日誌的地方加上 logger.info(日誌資訊)
執行後會自動在你寫的日誌存放的位址加入日誌檔案 (它會自動生成資料夾)
檢視一下內容
是這個樣子的 這樣就解決了排錯的問題
那麼新問題又來了 如果我呼叫了幾萬次這個方法 我怎麼才能找得到我這個服務呼叫的到底是那次請求的另乙個微服務?
這時候就用到了分布式鏈路追蹤
先引入依賴 想要追蹤那個專案 都要在裡面加入這個依賴
compilegroup:'org.springframework.cloud',name:'spring-cloud-starter-sleuth'
之後再執行 檢視日誌 發現是這個樣子
可以發現多出來一串編碼 它有什麼用呢
粉色框的編碼 它代表的是在同一次請求中 編碼就相同 紅色框的** 代表的是在同一服務中 它會相同
這樣就解決了我們的問題 我們只要找到報錯的一次請求 複製粉色框內的編碼 到另乙個服務的日誌中進行查詢 就能找到
這就是分布式鏈路跟蹤
springcloud分布式日誌鏈路跟蹤
1 思路 每個請求都使用乙個唯一標識來追蹤全部的鏈路顯示在日誌中 使用logback的mdc機制日誌模板中加入traceid標識，取值方式為 x,而mdc內部使用threadlocal，本地執行緒生效，需要通過閘道器傳給下游，下游再通過fegin往下游傳遞 2 閘道器實現 public class ...
spring cloud分布式日誌鏈路跟蹤
首先要明白一點，為什麼要使用鏈路跟蹤？當我們微服務之間呼叫的時候可能會出錯，但是我們不知道是哪個服務的問題，這時候就可以通過日誌鏈路跟蹤發現哪個服務出錯。它還有乙個好處 當我們在企業中，可能每個人都負責乙個服務，我們可以通過日誌來檢查自己所負責的服務不會出錯，當呼叫其它服務時，這時候出現錯誤，那麼就...
SpringCloud 分布式配置
我們一般把配置檔案寫在專案中直接獲取相關引數 spring cloud config實現的配置中心預設採用git來儲存配置資訊，所以使用spring cloud config構建的配置伺服器，天然就支援對微服務應用配置資訊的版本管理，並且可以通過git客戶端工具來方便的管理和訪問配置內容。1.配置倉...