服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

公司线上出了个支付异常，三四个微服务都有日志，但各打各的，谁也不知道哪条日志和哪条日志是同一个请求。运维在 ELK 里翻了一个小时，靠着时间戳和 userId 硬猜，最后猜错了版本，回滚到错误的代码上又出了一波事故。要是每条日志头上都有一个贯穿全链路的请求 ID，一秒就能搜出这个请求的完整轨迹。 X-Request-ID 不是什么新技术，但落地起来细节不少。谁生成、怎么传、下游怎么接、日志怎么打，任何一个环节断了，链路就断了。今天把这些细节串起来。 谁负责生成 Request ID 生成责任只有一个：第一个接收到请求的网关。 客户端不生成，因为你不能信任客户端传上来的值——重复、太短、甚至包含注入字符。 如果客户端已经传了 X-Request-ID（比如从另一个系统透传过来的），网关应当尊重它，直接转发。但如果客户端没传，网关必须生成一个。 请求到达 Gateway │ ├─ 检查 Header: X-Request-ID │ ├─ 有值 → 直接用（跨系统透传） │ └─ 没值 → 生成新 ID │ └─ 写入 Header → 转发到下游微服务 ID 格式建议用 UUID 去横....

一、深夜救火现场：你的日志在“裸奔”吗？ 凌晨2点，线上报警！用户反馈“支付成功但订单未生成”。 你冲到ELK控制台，输入“支付成功”，哗啦啦刷出10万条日志... “哪条是这位用户的请求？”“中间哪步丢了数据？” 翻了40分钟，眼睛发酸，冷汗直流😅 你是否也经历过： 🔍 多个用户请求日志混杂，靠时间戳“猜”关联 🌪️ 异步任务/线程池日志突然“失联” 🤯 微服务调用链断裂，像断了线的珠子 今天，教你用MDC+traceId给日志装上“身份证” 一次请求所有日志自动带唯一标识，排查效率直接翻倍！✨ 二、MDC是啥？为什么它能救命？ MDC（Mapped Diagnostic Context）：Logback/Log4j提供的“线程级上下文容器” 👉 简单说：在一个请求线程里存个traceId，后续所有日志自动带上它！ 💡 灵魂价值： 一次请求生成唯一traceId，贯穿Controller→Service→DAO→异步任务 日志检索时，直接搜traceId，秒级定位全链路 为后续接入SkyWalking等APM打下基础（低成本起步！） 🌰 类比：就像快递单号！....