面经策

为什么需要在微服务中使用链路追踪？Spring Cloud 可以选择哪些微服务链路追踪方案？ ​

  • 标签：微服务、链路追踪、Spring Cloud

🏛 业务架构师 ​

为什么需要链路追踪：一次请求横跨网关、订单、库存、支付多个服务，每个服务内部又有多层调用。没有链路追踪时，"下单慢在哪"要靠多台机器翻日志人肉拼时间线——故障定位以小时计。链路追踪通过 traceId 全局串联 + spanId 记录每个调用段的耗时与状态，把"跨服务排障"变成"看一条瀑布图"——MTTR（平均故障定位时间）从小时级压到分钟级，这是它最直接的业务价值。其次是性能剖析价值：慢查询、重调用、异常热点在大盘上一目了然，容量规划和优化有了数据依据。

Spring Cloud 可选方案（2026 现状）：

  • Micrometer Tracing + OTel：Spring Boot 3 官方路线（取代 Sleuth），对接 OpenTelemetry 标准，埋点数据可发 Zipkin/Jaeger/商业 APM——新项目默认选择，标准化是长期资产；
  • SkyWalking：国内使用极广，Java Agent 无侵入埋点 + 完整的拓扑图/告警/指标一体化平台，运维团队主导的选型最爱；
  • Zipkin/Jaeger：经典存储查询端，常作为 OTel 的后端搭配；
  • 商业 APM（Elastic APM、阿里 ARMS）：要预算但省运维。

我的选型经验：标准上押注 OpenTelemetry（厂商中立，埋点数据未来可迁移），产品形态上选一体化平台（SkyWalking 这类，拓扑图+告警开箱即用）。

落地要点：traceId 要透传到日志（MDC）、透传到异步线程与 MQ 消息——断链的追踪等于没有；采样策略按流量分级（全采样 → 尾部采样），控制成本。

🏗 系统架构师 ​

为什么需要：一个请求横跨十几服务、消息与定时任务，没有全链路视图就是盲人摸象——排查「下单慢」必须知道慢在哪一跳。链路追踪通过 traceId 贯穿加 span 树量化每个环节的耗时与状态，同时支撑依赖拓扑分析与容量定位。

2026 标准答案：OpenTelemetry 已统一江湖——W3C Trace Context（traceparent 头）传播、OTLP 协议上报、Collector 做采样与导出。Spring 侧：Micrometer Tracing（Boot 3.x 官方，Sleuth 退役）桥接 OTel 或 Brave，自动埋点覆盖 Web、MQ、JDBC、Redis。后端选 Jaeger、Tempo、SkyWalking 或 Zipkin。

架构实践三决策：

  1. 采样策略：全采扛不住存储成本——常态头部采样 1% 到 10%，错误请求 100% 保留（标记重采/尾采）；我的原则「正常抽样、异常全留」；
  2. traceId 与日志、错误契约打通：MDC 进日志、错误响应带 traceId，用户报障可秒查现场；
  3. 传播完整性：跨线程（@Async）、跨 MQ（属性透传）是断链高发区，平台统一封装传播器。

开销微秒级可忽略，但 span 量乘采样率的存储成本要提前规划。

💻 全栈开发专家 ​

微服务一次请求跨 5+ 服务，"慢在哪、挂在哪"必须靠 trace 串联。

为什么需要：排障定位（一个 traceId 贯穿所有服务日志与 RPC/MQ 调用）、性能分析（span 耗时瀑布图找慢点）、依赖拓扑自动生成、压测流量识别。

方案选型：

  • Micrometer Tracing + OTel/Brave：Spring 官方路线（3.x 起 Sleuth 停更），Brave 传 Zipkin、OTel 协议兼容 Jaeger/Tempo
  • SkyWalking：Java Agent 字节码无侵入，国内主流，拓扑图/慢接口分析 UI 好
  • Zipkin/Jaeger：开源标准存储查询后端

落地关键三件事（做过两次全链路接入的经验）：

  1. traceId 进日志：logback pattern 里 %X{trace_id}（MDC 自动注入），日志平台用 traceId 串起一次请求的全部日志
  2. 跨组件传播：HTTP header（W3C traceparent）+ MQ 消息头 + 线程池 TaskDecorator，漏一段链路就断
  3. 采样策略：默认 10% + 慢请求/错误全采，生产问题再动态调，全量采样存储扛不住

选型口径：存量多、改造慢用 SkyWalking Agent 无侵入；新项目我推 Micrometer Tracing（框架原生，与 metrics/logs 一体）。