基于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

命名规范须要根据具体业务来编写。示例仅供参考~

而且可对返回的数据进行适当的处理，使其避免暴露关键信息，同时还能方便问题的定位与处理。固然这个度仍是须要根据具体业务和需求来把握。