1. 问题现象与背景分析最近在SpringBoot3.0.2项目中集成Tlog1.5.2时发现日志中始终无法输出TraceId等关键链路追踪信息。这个问题看似简单实则涉及到SpringBoot3.0的重大架构变更。先说说我遇到的具体现象在微服务调用链中虽然业务逻辑正常运行但所有服务的日志都缺失了TraceId字段导致无法串联完整的请求链路。经过反复测试和排查发现问题根源在于SpringBoot3.0开始全面转向Jakarta EE规范。这个版本将原先Java EE中的javax.servlet包全部迁移到了jakarta.servlet命名空间下。而Tlog1.5.2版本仍然基于传统的javax.servlet实现这就导致了过滤器在初始化时无法正确拦截请求自然也就无法生成和传递TraceId。这种情况在微服务架构中尤为致命。想象一下当线上出现问题时你需要追踪一个用户请求经过的所有服务却发现日志中缺少了最关键的TraceId就像在迷宫里没有线索一样。我刚开始排查时也是一头雾水直到注意到控制台输出的类加载警告信息才意识到是包路径不兼容的问题。2. 深入理解技术背景要彻底解决这个问题我们需要先搞清楚几个关键技术点。首先是Jakarta EE和Java EE的关系演变。简单来说Jakarta EE是Java EE的下一代标准由于商标权变更从Java EE 8之后的所有版本都改名为Jakarta EE。SpringBoot3.0为了保持技术前瞻性全面采用了Jakarta EE 9的规范。具体到servlet API的变化原先我们熟悉的import javax.servlet.*; import javax.servlet.http.*;现在需要改为import jakarta.servlet.*; import jakarta.servlet.http.*;这种变化看似只是包名修改实则影响深远。Tlog作为一个日志增强框架其核心功能依赖于servlet过滤器来拦截请求并处理TraceId。当包路径变更后原有的过滤器类会因为找不到对应的servlet API而失效这就是导致TraceId丢失的根本原因。3. 完整解决方案实施3.1 重写关键过滤器类首先需要重写Tlog的两个核心类。第一个是TLogWebCommon这个类负责处理请求的预处理和清理工作。修改后的完整代码如下public class TLogWebCommon extends TLogRPCHandler { private static volatile TLogWebCommon tLogWebCommon; public static TLogWebCommon loadInstance() { if (tLogWebCommon null) { synchronized (TLogWebCommon.class) { if (tLogWebCommon null) { tLogWebCommon new TLogWebCommon(); } } } return tLogWebCommon; } public void preHandle(HttpServletRequest request) { String traceId request.getHeader(TLogConstants.TLOG_TRACE_KEY); String spanId request.getHeader(TLogConstants.TLOG_SPANID_KEY); String preIvkApp request.getHeader(TLogConstants.PRE_IVK_APP_KEY); String preIvkHost request.getHeader(TLogConstants.PRE_IVK_APP_HOST); String preIp request.getHeader(TLogConstants.PRE_IP_KEY); TLogLabelBean labelBean new TLogLabelBean(preIvkApp, preIvkHost, preIp, traceId, spanId); processProviderSide(labelBean); } public void afterCompletion() { cleanThreadLocal(); } }注意这里的关键变化是将所有javax.servlet引用替换为jakarta.servlet。虽然在这个类中没有直接体现但在依赖的父类中需要确保使用正确的包路径。3.2 实现自定义过滤器接下来是重写TLogFilter类这是整个链路追踪的核心public class TLogFilter implements Filter { Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { if (servletRequest instanceof HttpServletRequest servletResponse instanceof HttpServletResponse) { try { TLogWebCommon.loadInstance().preHandle((HttpServletRequest)servletRequest); // 把traceId放入response的header ((HttpServletResponse)servletResponse).addHeader(TLogConstants.TLOG_TRACE_KEY, TLogContext.getTraceId()); filterChain.doFilter(servletRequest, servletResponse); return; } finally { TLogWebCommon.loadInstance().afterCompletion(); } } filterChain.doFilter(servletRequest, servletResponse); } }这个过滤器会在每个请求到达时执行确保TraceId的正确生成和传递。特别要注意的是这里我们不仅处理了请求的预处理还将TraceId添加到了响应头中方便前端或其他服务获取。3.3 配置过滤器注册最后需要在SpringBoot配置中注册我们的自定义过滤器Configuration ComponentScan(value com.yomahub.tlog) public class LogConfig { Bean public FilterRegistrationBeanTLogFilter loggingFilter() { FilterRegistrationBeanTLogFilter registrationBean new FilterRegistrationBean(); registrationBean.setFilter(new TLogFilter()); registrationBean.addUrlPatterns(/*); // 拦截所有请求路径 registrationBean.setOrder(Ordered.HIGHEST_PRECEDENCE); return registrationBean; } }这里有几个关键点需要注意设置urlPatterns为/*确保拦截所有请求将order设置为HIGHEST_PRECEDENCE保证过滤器最先执行确保ComponentScan扫描到Tlog的包路径4. 高级定制与优化4.1 自定义TraceId生成规则在某些特定场景下我们可能需要自定义TraceId的生成规则。Tlog提供了灵活的扩展机制public class CustomTraceIdGenerator extends TLogDefaultIdGenerator { Override public String generateTraceId() { return APP- super.generateTraceId(); } }然后在配置文件中指定自定义生成器tlog.id-generatorcom.your.package.CustomTraceIdGenerator这种定制在微服务架构中特别有用可以在TraceId中加入应用标识方便快速定位问题来源。4.2 网关特殊处理如果你的架构中包含Spring Cloud Gateway等API网关可能还需要额外配置!-- 在logback配置中增加TLog MDC Listener -- contextListener classcom.yomahub.tlog.core.enhance.logback.TLogLogbackTTLMdcListener/这个监听器会确保在网关环境下也能正确输出TraceId信息。我曾在实际项目中遇到过网关日志不显示TraceId的问题添加这个配置后立即解决了。4.3 性能优化建议在高并发场景下TraceId的处理可能会成为性能瓶颈。根据我的实测经验有几点优化建议避免在TraceId生成逻辑中进行IO操作保持TLogFilter的代码尽可能简洁考虑使用ThreadLocal缓存一些中间结果定期检查过滤器的执行时间确保不会明显影响请求处理5. 验证与测试完成上述修改后需要进行全面验证。我通常采用以下测试方案发起一个端到端的请求检查所有服务的日志是否包含相同的TraceId测试并发请求确保TraceId不会互相干扰验证异常场景下的日志输出检查响应头中是否包含TraceId如果配置了的话一个健康的日志输出应该类似这样2023-08-20 14:30:45 [INFO] [TRACE_ID:abc123] 用户服务 - 开始处理用户查询请求 2023-08-20 14:30:46 [INFO] [TRACE_ID:abc123] 订单服务 - 获取用户订单列表 2023-08-20 14:30:47 [INFO] [TRACE_ID:abc123] 支付服务 - 验证支付状态如果发现某些服务的日志仍然缺失TraceId可以按照以下步骤排查确认该服务确实使用了修改后的Tlog版本检查过滤器是否被正确注册和调用查看是否有其他过滤器或拦截器清除了TraceId上下文验证日志配置是否正确集成了Tlog的MDC功能6. 兼容性考虑与未来升级虽然我们通过修改代码解决了当前的问题但还需要考虑未来的兼容性。根据Tlog社区的动态1.5.3版本可能会原生支持Jakarta EE。因此我建议将自定义修改的类单独放在一个模块中方便未来升级添加详细的注释说明修改原因定期检查Tlog的更新日志考虑向Tlog社区提交PR帮助推动官方支持在实际项目中我还遇到过一些边缘情况比如异步任务中的TraceId传递消息队列场景下的TraceId处理批量操作时的TraceId管理这些问题都需要根据具体业务场景进行额外处理核心思路是确保TraceId在整个调用链路中的一致性。