谈谈银行核心系统建设--篇7：核心系统的性能压测
文章来源：e路向上，文章仅供个人学习
“服务不可用”和“资金损失”（下称“资损”）是所有计算机系统的噩梦，由此引出在商业银行的所有系统中，与此有关的“电子渠道”（手机、网银、自助渠道）、“柜面”、“核心”及“支付系统”，在架构设计上，系统的高可用设计及资金安全设计显得尤为重要，这四类系统，也通常作为灾备服务建设优先选择。对核心系统建设而言，功能建设因为事关业务方，自然会被充分关注，但IT团队自己作为需求方的，系统的技术需求–性能足够、高可用、高可扩展、低运维成本等需求，则往往容易被忽略。其中，高可扩展、低运维成本等，真正上线后，带来的问题最多就是麻烦和多花点钱，而性能问题和高可用问题，则易导致系统建设遭受挫折，引发严重舆情和监管处罚。因此，为保证核心系统的吞吐能力及性能表现，系统的性能压测必不可少–当然，对应的前提是在建设前期，就对系统的吞吐量、并发连接数、并发线程数都已经做过评估和设计。本文就此问题做些探讨–更多来自项目经验的一家之言，与经典理论不符之处，仅供参考。
系统的吞吐量评估
本文以TPS（每秒交易量）作为吞吐量评估的关键指标，交易指包括开户、存取款、转账、利息调整、账户冻结/解冻、账户余额查询、账户信息查询（账户列表、账户交易记录查询等复杂查询功能，默认通过服务拆分做了剥离，一般不建议纳入）等交易类型在内的交易。
系统指标定义阶段，有三个关键指标需要关注，分别是：日均交易量、峰值交易量及年均增长率。关于新建系统数据库资源、缓存、应用服务器资源评估（CPU / MEM / 存储）评估的资料汗牛充栋，本文不狗尾续貂，回到商业银行核心建设的客观条件进行讨论：1、除新开银行外，多数银行的核心系统建设做的是替代，有大量的历史交易数据可以参考；2、与创业公司或者更加市场化的公司相比，商业银行相对充足的IT预算保证了计算资源的配置不会需要精打细算（虽然也不是可以不计成本）。在这样一种条件下，商业银行在进行系统吞吐量评估时，就可以采用相对简单的评估办法：
1）、参考同资产规模体量的、类似经营形态的同业的吞吐量指标。比如一般中小银行（5000亿规模上下），核心系统的TPS范围一般可选定在500~1000之间，一般3万亿以上规模的商业银行，TPS需要设置到>10000，几大行的TPS需要做到多少，不敢揣测，估计可能是10万+级别的。更准确评估的当然还要看账户数，以及业务形态，比如以互联网小额、分散为特点的5000亿，跟以对公业务为主的地区性商业银行，显然不可同日而语，但为了行文方便，需要进行适当的取舍。
2）、更准确的办法是参考银行之前的交易量。从旧系统拿到比如过去3个月的平均日交易量，并基于历史交易数据，判断一段时期以来的峰值交易时段（比如零售业务的峰值交易时段通常出现在上午9:0010:00的交易时段，而对公业务通常出现在下午3:004:00左右），并以1小时或者30分钟为时间窗口，测算这一交易窗口中，业务的峰值交易笔数，进而推测出旧系统的峰值TPS。举个例子：基于历史交易数据，我们分析出历史数据表明，个人活期存款峰值交易时段出现在9:0010:00时间段，过去3个月每天这个时段的各类交易平均笔数为30万笔，则这一峰值时段的TPS可以近似地测算为300000/3600 = 84tps。需要注意，这只是峰值交易时段平均的TPS，因为交易笔数被平均的原因（例如，通常节假日交易笔数会显著下降），这并不等同于需要支持的峰值TPS，峰值TPS可以选择这一区间最高一天的交易笔数，比如48万笔，则以此数据测算出来的TPS则为134TPS。这个仍然不一定是峰值交易量，要得到更准确的数据，还需要获得特殊交易日期的交易量数据，最典型的如双11，月末，银行有发售特殊产品（比如国债、大额存单）等日期，获取此类日期最高峰时段的交易笔数数据，进行测算，在这一例子中，比如我们将双11 00:001:00的交易笔数设定为60万笔，则需要支持的峰值TPS变为167TPS。在这个例子中，我们可以简单的在此基础上，设定我们的TPS指标（其实这些工作在项目需求阶段，就应该作为性能指标需求的工作做好），这里的TPS指标，先以满足系统切换的首日流量洪峰为目标（对业务增长的支持，从架构设计的角度，更多应该通过可扩展架构设计来满足），可以简单粗暴地在峰值TPS的基础上，增加一倍，然后再留下50%的冗余，将TPS设定为：167 + 167 *（1 + 50%） = 417。（勿怼，没有理论依据，只是笔者的经验，另外有个前提：不需要对投入过于精打细算，不出事才是关键。本文纯抛砖引玉，供有缘人参考）。需要特别注意的是，这里基于旧系统测算的交易笔数，有个关键前提，新旧交易类型是同一口径的，比如都是“存入、支取、冻结、解冻”等等。
3）、不可忽视的交易响应时间。交易时间直接影响到客户体验，尤其核心系统的交易响应时间对全链路服务具有全局性影响，并直接影响到系统吞吐能力，需要特别关注。通常，核心系统的关键交易的服务响应时间一般要求<300ms。以此为前提，可以相见，通过消息中间件异步解耦掉会计分录处理显然会节省部分的交易处理时间。再有，对于存款账户的贷记入账交易，是不是可以在完成账户可入账状态检查后，直接返回，再异步进行入账处理，甚至包括账户交易记录的insert处理，是不是也可以与主交易内容解耦…（其中当然会有复杂的数据一致性保持问题，但在需要支持高并发的场景下，CAP当然会有取舍，抛砖引玉）
4）、未来交易量的预测。对未来交易量的预测，通常需要回归到用户数（users）、客户数（customers）及账户数（accounts）增长上，以最近3年的用户或客户、或账户（核心系统用账户也许更准确）的增长率，作为未来系统的交易量增长率的参考值，测算未来10年的系统吞吐容量的情况。实操中，更多是评估未来3~5年的交易增长量情况，3年后峰值TPS = 当前峰值TPS * （1+ 预计增长率）^ 3。需要说明的是，随着弹性可伸缩架构在计算资源、应用、数据库、缓存等所有技术组件中的应用，弹性扩容变得相对容易，对银行而言，系统容量评估简单地聚焦在迎接系统切换后的流量洪峰即可满足项目的需要。
核心系统的压测
因为核心系统的特殊性，在对核心系统进行压测时，在考虑单系统压测外，还需要考虑端到端压测，以及部分特殊场景的压测（比如代发代扣业务、热点账户场景下的压测等）。
单系统压测。请求端统一采用压力模拟工具模拟交易压力发起，后端用挡板（模拟器），单一系统（服务）独立进行黑河模式下的性能测试。
单系统压测的交易包括：交易量占比高的交易，比如账户查询、余额查询、状态查询、金额冻结、金额解冻、状态设置、一对一转账、一对多转账、批量代发、代扣、热点账户混合流量等等。
场景覆盖：覆盖正常营业日峰值时段、特殊营业日峰值时段、批量提交的交易（如批扣、批量清分）与联机单笔提交交易的混合流量测试等。
关注的内容包括TPS表现、交易响应时间、对应的系统计算资源表现及稳定性–相关压测需要持续一定时间（比如持续2小时）。
端到端压测。端到端压测（也称为全链路压测）是一种模拟整个系统的真实业务流程的压测方法。通过端到端压测，可以覆盖从请求的初始点（例如：API接口）经过所有相关的服务，再返回请求者的全过程压测，可以相对准确地模拟真实的交易场景。
对核心系统建设而言，比较好的情况是核心系统建设团队主动统筹端到端压测工作，或者是外围协同团队，从保证自身系统稳定运行的目的出发，主动进行端到端压测。
端到端压测场景的选择原则：手机银行、个人网银等用户可直接触达且相对高频的交易场景；柜面与核心相关的相对高频交易；从第三方发起的，如银联、大小额、超网及支付机构发起的快捷代扣、贷记来账等业务。
端到端压测的方法：采用“多渠道模拟”方式，模拟用户在不同渠道进行的，与核心系统相关的交易和操作(混合各种不同的场景）。
端到端测试建议关注的重点内容：包括模拟正常情况下相对高频的业务流程，评估系统在正常运营条件下的性能和稳定性；模拟大比例(如：50%–投产首日)客户在短时间(10分钟)内集中登录查询账户，检验系统在瞬时的流量爆发下的承载能力；模拟类双11等特殊情形下，第三方通过代收付发起海量交易请求时的场景。
压测环境的选择。在项目建设过程中进行环境规划非常重要，压力测试通常在预生产环境进行，但出于成本考虑，预生产环境的计算资源配置通常会较生产适当简配，在该环境完成的性能压测指标，通常可以用于作为对监管报备的依据，并为真实的生产性能表现提供先手依据。对单系统而言，因为核心系统建设一般对应着新的计算资源部署，因此，一般而言，可以在生产环境对单系统做真实的压力测试–基于真实的全量迁移数据及未来的生产部署版本。
压测工具的选择。非功能测试执行基于Jmeter的性能压测平台即可，这个工具集测试脚本、测试场景、测试执行、资源监控、测试报告为一体，可快速进行性能压测，并将性能测试指标进行实施图形化展示，同时压力机资源可进行动态管理，可以满足非功能测试效率和质量要求。
生产流量下的真实压测
另一种供参考的压测方案，是在真实运行的生产环境进行压测的方式，笔者在前司工作时，曾见同事实施过，但未深度参与，供为读者提供一种思路参考。该基于生产环境的真实压测（当时的银行系统是基于阿里云构建的），压测时使用影子表和影子Topic隔离测试数据，利用服务网格的流量镜像功能，将生产流量复制到影子服务，真实模拟业务场景，在阿里云云解析DNS中配置权重路由策略，将压测流量按比例分发到指定集群（如10%流量指向压测专用的K8s节点组），或通过http请求头实现七层流量染色，由Envoy/Sidecar路由到影子服务。在DNS流量分发的精准控制、数据写入隔离、数据清理等环节，都做了很多工作，非常具有启发，有基于云原生构建的新核心系统的压测，可以进行相关探索。
结语
讲性能就不可避免地要谈到架构，云原生、微服务时代新型技术栈为从计算资源到应用的弹性扩容提供了极大的便利。云原生时代，应用层基于k8s等容器编排平台，应用服务以无状态微服务形式部署，通过动态增加Pod副本数即可实现计算资源的横向扩展；而在数据库层，通过分布式数据的分片策略，可以根据业务增长情况方便地新增分片，并通过分片中间件实现对应用的无感知适配。在这样一种架构模式下，高可用性、高可扩展性都得到了更佳的保证，由此一般性地也必然带来系统吞吐能力的大幅提升，换句话说，在全新的技术体系下，性能问题远不会如单体架构时代那样棘手，这也是技术进步的重大意义，此其一；其二，性能并不就是越高越好，所有的高标准都必然隐含着对应的成本，过度追求高性能必然导致回报率极低的IT投入（以及技术团队的怨声载道），技术的目的永远不是炫技，对一家只需要500TPS的机构而言，实现10000的TPS的架构师是不应鼓励的；其三，功能之外，性能问题以及其他的非功能问题–高可用、高可扩展、低运维成本，也都是IT管理者、架构师需要关注的内容。