使用唯一traceId实现请求追踪，结合结构化日志与ELK/EFK集中收集，再通过Sleuth+Zipkin等工具实现调用链可视化，提升微服务可观测性。
在微服务架构中，服务被拆分为多个独立部署的小型服务，每个服务负责特定的业务功能。这种架构提升了系统的灵活性和可维护性，但也带来了新的挑战——如何统一收集日志并追踪一次请求在多个服务间的流转过程。本文通过一个简单示例说明如何实现微服务的日志收集与请求追踪。
使用唯一请求ID实现请求追踪
当一个用户请求经过网关后，可能调用订单服务、用户服务、支付服务等多个微服务。为了追踪该请求在整个系统中的路径，需要为每次请求分配一个唯一的追踪ID（如 traceId）。
具体做法如下：
- 在请求进入系统入口（如API网关）时生成一个全局唯一的 traceId，例如使用 UUID 或雪花算法。
- 将 traceId 放入 HTTP 请求头中，如 X-Trace-ID。
- 每个下游服务在处理请求时，从请求头中读取 traceId，并在本地日志中打印该ID。
- 服务间调用时，需将 traceId 继续传递给下一个服务。
例如，用户请求创建订单：
[X-Trace-ID: abc123] 接收到创建订单请求 → 调用用户服务验证用户 → 调用支付服务扣款所有服务在日志中输出相同的 traceId "abc123"，便于后续聚合查询。
集中式日志收集方案
每个微服务独立打印日志到本地文件不利于排查问题。应将日志集中收集到统一平台，常用技术栈包括 ELK（Elasticsearch + Logstash + Kibana）或 EFK（Fluentd 替代 Logstash）。
实施步骤：
- 各服务使用结构化日志格式（如 JSON），并在每条日志中包含 traceId、服务名、时间戳等字段。
- 在每个服务节点部署日志采集代理（如 Filebeat 或 Fluent Bit），实时读取日志文件并发送到消息队列（如 Kafka）或直接传入 Elasticsearch。
- 通过 Kibana 查询日志时，输入 traceId 即可查看该请求在各个服务中的执行轨迹。
例如，在 Spring Boot 服务中可通过 MDC（Mapped Diagnostic Context）将 traceId 写入日志上下文：
MDC.put("traceId", traceId);log.info("开始调用用户服务"); // 日志自动包含 traceId
集成分布式追踪工具（如 Zipkin 或 Jaeger）
除了日志，还可以引入专业的分布式追踪系统，自动记录服务调用链路。这类工具不仅能显示请求路径，还能展示每个环节的耗时、错误状态等。
以 Spring Cloud 应用为例：
- 引入 Sleuth（生成 traceId 和 spanId）和 Zipkin 客户端依赖。
- 服务启动后，Sleuth 自动为请求生成 traceId 和 spanId，并通过 HTTP 头向下游传播。
- Zipkin Server 收集调用数据，提供可视化界面展示完整的调用链。
例如，Zipkin 界面会显示：gateway → order-service → user-service → payment-service，每段调用的耗时清晰可见。
基本上就这些。通过 traceId 贯穿请求、结构化日志输出、集中收集与可视化追踪工具结合，可以有效提升微服务系统的可观测性。关键在于统一规范和自动化注入，避免人工遗漏。不复杂但容易忽略。
