• 快捷搜索
  • 全站搜索

从非功能需求观银行信息系统设计优化

2017-11-30 17:52:01作者:中国农业银行科技与产品管理局 张庆 来宾编辑:金融咨询网
银行业应用系统由于自身特点,不仅要实现功能性需求,更要注重如何满足非功能性需求,使得系统上线时真正可用、好用、易用。如何识别和实现软件产品的非功能性需求对于系统设计人员至关重要。

软件产品需求可以分为功能性需求和非功能性需求。银行业应用系统由于自身特点,不仅要实现功能性需求,更要注重如何满足非功能性需求,使得系统上线时真正可用、好用、易用。如何识别和实现软件产品的非功能性需求对于系统设计人员至关重要。本文从非功能性需求目标(高可用、可伸缩、高安全、高性能、易维护和经济性等)的视角,将多年来在运维管理过程中遇到的问题及解决方案进行了系统总结,提出若干如何优化应用设计来满足非功能性需求的建议,旨在进一步提升系统架构设计水平,加强系统的健壮性,减少重复性的错误,为应用研发设计、测试管理、运维管理等提供参考。

高可用

  实现应用系统高可用,需要对基础架构和应用设计两个层面进行统一考虑。基础架构层面高可用主要基于负载均衡和集群技术,较为成熟,如图1所示。对于应用设计高可用,我们借鉴基础架构高可用的设计思路和以往的运维经验,总结出以下几方面要点。

图片2.jpg
图1 企业级应用系统逻辑架构

  1.冗余设计。尽可能避免单点风险,即系统中任何一个模块出现异常停止服务时,不会影响整个系统持续对外服务。根据以往经验,总控程序、公共服务等模块容易成为单点。
  
  2.检错设计。当系统中某些模块出现故障未能按预期执行时,系统应能够自动恢复或提示运维人员手工处理,以此提高系统的可靠性。例如,日终批量执行、定时调度执行和核心数据库备份等重要操作就有必要进行检错设计。
  
  3.降低系统复杂度。系统复杂度越高,可能出现故障的环节也就越多,潜在的风险点就越多,因此在设计过程中,应本着以简为美的原则,尽可能选择成熟、简洁的应用架构,通过降低系统架构的层级和复杂度来提升系统的可用性。
  
  4.降低系统关联度。对于系统间存在交互的情况,在跨系统调用时一定要有超时机制和流量控制的设计,避免因被调用系统长时间无响应而导致调用系统引发连锁反应。系统间通信尽可能采用消息队列方式,少使用直接访问或共享内存等模式,以便在系统部署上更加灵活、更易扩展,避免只能部署在同一个系统分区中。

可伸缩
  
  银行重要业务系统面临着较高的并发访问压力,访问量会在一些重要业务时点出现较大波动,例如“双十一”、法定节假日等。为了更好地适配企业的基础架构云环境,在应用设计之初就要将可伸缩性作为最重要的设计原则之一。通常,我们可以从程序和数据两个层面来优化设计。
  
  1.程序上支持集群架构。利用负载均衡技术,将应用系统设计成多个无状态应用节点并行的集群架构。集群中各个应用节点不依赖于某个应用节点的内部资源,如内存数据、IP地址端口、文件等,即各个节点之间相对独立且对等,没有相互依赖或者调用关系,配合云基础架构可实现集群规模按需动态、弹性伸缩。
  
  2.数据拆分。对于联机交易系统而言,数据库往往是整个架构中最集中的环节,进行数据拆分的目的是为了提升系统的并发访问能力,更好地满足并发访问需求,拆分粒度需视具体情况而定。常用的拆分方法包括两种,一是按数据操作类型拆分,比如拆分成联机库与历史库,联机库进行日常交易,历史库进行数据查询分析;二是按照业务规则进行竖直拆分,比如按照地区、客户号、业务类型等业务属性拆分,拆分后的数据可部署在多个数据库,即为分库。如完全分库代价太大,也可采用单个数据库集群中由不同节点处理不同数据的方式,最大程度保证节点扩展带来的性能提升。除此以外,在单个数据库内部也可以使用分区技术对若干大表或热表进行逻辑或物理上的拆分。

高安全
  
  随着银行业信息化进程的不断推进,业务运营及日常办公都依托于信息化平台,各类重要文件及敏感数据需要通过计算机和网络进行存储和传输,信息安全问题受到行内管理层及行外监管部门的高度重视。
  
  1.敏感数据加密。对于业务系统中的敏感数据,如用户名称、密码、账户信息、身份证、交易金额等数据在传输、存储过程中必须进行加密。对于配置文件中的敏感字段,如IP地址、各类用户及口令等也应该进行加密保存,参数化管理。密钥应满足一定复杂度,且定期(3个月或更短)进行更改。
  
  2.采用加密方式进行文件传输和访问。对于信息传输和访问,建议使用SSL等安全性较高的协议替代HTTP、FTP等高风险协议,保证数据在传输及系统访问过程中的安全和可靠。
  
  3.妥善使用开源产品。除了商业软件外,共享软件、免费软件和开源软件已成为软件行业不可或缺的组成部分,吸引越来越多的企业级用户关注和使用。结合我行的实际情况,对这三类软件的管理和使用,建议如下。
  
  (1)限制使用共享软件。共享软件往往在使用时间或者功能上有一定限制,因此仅限于短时间、小范围的试用或验证,不宜大范围使用。如需大规模使用,则同商业软件相同,需购买使用。
  
  (2)谨慎使用免费软件。使用免费软件时,必须研究清楚相关的协议声明,明确“免费”所指范畴是个人使用还是商业使用,只有对商业使用免费的软件才能使用。
  
  (3)稳妥使用开源软件。建议优先选择主流的、成熟的开源软件。第一,若所选核心基础软件(如Linux)为开源软件时,应同时购买相应的技术支持和服务,以降低使用风险。第二,采用或基于开源软件源代码开发行内专有软件,应注意开源许可证类型,建议选择商业友好的开源软件及其源代码。第三,开源软件版本往往变化较快,新老版本的兼容性、稳定性、升级频度要做好合理评估,有必要做好开源软件的版本管理。第四,开源软件的稳定性通常较商业软件差、更新快,因此有必要在企业内部培养数名相关领域技术专家,以支持和推动产品使用。

