如何应对银行交易系统性能下降

　　银行的交易性能下降，可先分析软硬件环境，多种判断之后，寻找到合理的解决方法。

　　银行交易系统的性能下降，这是由于后台的数据规模、应用的逻辑复杂度、客户并发的访问数在逐步增加，日积月累就会跨越最初的设计容量，从而遭遇性能瓶颈。

　　性能问题的范围

　　银行交易系统又称为银行OLTP系统（On-Line Transaction Processing），即银行联机事务处理系统，其基本特征是客户交易数据实时发送到银行后台主机进行处理，并在极短的时间内返回响应。银行交易系统一般都是实时系统(Real time System)，性能至关重要。良好的性能意味着：交易吞吐率越高越好、交易响应时间越短越好。

　　银行交易系统包括很多：核心交易系统、信用卡系统、大前置系统、网上银行、电话银行、手机银行、第三方存管、银基通等。

　　银行交易系统性能管理可概括为：客户请求是否被快速处理，系统资源是否得到合理利用，系统是否能够连续不间断地运行这三个方面。

　　决定银行交易系统性能的往往都是后台的Server系统。银行后台系统是复杂的混合体。从性能分析的角度，后台系统大致可以划分如下几类：硬件组件有服务器主机、网络等，系统软件包括OS、中间件、DBMS等，应用软件如联机应用、批量应用、定时应用等，系统架构是指组件之间的协作方式，比如应用与数据库分离运行还是单机运行等。

　　这些组件都可能成为银行交易系统潜在的性能瓶颈。不同的是，硬件组件与系统软件组件的性能瓶颈容易被发现和定位，也容易被快速处理，而应用软件和系统架构方面存在的性能瓶颈不容易被发现，发现与解决的周期会很长。

　　需要说明，系统性能问题与系统故障有所不同。故障往往是由于某些组件异常导致交易系统部分或整体无法正常工作；性能问题是指在系统各个组件正常情况下，处于瓶颈的组件过于繁忙而导致系统整体服务能力下降。性能问题得不到不及时处理也可能引发系统故障，性能问题就像亚健康，而系统故障就像患病。

　　银行交易系统的性能问题不明显时，客户和交易柜员基本察觉不到系统的异常。当性能问题逐渐积累并且爆发之后，交易系统的客户就会明显感觉到异常，客户满意度也随之下降。严重性能问题的外部症状可能有很多，举例如下：网银客户投诉增加：比如转账失败、查看账户信息超时、客户投诉POS刷卡多次失败、客户投诉短信通知不及时、客户抱怨柜面处理速度太慢、柜面反馈交易缓慢、柜面反馈交易失败等等。

　　主动发现问题

　　当银行因交易系统性能问题产生客户投诉后再开始应对处理，就比较仓促和被动。所以最好是能在日常的运营维护中发现系统的性能问题——当问题还没有影响到业务本身，处理起来会比较主动。

　　利用监控工具和报警规则，找到问题的征兆。在银行交易系统运行中，大多数性能问题可以从操作系统、网络、数据库、中间件的细微变化中反映出来的，例如内存过度消耗、CPU过高使用率、进程频繁启动或数量过多、数据库会话过于繁忙、中间件队列变长等。所以常见的监控对象通常是：CPU、磁盘I/O、网络、文件系统、进程、系统日志、数据库负载和中间件队列等。

　　可以使用成熟的商业监控套件、也可以使用自主编写的监控软件、性能检测脚本或者软件自带的工具，比如：Quest、HP OVO、IBM Tivoli等。操作系统自身也有丰富的系统管理工具可用。对特定的系统软件，比如Oralce、Tuxedo、Informix等软件系统，需要有针对性地引入监控工具并建立报警规则。以Informix数据库为例，监控工具除了自身的onstat命令外，IDS11会自带图形化的监控工具Open Admin Tool。第三方的监控工具有台湾库柏的DBSonar软件等。在应用系统监控方面，应该有对应的监控工具。简言之，如果全部性能组件都有相应的监控工具和报警规则，则比较有利于快速发现问题。

