链路监控概述：从“盲人摸象”到“全链路透视”
链路监控，说白了就是给分布式系统装上一套“追踪仪”。你想想看，微服务一多，一个请求可能穿越十几个服务，出问题了你根本不知道卡在哪一环。我刚开始接触分布式系统时，就吃过这个亏——用户反馈页面加载慢，我查了所有服务的日志、CPU、内存，都正常。折腾了大半天，最后才发现是某个下游服务的连接池配置错了。要是当时有链路监控，一眼就能看出延迟在哪爆的。
什么是链路监控
链路监控（Distributed Tracing）的核心思想很简单：为每个外部请求生成一个全局唯一的 Trace ID，然后把这个请求经过的所有服务、方法、数据库调用都记录下来，形成一棵调用树。每个节点叫 Span，记录了开始时间、结束时间、调用方、被调用方、状态等信息。
举个真实例子：你在浏览器点了个“下单”，请求经 API 网关 -> 订单服务 -> 库存服务 -> 支付服务 -> 消息队列 -> 通知服务。如果每个环节都打了 trace，你就能看到：
Trace ID: abc123
Span A: API Gateway (耗时 5ms)
Span B: Order Service (耗时 200ms)
Span C: Redis 扣库存 (耗时 150ms)
Span D: Payment Service (耗时 300ms) ← 这里慢了！
Span E: 调用第三方支付 (耗时 280ms)
Span F: Notification Service (耗时 20ms)
这样，哪怕第三方支付挂了，你也能一眼定位到是外部依赖的问题。我在上一家公司就遇到过类似场景：一次大促时订单成功率骤降，在日志海里根本找不到线索。幸好我们当时已经接入了链路监控，排查后发现是某个缓存的连接池被耗尽，整个调用链在 Redis 那一步延迟飙升。没有 trace，可能得排查几个小时。
Trace：一次请求的完整调用链路，包含多个 Span。
Span：一个调用单元，记录服务间的一次 RPC、数据库查询或消息发送。
Span Context：用于传递 Trace ID 和父 Span ID，跨进程传播。
为什么要做链路监控？
你可能会想：“我服务运行得好好的，干嘛要费劲搞这个？”嗯，等你的系统从几个服务膨胀到几十个，你就会明白。我总结了几大痛点：
- 定位慢：一个请求跨 10 个服务，出问题你根本不知道是哪个服务慢、哪个挂了。链路监控能把每个环节的耗时和状态直接列出来。
- 依赖模糊：新同学接手项目时，经常搞不清服务之间的调用关系。链路监控画出的拓扑图比文档靠谱多了。
- 性能瓶颈：你以为数据库是瓶颈，实际可能是某个不怎么起眼的 Redis 操作拖了后腿。trace 能告诉你真实耗时。
- 故障蔓延难追溯：下游服务超时导致上游线程池耗尽，这种“雪崩”现象在链路监控下非常清晰。
- 无法量化 SLA：想统计 P99 延迟？必须靠全量采样或合理采样的链路数据。
| 业务场景 | 没有链路监控 | 有链路监控 |
|---|---|---|
| 线上故障排查 | 登录各台机器查日志，人工拼调用链 | 输入 Trace ID，一键看全链路 |
| 性能优化 | 拍脑袋猜瓶颈，压测验证 | 直接看每个 Span 耗时，数据驱动 |
| 容量规划 | 模糊估算 QPS 和依赖 | 精确知道每个链路的调用量和延迟分布 |
| 团队协作 | 靠代码注释和口头沟通 | 实时更新的服务拓扑图，一目了然 |
常见开源框架对比
选框架时，我踩过一个坑：当时项目急，直接选了某个框架，结果发现它不支持我们用的消息队列协议，不得不重写部分代码。所以选型前，一定要对比清楚。
目前主流的开源方案有四个：Zipkin、Jaeger、Apache SkyWalking、Pinpoint。我整理了一张对比表：
| 特性 | Zipkin | Jaeger | SkyWalking | Pinpoint |
|---|---|---|---|---|
| 语言 | Java 为主，多语言 SDK | 多语言（Go、Java、Python…） | Java、.NET、Node.js 等 | Java、.NET |
| 存储 | Elasticsearch、Cassandra、MySQL | Elasticsearch、Kafka、Cassandra | Elasticsearch、H2、MySQL | HBase（必须） |
| UI 成熟度 | 基础，支持依赖图 | 好，有深度分析 | 非常好，拓扑图+告警 | 好，CallStack 细致 |
| 采样策略 | 固定、速率、自定义 | 固定、概率、自适应 | 固定、概率、端点级别 | 固定、概率 |
| 社区活跃度 | 中等（维护良好） | 高（CNCF 毕业项目） | 高（Apache 顶级项目） | 中等（Naver 维护） |
| 侵入性 | 需手动埋点或 AOP | SDK 埋点，自动注入 | Agent 字节码增强，无侵入 | Agent 字节码增强，无侵入 |
| 学习成本 | 低 | 中 | 中 | 中 |
我的选择建议：如果你团队以 Java 为主，又想快速上手且不想侵入业务代码，SkyWalking 是首选。它的 Agent 直接挂在应用上，自动拦截主流框架的调用，非常省心。如果你有多语言需求（比如 Go/Python），Jaeger 是更合适的选择，它的组件设计更微服务化，扩展也方便。Zipkin 虽然老牌，但在功能和易用性上已经落后了。Pinpoint 依赖 HBase，运维成本偏高，我一般不太推荐。
好了，链路监控的概貌就是这样。你可以把上面的架构图当作一个“地图”，后面几章我们会逐步深入每个环节：如何埋点、如何采集、如何存储、如何查询。别看它涉及组件多，理解清楚数据流向之后，你自己也能搭起来一套。