高性能
  
  应用系统性能与以下两方面因素密切相关,一是应用及架构设计的水平,二是基础软硬件产品的支撑能力。前者具有主观能动性,且改善效果明显,改善过程相对容易,从运维经验来看,良好的应用及架构设计优化通常能带来几倍、几十倍甚至几百倍的提升,是解决性能问题的关键。后者作为支撑,一是要保证应用类型与基础架构相匹配,比如联机类应用和查询分析类应用所使用的基础架构存在较大差异,对于高性能场景更加难以通用。二是要分析、排除较为明显的瓶颈,比如I/O能力、网络带宽等。但总体来讲,通过基础架构调整来改善性能,投入成本高、实施周期较长、改善效果有限。
  
  1.应用拆分设计。主要体现在如下三个方面。
  
  (1)联机与批量拆分。联机交易系统对交易的响应时间及稳定性非常敏感,其特点是小事务、高并发、低带宽、高IOPS;而批处理则要求最大化利用资源,在最短时间内完成,其特点是高并行、低并发、高吞吐。一套基础架构往往难以同时满足两种业务类型的性能需求,因此建议应用设计上做到联机交易与批处理分开,隔离不同类型交易在资源使用时的相互影响。
  
  (2)联机交易与查询交易拆分。对于存在大量历史数据查询需求的应用系统,可将历史数据从联机交易应用中分离出来,单独构建一套历史数据查询系统。这种设计有两方面优点,一是能够控制联机交易数据库的数据量,保证联机交易性能。二是历史数据查询系统能够按照一定维度分库、分表建设,如按年度、月份、地域等,容易实现多服务器、多库、多表的集成。
  
  (3)功能模块拆分。对于访问压力接近单个数据库处理能力上限的应用,如日均交易量达到千万级别的应用,建议按照业务功能模块拆分成若干个相对独立的子系统。如图2所示,共享数据集中部署,由共享数据服务器以服务的形式提供给其他子系统访问。

图片3.jpg
图2 按功能拆分的多数据结构

  2.分散热点。热点是指大多数甚至几乎每笔交易都会访问的应用或系统组件,通常,热点是整个系统的性能瓶颈所在,因此在进行应用设计时应尽量避免某个常用组件、模块、数据库表成为全局热点。在设计之初通常难以规避掉所有热点,对于系统上线后出现的热点问题,我们可采用降低热点工作压力或分散热点的方式来降低对系统资源的竞争。
  
  银行业务中常见的热点有交易计数器、日志计数器及热表等,对于计数器类热点问题,建议各应用服务器预分配交易号段或日志号段,采用定期同步或者事件触发同步等方式进行汇总统计。对于热表,建议采用表分区技术、缓存加载、查询分页等技术降低物理I/O数量。

易维护
  
  系统上线后仍会面临各种业务功能及基础架构方面的变更,因此为了减轻应用和系统运维工作量,减少变更所需时间,应用系统有必要秉持易于维护的设计理念。
  
  1.高内聚、低耦合。高内聚,即应用中单个模块内部应尽可能完成一系列极为相关的功能,高内聚设计能够提升系统的可维护性和可重用性。低耦合,即尽量降低两个模块之间的相互依赖,如程序中应尽量使用DNS或主机别名,而不是绑定固定lP地址,这样当lP地址变化时对应用无影响。
  
  2.参数化配置。建议统一将系统变量或环境变量以参数形式放在配置文件或数据库中管理,当需要进行调整时,仅需要修改对应配置项即可。
  
  3.良好的日志设计。日志能够帮助应用或系统维护人员在问题诊断时快速定位、查明原因。为方便调试,可通过参数化配置便捷调整日志的详简程度,明确输出问题代码所在的模块或函数以及触发异常的变量值等信息,以便快速定位。
  
  4.自我状态检测。应用系统具有自我状态检测功能,并对外提供访问接口,供公共的集中监控系统获取应用运行状态信息,便于较早发现运行时的各种异常,提醒运维人员尽早处理,将问题化解在萌芽状态。

经济性
  
  经济性的原则主要是根据应用系统的重要性等级设计与之相匹配的架构。例如,直接面向外部客户服务的应用或对对外服务间接产生影响的应用,服务中断的成本很高,社会影响较大。因此不论从应用设计还是基础架构选型都应优先考虑成熟、稳定、高可用、高性能的解决方案,而对于内部服务且可用性要求相对较低的应用在架构设计时要控制成本,满足业务运营要求即可。总体来讲,在研发投入和基础架构投入方面寻求比较合理的均衡点,以获得最佳投资回报率应该是我们共同追求的目标。

(文章来源:金融电子化杂志)

扫码即可手机
阅读转发此文

本文评论

相关文章