基於Spring Boot + Dubbo的全鏈路日誌追蹤(一)

1、 概要

當前公司後端總體架構爲：Spring Boot + Dubbo。因爲早期項目進度等緣由，對日誌這塊沒有統一的規範，基本上是每一個項目本身管本身的日誌。這也對後面的問題排查帶來了很大的困難，特別是那些須要同時或者多級調用Dubbo的服務場景，排查起來更加的困難。

如今須要實現從請求開始，到請求結束的全程日誌跟蹤。需求很簡單，實現思路也不難，只須要全局添加一個traceId便可。

固然只有日誌的記錄是不夠的，還要有日誌的統一存儲和查詢。

2、 思路

2.1 日誌採集與存儲

初步選擇的方案是：阿里雲*日誌服務。可免落地，直接存儲。日誌服務支持Appender直接發送。

替代方案：基於Logback appender + 消息隊列 + ELK來實現。不過，這樣的話，成本並不必定會比阿里雲服務低。

2.2 當前項目改造

2.2.1 API接口

當前項目返回數據格式:

{
    "code": 200,
    "data": "Hello world",
    "msg": "ok"
}

改造後，全部HTTP API響應體中增長traceId字段：

{
    "code": 200,
    "data": "Hello world",
    "msg": "ok",
    "traceId": "bd41aed8b2da4895a9d2b43d1ef12595"
}

2.2.2 Dubbo

對於服務調用方：每次調用服務時，都須要向服務提供方傳遞traceId。

對於服務提供方：每次服務響應時，都須要從服務調用方獲取traceId,並將該traceId傳遞下去，直至該響應結束。

2.2.3 日誌配置

需對當前日誌格式及配置進行統一。

2.3 落地思路

2.3.1 API接口

項目內部使用org.slf4j.MDC傳遞traceId。

使用攔截器完成traceId的設置與清除。請求到來時，生成並設置traceId；請求結束時，清除traceId。

攔截器中沒法修改HTTP響應體。可經過ControllerAdvice統一貫Response Body中寫入traceId。

2.3.2 Dubbo

使用Dubbo提供的org.apache.dubbo.rpc.Filter來完成traceId的設置與獲取。

3、 備註

Dubbo日誌問題

Dubbo服務的調用，並不必定是HTTP Request引發的，因此會存在一些沒有traceId的調用狀況。這塊須要單獨的處理。

可對traceId的命名進行規範。

如：

• req:xxa:xxx 表示 前端請求，xxa模塊，序號標識xxx
• tim:xxc:xxx 表示 定時器觸發，xxc模塊，序號標識xxx

命名規範須要根據具體業務來編寫。示例僅供參考~

而且可對返回的數據進行適當的處理，使其避免暴露關鍵信息，同時還能方便問題的定位與處理。固然這個度仍是須要根據具體業務和需求來把握。