2.2 开放平台基础架构设计原则

为满足业务连续性要求，提供更可靠、更高效的开放平台系统服务，本研究在银行开放平台基础架构建设方面遵循以下原则：高可用、可扩展、高性能、高安全和易维护。其中，高可用、可扩展和高安全是银行信息系统的根本属性，在系统架构设计过程中应始终关注，确保系统上线后能够平稳运行，并且能够满足监管部门日趋严格的安全性要求；高性能和易维护是银行系统的关键属性，这直接关系到整体系统运维的效率。

2.2.1 高可用

系统可用性是应用研发人员在整个系统设计、研发、测试、投产过程中都必须重点考虑的问题，可用性程度的高低直接影响到业务系统持续对外提供服务的能力，因此，高可用是银行系统需具备的最基本的要求之一。

实现系统的高可用需要对应用设计和基础架构两个层面进行统一考虑。本研究针对大型银行开放平台系统基础架构层面的高可用性进行长期的、深入的、与时俱进的研究，并基于自身的技术特点制订了一套较完备的银行高可用解决方案。对于应用设计上的高可用原则，从以下三个方面进行了研究。

（1）冗余设计。尽可能避免单点风险，即系统中任何一个模块出现异常停止服务时，不会影响整个系统的持续对外服务。根据经验，银行系统的总控程序、公共服务、数据库等模块容易成为单点。

（2）检错设计。当某些模块出现故障未能按预期执行时，系统能够及时报警提示运维人员及时处理。例如，日终批量执行、定时调度执行和核心数据库备份等重要操作就需要进行检错设计。

（3）降低系统复杂度。系统复杂度越高，可能出现故障的环节也就越多，潜在的风险点就越多，因此，降低系统复杂度能够有效提升系统的高可用性。例如，不少系统的应用服务器层采用了WAS+CICS架构而非单一的WAS架构，从功能上，后者完全可以替代前者且复杂度明显更低，同时，WAS+CICS架构的高可用方案也更加复杂，更具风险。

另外需要加以说明的是，应用系统的高可用性并非依赖某个硬件设备或者软件产品的可靠性来保证，高可用是一个全局性问题，需要综合考虑软件设计和基础架构设计两个层面才能解决。

2.2.2 可扩展

银行的应用系统面临着较大的并发访问压力，并处于持续快速增长的阶段。一方面银行的客户数量巨大，且逐年递增；另一方面随着服务种类的增多以及服务渠道的便利，银行的实际业务量呈几何式增长。以网上银行为例，短短的两三年之内，业务量就从百万级增至几千万级，年均增长率高达70%以上。因此，在系统基础架构建设时就要将可扩展性作为最重要的设计原则之一。

关于可扩展性，需要从系统架构和应用设计两个方面加以考虑。

（1）在系统架构设计之初，可扩展性就成为一个重要的系统属性。在负载均衡集群架构的系统中，可以通过增加负载均衡设备或者服务器设备实现系统资源的横向扩展；对于数据库服务器，可以通过数据库的拆分实现数据库系统资源的扩展；对于存储设备可以通过SAN网络的合理规划和存储空间的虚拟化，针对不同需求的系统对存储资源进行扩展。

（2）在程序设计时，需要考虑可扩展性。应用程序需要适应开放系统的负载均衡的多应用节点集群机制，集群中各个应用节点不依赖于某个应用节点的内部资源，如内存数据、IP端口和文件等，即各个节点完全独立对等，不存在相互依赖和调用关系，以便于系统资源的动态弹性扩展。

2.2.3 高性能

评价银行系统的性能主要有两个指标：一是吞吐量，即单位时间能够处理的交易量；二是响应时间，即用户触发一个功能到获得反馈所需的时间。对于某个特定的业务，银行系统的性能与以下两方面因素密切相关：一是应用程序的质量；二是基础软硬件产品的支撑能力。前者具有主观能动性，后者为前者提供服务的同时自然也形成了约束，两者相辅相成，不可分割，需要综合考虑，统筹规划。