　　收集各组件的性能数据。银行交易系统出现性能问题的时间段可能很短，也可能没有规律。为了方便专家分析，在交易系统出现性能问题的最短时间里，应尽可能收集该时段中各性能组件的运行数据，不管问题发生在操作系统、存储、数据库、应用服务器还是WebServer等；我们需要借助软件工具来收集有用的系统性能信息，提供丰富的实时的视图和报表，直接在每个被监控的系统中搜集端到端的准确信息。

　　应高度重视数据库系统运行信息的收集。很多情况下，数据库运行信息收集需要一些辅助手段，比如informix在版本11之前的性能监控不够完善，获取会话信息比较困难，即使借助DBSonar等工具获得的信息也可能是不准确的。往往还要借助一些其他的工具或脚本来收集数据。

　　对应用方面的数据收集还可以开启报文记录功能，利用存储系统对数据库和文件系统做快照，能方便重现问题，并且可分析和验证解决方案是否有效。

　　定位性能瓶颈

　　发现银行交易系统的性能问题之后，需要定位性能瓶颈。可以遵循这种查找顺序：从近期有变更的组件到近期无变更的组件，从应用类组件到系统类组件，从软件组件到硬件组件。

　　请银行交易系统的主要相关厂商协同分析是好办法。明确供应商责任有利于快速解决问题。在各供应商收集的性能信息基础上进行实时和历史分析，可大大缩短问题查找和等待的时间。各厂商的技术资源还有一定优势，它们一般都有丰富的性能问题案例库，结合性能问题特征，可以采用分段排除法，最后定位系统的性能瓶颈位于哪里。

　　实践当中应注意，性能瓶颈所在环节也许并非是触发性能问题的初始原因。很多的情况下，应用本身的设计缺陷会造成数据库过于繁忙。有的数据库的BUG也可能造成数据库服务器CPU利用率过低或过高。不同的原因也许会造成相似的性能问题症状。

　　解决性能问题

　　解决性能问题要明确触发性能瓶颈的初始原因。可以参考专家建议和方案，有选择地进行实施。实施前需要进行反复的验证和评估，最后在现有方案中确定最优的解决方案并进行实施。不同性能组件的解决方法有一些常规的处理方法。

　　硬件组件问题：常见的处理办法是对硬件进行扩容或者升级，可以快速解决。比如：对存储系统的更新换代，对服务器增加CPU数量、扩充内存量、升级存储光纤卡等；

　　系统软件问题：常见的处理办法是升级为新版本或安装新补丁、或者调整系统配置参数。系统软件升级环节看似简单，但却有可能引起兼容性的问题。可以参照系统软件厂商的官方意见。

　　应用本身的问题：应用问题多属设计问题，常见的做法是对设计拙劣的应用代码逐步优化。下列的做法一般有利于交易系统性能的提高：交易系统的日志采用异步方式记录，优于同步方式记录日志；交易事务小型化能减少锁冲突；记录高开销的SQL，分析SQL的优化写法等。

　　系统架构的问题：交易系统在架构设计之初就应将灵活性、可扩展性纳入其中。当某个性能组件成为性能瓶颈，只需要在配置上增加同种组件的数量即可，方便快捷。拙劣的架构可能由于不具备可扩展性而成为性能瓶颈，引发性能问题。

　　银行交易系统架构往往有大量成功案例可以参考，这要经过大量压力测试的实验数据来筛选最优架构方案。

　　银行交易系统的性能问题如果能得到持久的维护和管理，将大大延长交易系统的生命周期，这无论从银行业务的发展还是节约IT成本的角度来看，都是很有必要的。包括以下几点：建立并维护性能问题知识库，将每次性能问题的处理信息备案并总结，积累知识；不断充实交易系统性能指标，定期分析系统运行报告；通过定期的压力测试寻求银行交易系统处理能力的极限值，探索交易系统架构多种扩展方案的优劣，提前发现可能引起性能下降的不恰当的应用变更；建立应急预案，在交易系统发生突发性能问题并难以就地解决的情况下，可以从业务/技术两方面降低系统压力。