关于银行核心系统性能测试和调优

背景

由于工作原因，这一两年经常对公司的核心系统产品进行性能测试，写这篇文章的初衷是想把我性能测试中积累的一些测试经验以及遇到的常见问题做个记录，其中也会包括一些oracle、RAC相关的调优经验。
真正动笔开始写这篇博文主要还是受到了陈皓老师的这篇文章《性能测试应该怎么做？》的一些启发，这篇文章不长但是干货十足，推荐大家有空可以看一看。网上讲性能测试的文章其实也很多，有些是介绍工具的也有一些是讲测试方法的，但我看下来绝大部分文章都是针对web系统的性能测试，相比而言谈及类似银行核心系统的压测文章就少之又少，加之不同系统的测试方法甚至关注点本来就是不同的，这让我工作中很难从网上找到我需要的信息。

银行核心系统的特点

讨论问题一定要先明确范畴，这里我说的银行核心系统指的主要是银行的联机交易系统，一般是7*24在线处理金融8583或者自定义格式报文的一类系统。这类系统是典型的OLTP系统，要求交易处理低延时、高可用、稳定性强。

硬件架构

虽然现在整个行业里都在做去IOE，系统向x86平台下沉，分布式微服务走起，但是大多数的银行业务系统是运行在IBM P系列小型机上的，操作系统则是AIX，后台使用Oracle数据库，这种集中式一体化的架构确实是适用银行业务的，原因有几点：

1. 稳定性高。
2. 稳定性高。
3. 稳定性高。

没错，银行的业务最重要的就是稳定，撇开程序本身是否core，这种稳定性很大程度是由硬件的可用性带来的。与其我拉几十台pcserver组一个集群每天监控看哪台机器down要重启，银行更愿意选择应用系统小型机一主一备，数据库RAC双节点，简单粗暴，加上两地三中心的灾备设计，可谓高枕无忧，丢了什么也不能丢了业务连续性啊。另外，从业务的角度看，银行核心业务自身就耦合度就较高，相比起设计复杂的分布式的分库分表分片的策略，我把相关数据一股脑都扔到一个数据库实例里，业务上访问也简单，美滋滋。
当然，这种架构设计也有很多的弊端：

1. 整体性能的扩展很多时候依赖于数据库。
2. 业务设计不灵活，耦合度太高。
3. 贵。

工作久了才发现，能用钱解决的问题就不能算问题，遇到性能问题，首先想到的必然是加机器！换机器！换存储！小型机型号从几年前的550、740、770到现在的824、870系列，一代性能不行了换下一代，数据库单实例不行了上RAC双节点，再不行上oracle一体机！咱有钱～
但是话说回来，如果一个业务系统通过叠加或者更新硬件能一直有性能提升，其实已经算不错了，怕就怕给你一台垃圾机器你的应用连cpu都用不满那可就没辙了，这个情况我还真遇到过，后面可以细说。

软件架构

核心系统处理的联机交易一般是从各种前置系统发起的，通过tcp协议的异步单工长连接将交易报文发送到核心的通讯模块，再由中间件将报文转至后台业务处理进程中，后台进程则是通过万兆网络与oracle通讯。