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

问题背景 在微服务架构中，网关作为系统的入口，承担着请求路由、安全认证等重要职责。为了保证通信安全，HTTPS 成为了标配，而双向认证（mTLS）则是更高安全级别的选择。然而，配置 HTTPS 双向认证的过程往往充满挑战： 证书管理复杂：需要创建根证书、服务器证书、客户端证书，涉及多个文件和密码 配置繁琐：需要在网关和服务端分别配置证书和密钥 调试困难：出现问题时，难以定位是证书问题、配置问题还是网络问题 连通性验证：需要编写测试代码或使用复杂的命令行工具验证双向认证是否正常 环境差异：不同环境（开发、测试、生产）的证书配置不同，容易出错 核心概念 HTTPS 双向认证原理 HTTPS 双向认证（mTLS，Mutual TLS）是一种安全通信协议，要求通信双方都需要验证对方的身份： 客户端验证服务端：客户端验证服务端的证书是否由可信任的CA签发 服务端验证客户端：服务端验证客户端的证书是否由可信任的CA签发 证书链结构 ┌─────────────────┐ │ 根证书 (CA) │ └────────────┬────┘ │ ┌────────────▼────┐ ┌────....