系统架构师论文-论软件的性能优化设计

论软件的性能优化设计

[摘要]

本文结合我2008年在某人民银行实施的E户通电子转账系统的经历，就软件的性能优化设计进行了详细讨论。在系统的设计中针対实际应用环境主要从以下几方面対系统性能进行了优化设计：

• （1）选择当前成熟的三层C/S体系结构进行开发，以减轻数据库服务器的负担；
• （2）优化数据存取策略以降低系统运行対网络带宽的要求；
• （3）対客户端应用进行优化，如减少数据请求量、相关的处理利用多线程进行以提高系统的响应速度。通过 以上优化设计，系统满足了企业百万级以上主题数据库处理要求，系统开发获得了成功。最后対系统中存在的不足进行了简耍的总结，如未考虑查询的需求等等。

[正文]

近年来，各银行的信息化发展非常迅速，直接带动了银行中间业务的发展。多年的建设，已经在中间业务上建立了多个业务系统：如行内的通存通兑系统、系统、定期贷记系统等。由于这些系统都是由各银行的内部需求为主导建设的，单个银行系统内部的服务，难以实现银行间的服务。如以银行代收水电费为例，代收水费，农行能代收电费，老百姓如果需要同时交纳水电费，就必须同时在这两家银行开户，十分麻烦。与此同时，银行因开展业务的需要，不得不与不同的收款单位联网，如水厂，电厂等。数量一多，银行也很麻烦，安全控制越来越复杂。老百姓和银行都迫切要求进一歩提升服务质量，实现银行中间业务联网，合理规划和利用银行的总体资源。为此,某人民银行领导经过研究决定于2005年利用自身技术力量开发设计E户通电子转账系统，作为银行间的电子转账业务支撑平台，实行7X24小时连续运行，满足银行间的跨行转账业务、定期借、贷记业务，并支持各商业银行在此基础上建设新的中间业务。我作为工程实施组组长，组建了 12人的开发队伍，全程参与了项目建设。项目从05年7月启动,06年4月结東，历时9个月。 E户通系统涉及到与相关银行、相关企业的联网，支持批量和两种业务处理模式，支持定期借记（如定期代收水电费）、普通借记（如支票）、定期贷记（如代发工资）、普通贷记（如银行间转账）、银行柜面现金缴费（如老百姓缴养路费等）、客户签约管理、网上业务授理等。除了满足以上的业务功能需求以外，还要应対如下性能方面的需求：系统的大部分业务工作都由分敬全市的银行网点和联网企业受理，相应要求系统适合于分布式的应用环境并提供较好的性能，要能支持500个并发实时处理；必须在较小的网络带宽占用下完成日常业务处理，在使用64KB的DDN与我系统连接，要求实时业务处理（128字节/笔）要求在20秒以内完成；対于批量业务数据采取包处理制，最大800笔一包（约150KB）,要求対包中每笔数据进行MAC验证正确后转发至相关银行，每包处理时间不能超出45秒;要求查询时，最迟必须在15秒内返回结果；资金清算，报表统计与生成工作等，不能影响其它业务的正常进行。 根据银行的业务和管理特点及上述提出的対软件性能方面的要求。在対软件的性能优化设计中我和系统分析人员进行了系统分析：因为该项目的硬件投资较为宽裕，可以购买性能较好的服务器。因此，系统分析主要集中在数据库的设计和编码问题。対于500个并发问题，考虑到目前主要商业银行已经实现数据集中，各银行网点的交易数据是通过其管理行发起，交易量会很多，但是银行总量不会很多，因此交易模式拟采用长连接模式，一方面是保证交易效率，一方面是保证交易可靠性，简化设计。由于是异构环境开发，最好采用成熟的应用服务器；対于实时交易时间问题，数据包的大小不是问题，关键是合理安排交易各区段的时间划分问题，考虑到受理方的处理能力，应至少保证它有10秒的处理时间；対于批量系统的时间要求，主要在于两个方面：T MAC验证的时间；二是対包內数据的区分和路由转发。其中后者是重点，需要在网络实环境下进行验证。対于查询性能要求，考虑到主要是対交易历史的查询，应适当分离当前库和历史库。 鉴于以上的分析，我们在系统开发中做了以下的设计和安排：首先我们选择了目前在数据库开发方面非常成熟的BEA公司的WEBL0GIC应用服务器模式，数据库服务器采用SYBASE EAServer。这样，系统具有良好的兼容性与可扩展性的同时，也为系统的性能改善提供了可能。 其次，在系统中我们根据业务处理分敬在异地的特点，采用了三层C/S体系结构，通过三层C/S体系结构的设计可以将数据库的访问及业务处理逻辑移到应用服务器进行。由于系统应用特点，我们在应用服务器的设计中主要采取了长连接池和负载均衡的技术来提高系统性能。対于客户的新数据库连接我们首先去查找连接池中是否有可用的连接，如果没有才则建立之，否则直接利用连接池中的连接来处理客户端的请求，这样做可以有效降低系统因建立与数据库的连接而带来的性能影响，同时也可以较好的节约系统资源。我们针対系统主题数据库容量上百万及日常业务处理繁重的情况，充分利用BEA WEBL0GIC应用服务器系统提供负载均衡的功能，如在业务处理高峰期系统将会自动通过调配服务器组的利用率，提高了应用服务器的响应能力。同时，在系统开发中我们采用了大量的存储过程対业务进行处理，既简化了业务逻辑变化带来的雄护工作重，在提升数据库服务器的处理能力也提高了系统的性能。 第三，合理确定实时交易的时间区段。対于此类交易，我方只是转发,处理的重点在于受理方。受理方可能有各种原因会导致时延。因此我们设定受理方有10秒的受理时间,若超过此时间，我方将会自动提示发起方业务超时。为防止业务多次超时引起系统等待造成效率下降，我们在程序中设置了阈值，対达到阈值的网点实行交易限制。 第四，対于批量交易处理问题，在某某研究所的大力支持下，我们找到了合适的网络MAC加密机，能够满足系统対MAC运算的时间要求。我们要重点解决批量业务交易包问题。为此，我们需要第一手数据。我们模拟了一批数据，进行网络实环境的测试，我们发现，在数据包满载且包内数据目的地为不同银行的时候，在交易高峰期，很容易超时。一方面是受理银行可能超时，一方面是中心端可能超时。因此，经过仔细分析，我们确定以下组包原则：按照业务种类和单一受理行组包；业务发起方只需要关注业务包是否发送到中心,而不必关心是否到受理行。这样，一方面可以简化中心端的操作，另一方面是发起方等待时间短。 第五，合理规划设置查询服务，专门设置查询服务器，提供対当前日以前各交易的查询活动。这样，既可以满足客户的需求，又可以有效防止対交易的影响，客观上提高了数据库的处理能力。 第六，我们在客户端主要采取GUI方式与用户进行交互，使用多线程技术対用户输入进行处理，如用户输入完相关资料在提交时，系统利用线程来进行处理，这样系统主线程就不会因等待处理结果而停顿。另外，系统在查询中也大量使用了线程技术，系统首先利用线程対用户要求的资料进行查询，待结果出来后再交给主线程将结果显示出来。在显示浏览表格或用户查询结果时并不是一下将所有的结果都从服务器提取过来，而是每次传输60条记录，屏幕上显示20条，还有40条暂存在本地，如果用户继续查看则进行“翻页"操作以提高系统的响应速度。 另外，我们将批量业务处理、报表处理等大作业重尽量在系统闲时进行处理，一方面可以缓解业务高峰期的性能压力，另外还可以实现系统性能。 通过综合利用以上技术，系统于2009年4月投入运行时就取得了较好的效果，实时交易时间一般不会超过3秒，最长15秒；系统峰信处理能力远超过设计要求，经受住了 5倍数据量的考验；批量交易数据处理一般在15秒内就得到了应答。客户查询交易一般在6秒左右得到应答。系统主要性能到了设计要求，得到了银行和企业的好评。尽管系统建设取得了成功，但是我也看到了不足之处。设计中只考虑了满足联机交易均衡负载和提高性能，但是在实际应用中，发现银行客户対交易的查询是大量的，设计的前瞻性不足，力度不大，容易引发服务器堵塞，需要进一歩考虑查询优化。 此次系统的顺利实施为我在中、大型软件性能设计方面积累了较多的经验，为我以后的工作提供了很好的帮助。同时，软件技术的日新月异也促使我要不断更新自己的知识结构，为应対不同体系结构的软件分析与设计做好准备。