📚 课程目录第1章课程导入

1. 课程导入

核心银行系统是金融机构的“心脏”，它承载账户、存款、贷款、支付结算、总账等关键业务。一次秒杀活动、一笔批量代发、一个日终切日，都可能让交易响应时间从 200ms 飙升到数秒，甚至引发联机交易超时、账务不平、客户投诉。性能问题从来不是“上线后再说”的小事，而是需要在投产前通过性能基线与容量验证提前锁定的工程能力。本课程面向架构师、性能测试工程师、DBA、运维与开发骨干，用 30 个章节把“怎么定基线、怎么验容量、怎么定位瓶颈、怎么复盘改进”讲透。

一、学习目标：从“能跑”到“可证明能扛”

很多团队做性能测试，停留在“压一压、看 TPS、写个报告”。本课程的目标是让学员建立可交付、可审计、可复用的性能工程闭环。具体包括：

能定义：根据业务量、峰值系数、SLA，推导核心银行关键交易的性能基线与容量目标。
能设计：设计贴近生产的测试场景、数据模型、链路拓扑与监控埋点。
能执行：使用压测工具、数据库监控、APM、操作系统指标完成容量验证。
能定位：从应用、中间件、数据库、存储、网络逐层缩小瓶颈范围。
能复盘：把测试结论转化为扩容建议、参数调优、架构改造与上线准入标准。

  一句话概括：性能基线回答“正常应该多快”，容量验证回答“最多能扛多少”，两者共同构成核心银行上线前的“性能体检报告”。

二、核心概念：基线、容量、瓶颈与拐点

在进入实战前，必须先统一语言。核心银行性能领域最容易被混淆的四个概念如下：

概念	定义	典型指标	常见误区
性能基线	在标准环境、标准数据、标准场景下，系统稳定运行时的性能参考值	TPS、RT 均值/P95/P99、成功率、资源利用率	把一次压测结果当基线，忽略环境与数据差异
容量验证	验证系统在目标业务量下能否满足 SLA，并找出可扩展上限	最大 TPS、并发用户数、数据增长量、扩容比	只压联机交易，忽略批量与日终
瓶颈	限制系统吞吐或响应时间的关键资源或代码路径	CPU、内存、IO、锁等待、连接池、GC	只看应用日志，不看数据库与操作系统
性能拐点	压力增加时，吞吐不再上升而响应时间急剧恶化的临界点	TPS 曲线平台期、RT 陡升点、错误率上升点	把拐点后的数据当作稳定容量

理解这些概念后，再看一个典型的核心银行性能指标关系。下图用参数关系示意“并发—吞吐—响应时间—资源”之间的非线性变化，帮助你在压测中识别拐点。

三、整体框架：从业务量到准入结论的六步法

本课程把性能基线与容量验证拆成一条可落地的主线，称为“六步法”。它不是简单的测试流程，而是从业务目标反推技术验证的闭环。

业务量建模：统计日均交易量、峰值时段、峰值系数、批量窗口，形成容量输入。
基线定义：为转账、存款、贷款、查询等关键交易定义 RT、TPS、成功率与资源红线。
场景设计：按联机、批量、日终、混合链路设计压测场景与数据配比。
环境与数据准备：保证测试环境、数据量、参数配置尽量贴近生产。
执行与监控：压测同时采集应用、中间件、数据库、OS、网络全链路指标。
分析与准入：识别瓶颈与拐点，输出扩容、调优、改造建议与上线准入结论。

六步法中最容易被跳过的是第 1 步和第 4 步。业务量建模不准，容量结论就没有意义；环境与数据不贴近生产，基线就不可信。

四、实战价值：为什么核心银行必须做这件事

核心银行的性能问题具有“高代价、强关联、难回滚”的特点。一次日终批量超时，可能影响次日开门营业；一次数据库连接池耗尽，可能引发全行柜面交易阻塞。性能基线与容量验证的实战价值体现在三个层面：

风险前置：在投产前暴露瓶颈，避免带病上线。
成本可控：用数据决定扩容规模，避免过度采购或容量不足。
责任清晰：形成可审计的性能报告，为上线决策提供依据。

下面给出一个简化的压测命令示例，用于采集核心交易在指定并发下的 TPS 与响应时间。实际课程中会结合具体工具与监控平台展开。

# 示例：使用压测工具执行核心转账交易场景
# 目标：验证 500 并发下转账交易 TPS 与 P95 响应时间
stress-test \
  --scenario transfer \
  --concurrency 500 \
  --duration 1800 \
  --ramp-up 300 \
  --data-file account_pairs.csv \
  --report tps,rt_p95,rt_p99,error_rate \
  --output report/transfer_baseline.json

# 关键观察指标
# TPS：每秒成功交易数
# RT P95：95% 交易响应时间
# Error Rate：超时、拒绝、账务异常比例
# CPU / DB Wait / GC：资源与瓶颈信号

不要用“平均响应时间”单独判断性能。核心银行更关注 P95、P99 与错误率，因为少量慢交易可能对应大量客户投诉与账务风险。

五、常见误区与复盘视角

在真实项目中，性能基线与容量验证常被做成“一次性表演”。以下误区需要从一开始就避免：

误区一：只压联机，不压批量。核心银行的日终、结息、代发批量往往才是真正的容量杀手。
误区二：测试数据量太小。百万级账户与亿级账户的索引、分区、锁竞争完全不同。
误区三：忽略混合场景。联机交易与批量任务并行时，资源争抢会显著改变性能表现。
误区四：没有基线就谈优化。没有基线，调优无法量化，也无法判断是否真正改善。
误区五：把拐点当容量。拐点之后系统已进入不稳定区，不能作为上线容量依据。

复盘时建议围绕“业务量—场景—指标—瓶颈—结论—行动”六要素输出报告。每一轮压测都要回答：目标是什么、结果如何、瓶颈在哪、下一步做什么。只有这样，性能工程才能从一次性测试变成持续能力。

本章作为课程导入，已经建立了学习目标、核心概念、六步框架与实战价值。接下来你将进入具体的方法、工具与案例，逐步掌握核心银行性能基线与容量验证的完整技能体系。