1. 课程导论与性能基准
1.1 支付系统全链路性能挑战概述
支付订单系统是电商、金融、出行等业务的核心命脉。一次看似简单的“点击支付”操作，在后台会触发一条跨越数十个微服务、多个网络边界、至少一次数据库写入的复杂调用链。这条链路中的任何一个环节出现延迟或瓶颈，都可能导致订单丢失、用户流失甚至资损。
典型的支付全链路包含以下关键阶段：
- 客户端请求：用户点击支付按钮，发起 HTTP/HTTPS 请求。
- API 网关：路由、限流、鉴权、协议转换。
- 业务服务层：订单服务、支付服务、用户服务、库存服务等。
- 缓存层：Redis 集群，用于会话、热点数据、分布式锁。
- 消息队列：异步解耦，如订单状态变更、对账通知。
- 数据库层：关系型数据库（MySQL/PostgreSQL）与 NoSQL。
核心挑战： 支付系统对一致性、可用性、性能有极高要求。任何优化都不能以牺牲数据一致性为代价。全链路优化的难点在于“木桶效应”——最慢的环节决定了整体吞吐。
1.2 核心性能指标定义
在开始调优之前，必须统一团队对性能指标的认知。支付系统最关注的四个核心指标如下：
| 指标 | 全称 | 定义 | 支付系统典型关注点 |
|---|---|---|---|
| TPS | Transactions Per Second | 系统每秒处理的事务数。一个支付事务通常包含一次完整的“下单→支付→回调”流程。 | 核心业务吞吐量，直接决定系统能承载多少笔并发支付。 |
| QPS | Queries Per Second | 系统每秒处理的查询请求数。通常用于衡量读接口的负载能力。 | 订单查询、支付状态轮询等读密集型场景。 |
| RT | Response Time | 从客户端发起请求到收到完整响应所经过的时间，单位通常为毫秒 (ms)。 | 用户感知的直接体验，支付超时通常设置为 5s~30s。 |
| P99 延迟 | 99th Percentile Latency | 在所有请求中，99% 的请求响应时间低于该值。用于衡量尾部延迟。 | 支付系统必须关注 P99，因为 1% 的慢请求可能对应大额交易或 VIP 用户。 |
实践建议： 在支付系统中，TPS 和 P99 延迟 是最关键的北极星指标。QPS 更多用于容量规划和限流阈值设定。不要只关注平均 RT，平均延迟会掩盖尾部慢请求的严重性。
1.3 建立性能基准测试方法论
没有基准，就没有优化。性能基准测试为后续的调优工作提供可量化的起点和对比依据。一个严谨的基准测试流程包含以下步骤：
- 定义测试场景：明确测试的业务流程（如：用户下单支付、查询订单列表、退款）。
- 确定负载模型：模拟真实用户行为，包括并发数、思考时间、请求比例。
- 选择测试工具：JMeter、Gatling、Locust 或自研压测平台。
- 搭建隔离环境：测试环境应与生产环境硬件配置、网络拓扑保持一致，避免干扰。
- 预热系统：压测前先发送一定量请求，让缓存、连接池、JIT 进入稳定状态。
- 执行阶梯加压：从低并发开始，逐步增加负载，直到系统出现性能拐点或错误率超标。
- 采集全链路数据：记录各节点的 CPU、内存、IO、网络、GC、慢查询等指标。
- 记录基准结果：输出当前版本的 TPS、QPS、RT 分布、P99 延迟、错误率。
常见误区： 不要在生产环境直接进行压测，除非有完善的熔断和降级预案。基准测试结果必须包含“环境配置快照”（CPU 型号、内存大小、JVM 参数、数据库版本、连接池大小），否则后续优化无法复现和对比。
1.4 本章小结
本章明确了支付系统全链路优化的核心挑战，统一了 TPS、QPS、RT、P99 延迟四个关键指标的定义，并给出了建立性能基准测试的标准化方法论。在下一阶段，我们将基于这套基准，从 API 网关开始逐层深入调优。