银行系统基础架构的高性能可以从系统层面和应用程序层面分别进行分析。在系统层面，为了保证系统高性能、高效率运行，在系统投产时都采用了较新的基础软件版本和业界高端、高配的硬件资源，包括小型机服务器、PC服务器和存储设备等来提高系统的运算能力，减少响应时间，并采用负载均衡的集群架构支撑日益增长的吞吐量。同时，不断从日常的运维管理中总结经验，优化各基础软件的配置规范，使各基础软件在同一系统中配合运行更加稳定和高效。在此基础之上，进一步通过性能的趋势分析对系统进行合理化扩展。

当前，银行为适应业务发展需要和应用系统特点，不断丰富、完善基础软硬件产品体系，努力改善由基础软硬件能力不足所造成的功能缺失或者性能瓶颈等问题。但仅依靠更换高端设备和提升资源配置来提高应用系统性能是不够的，成本消耗巨大，也无法根本解决系统性能问题。通常来讲，采用提升资源配置的方式来提升性能，其效果不但逐级递减，而且还存在性能拐点，即资源扩充到一定程度反而导致整体性能下降。因此，在应用程序层面，提升应用程序质量才是解决性能瓶颈的有效途径。

2.2.4 高安全

随着银行信息化进程的不断推进，业务运营及日常办公都依托于信息化平台，各类重要文件及敏感数据需要通过计算机和网络进行存储和传输，信息安全问题受到银行监管部门及行内管理层的高度重视。

在银行开放平台基础架构建设中，严格执行各监管部门的相关规范，从系统的部署到运维紧把安全关。从系统层面有如下要求。

（1）敏感数据加密。系统内的用户、密码等文件，都通过加密方式进行保存。

（2）禁用高风险协议。例如Telnet、FTP等高风险协议，在系统内严格禁止使用，通过封锁端口等方式从技术层面加以实现。

（3）用户分离。系统管理员与数据库管理员用户分离，从人员管理和用户管理的角度提高系统的安全性。

（4）定期修改相关密码。系统管理员密码和数据库密码都必须定期修改，提高密码安全性，避免密码泄露。

（5）高级权限用户上收。具有高级权限的用户进行上收，例如root和sa等，系统管理员如需使用，需要得到职能组长授权。

（6）系统操作双人复核。任何系统上的变更操作都严格规定双人在岗复核，避免操作风险带来的安全隐患。

另外对所运维的开放平台系统需要进行分级分类管理。按照系统的服务对象、服务时间、监管要求、安全要求等，考虑应用系统的高可用、连续性设计，配置相应的基础架构和资源，如直接面向外部客户服务、7×24小时、等级保护三级以上的应用系统，与面向内部经营管理、5×9小时、等级保护三级以内的系统，在高可用设计、资源配置上有较大的差异。对于同类型系统，可按照使用频度再进行细分，如使用频度较高的联机业务系统和使用频度较低的历史查询系统在设计之初就予以区别考虑。

2.2.5 易维护

在系统运维过程中，由于硬件、软件等各种客观因素，必须考虑系统的可维护性，系统维护管理的核心是维护评估和维护验证。系统维护评估的主要工作包括判定维护申请的轻重缓急与合理性、确定维护的可行性、制订维护策略与维护计划等。维护验证是指在主要验证系统维护后，确定是否实现了维护目标、应用程序运行是否正常、支撑的业务运营是否正常等。

一般的，联机系统对开放平台系统连续性要求很高，对系统维护的时间要求比较严格，因此，提高系统架构的易维护特性对于系统和应用的持续服务能力非常重要。集群架构的系统易维护特性和高可用性相辅相成，即可用性高，易维护性也高。在一个应用服务器集群的架构中，即使其中一台或几台应用服务器出现异常，也几乎不影响业务，系统维护可在生产调度部门的协调下，寻找合适时间进行统一维护；而对于非集群架构的系统，系统维护则尽量在停业时间或交易低谷时间进行，对人员技能的要求较高，维护成本也较高。