1. 课程导入
在银行核心系统向微服务架构演进的过程中，一笔转账、一次支付、一个账户查询，往往要跨越网关、认证、账务、风控、限额、通知等十余个服务。服务拆分带来了弹性与迭代速度，也带来了新的难题：当交易失败、耗时抖动或金额不一致时，我们很难仅凭单个服务的日志判断问题出在哪个环节。可观测性正是为解决这一问题而生的工程能力体系，它让分布式交易链路从"黑盒"变为"可追踪、可度量、可定位"的白盒。
一、学习目标：从"能看"到"能定位、能预防"
本课程的学习目标分为四个递进层次。第一层是建立认知：理解可观测性三大支柱——日志（Logging）、指标（Metrics）、追踪（Tracing）在银行交易场景中的分工与协同。第二层是掌握采集：能够为微服务接入统一的 TraceID、Span 上下文传播，并输出结构化日志与关键业务指标。第三层是学会分析：借助链路追踪定位跨服务瓶颈，通过指标下钻识别异常拐点，结合日志还原失败现场。第四层是落地治理：把可观测性嵌入发布、压测、故障演练与日常巡检，形成可复用的告警与复盘机制。
二、核心价值：银行为什么必须做链路可观测性
银行交易具有强一致性、强合规、低延迟容忍度的特点。传统监控只关注单机 CPU、内存和接口成功率，无法回答"跨服务调用链中哪一跳拖慢了整体"。链路可观测性的核心价值体现在三方面：
- 故障定位提速：从"逐台登录查日志"变为"按 TraceID 一键串联全链路"，平均定位时间可从小时级降到分钟级。
- 容量与性能治理：通过 Span 耗时分布识别慢调用、重试风暴和连接池瓶颈，为扩容与限流提供数据依据。
- 合规与审计支撑：完整链路记录可作为交易审计、纠纷排查和监管报送的证据链。
下面这张图展示了银行微服务交易链路中可观测性数据的整体流向：交易请求从网关进入，经过各业务服务，同时产生日志、指标与追踪三类信号，最终汇聚到统一的可观测性平台。
三、整体知识框架：三层能力与一条主线
本课程的知识框架可以概括为"一条主线、三层能力"。一条主线是以交易链路为中心，所有采集、存储、分析都围绕 TraceID 展开。三层能力分别是：
| 能力层 | 核心内容 | 关键工具/技术 | 产出物 |
|---|---|---|---|
| 采集层 | 日志、指标、追踪数据埋点与上报 | OpenTelemetry、Logback、Micrometer | 统一上下文与结构化数据 |
| 存储与计算层 | 链路存储、指标聚合、日志检索 | Jaeger、Prometheus、Elasticsearch | 可查询的链路与指标库 |
| 分析与治理层 | 根因定位、告警、容量与发布治理 | Grafana、告警规则、SLO | 故障定位与预防机制 |
在采集层，最关键的是上下文传播。下面是一段典型的 OpenTelemetry 配置片段，用于在服务中注入 TraceID 并导出到后端：
otel:
traces:
exporter: otlp
endpoint: http://otel-collector:4317
resource:
attributes:
service.name: account-service
deployment.environment: prod
propagators:
- tracecontext
- baggage
当交易进入网关时，网关生成全局 TraceID，并通过 HTTP Header 向下游传递。下游服务在日志中打印该 TraceID，即可实现"一笔交易、一个 ID、全链路可查"。
四、实战路线图：从单服务到全链路
课程实战路线分为五个阶段，建议按顺序推进：
- 阶段一：单服务可观测。为一个账务服务接入结构化日志与基础指标，验证 TraceID 生成与打印。
- 阶段二：跨服务链路打通。在网关、账务、风控三个服务间传播上下文，形成完整 Span 树。
- 阶段三：指标与告警。定义交易成功率、P99 耗时、错误码分布等核心指标，配置阈值告警。
- 阶段四：故障演练与根因定位。模拟下游超时、连接池耗尽、数据库慢查询，练习按链路定位根因。
- 阶段五：治理闭环。将可观测性数据接入发布卡点、容量评估与复盘报告，形成持续改进机制。
五、常见误区与复盘要点
初学者在落地可观测性时，常陷入以下误区：
- 只采集不关联：日志、指标、追踪各自为政，没有统一 TraceID，导致无法交叉验证。
- 埋点过度：每个方法都打 Span，产生大量噪声，反而增加存储与检索成本。
- 忽视采样策略：全量采集在高并发下不可持续，需要按错误优先、慢请求优先的采样策略。
- 告警无分级：所有异常都触发告警，导致告警疲劳，真正严重的故障被淹没。
本章作为课程导入，已经明确了学习目标、核心价值、知识框架与实战路线。接下来，我们将从可观测性的三大支柱开始，逐步深入银行微服务交易链路的每一个关键环节。