1. 课程导论与目标：支付订单系统的性能挑战、可观测性概念、Grafana生态概览
1.1 支付订单系统的性能挑战
支付订单系统是交易链路的核心枢纽，其性能直接决定用户体验与资金安全。在秒杀、大促等流量洪峰下，系统面临以下典型挑战：
- 高并发与毛刺：瞬时流量可达正常值的数十倍，导致CPU、内存、数据库连接池瞬间打满，引发接口超时雪崩。
- 分布式事务一致性：跨服务（订单、支付、库存、积分）的最终一致性保障，失败回滚链路长，排查困难。
- 慢SQL与锁竞争：订单表数据量级大，索引设计不当或行锁升级为表锁，拖垮整个写链路。
- 第三方支付网关抖动：银行/支付渠道响应超时或返回异常码，导致订单状态长时间“处理中”。
- 全链路追踪断裂：微服务调用链长，缺乏端到端追踪，故障定位耗时数小时。
核心痛点：传统监控（CPU/内存/网络）只能回答“系统挂了”，无法回答“哪个订单、哪个服务、哪个SQL导致挂了”。可观测性正是为解决此问题而生。
1.2 可观测性概念与三大支柱
可观测性（Observability）是一种通过系统外部输出来推断内部状态的能力。在支付场景中，它由三大数据支柱构成：
| 支柱 | 支付场景示例 | 解决的核心问题 |
|---|---|---|
| Metrics（指标） | 订单创建QPS、支付成功率、P99延迟、数据库连接数 | “系统当前是否健康？趋势如何？” |
| Logs（日志） | 订单创建日志、支付回调日志、异常堆栈 | “具体发生了什么？错误详情是什么？” |
| Traces（链路） | 从“用户下单”到“支付回调”的完整调用链 | “哪个环节慢？依赖关系如何？” |
实践要点：三大支柱必须关联。例如，当Metrics发现支付成功率下降，可通过Trace定位到具体服务，再通过Logs查看该服务的错误堆栈。三者缺一不可。
1.3 Grafana生态概览
Grafana已成为可观测性领域的“统一控制面板”。其生态核心组件如下：
- Grafana：可视化仪表盘，支持Prometheus、Loki、Tempo、Elasticsearch等数据源。
- Prometheus：时序数据库，采集Metrics，支持告警规则。
- Loki：日志聚合系统，类Prometheus的标签索引，成本低。
- Tempo：分布式链路追踪后端，兼容Jaeger/OpenTelemetry。
- Pyroscope：持续性能分析，定位代码级热点。
1.4 课程学习路径与预期收益
本课程共30章，从基础到实战，层层递进。学习路径分为四个阶段：
| 阶段 | 章节范围 | 核心内容 | 产出物 |
|---|---|---|---|
| 基础篇 | 第1-8章 | 可观测性概念、Grafana/Prometheus/Loki/Tempo部署与配置 | 搭建完整可观测性平台 |
| 进阶篇 | 第9-16章 | 支付系统核心指标设计、日志结构化、链路追踪采样策略 | 支付系统三大支柱数据接入 |
| 实战篇 | 第17-24章 | 慢SQL定位、接口毛刺排查、分布式事务追踪、告警规则设计 | 性能调优案例与告警体系 |
| 高级篇 | 第25-30章 | Grafana Dashboard设计、SLO/SLI、成本优化、混沌工程 | 生产级可观测性方案 |
预期收益：完成本课程后，你将能够独立设计并落地一套面向支付订单系统的可观测性方案，实现“5分钟定位性能瓶颈、10分钟排查线上故障”的目标，显著提升系统稳定性与排障效率。
1.5 课程核心概念关系图
下图展示了支付系统性能调优中，可观测性三大支柱与调优目标的关联关系：
1.6 本章小结
- 支付订单系统的性能挑战集中在高并发、分布式事务、慢SQL、第三方依赖抖动和链路断裂。
- 可观测性三大支柱（Metrics、Logs、Traces）是解决上述挑战的基础，必须关联使用。
- Grafana生态（Prometheus + Loki + Tempo + Pyroscope）提供了统一的可观测性平台。
- 本课程从基础到高级，覆盖部署、数据接入、实战调优、Dashboard设计，最终实现生产级可观测性方案。