金融企业IT基础架构建设现状分析及解决思路

何为IT基础架构？

ISO/IEC 42010:20072把“架构（Architecture）”定义为：“一个系统基本的组织，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及治理其设计和演进的原则上。”

TOGAF架构框架认为一个完整的企业架构应该包含以下四类：

IT基础架构则是一个比较综合的概念，我们平常所提到的基础架构狭义上讲特指网络、服务器、操作系统、存储等单元的部署方式，可以认为其是TOGAF框架中技术架构的一部分，它是一个基础的软硬件平台，更像是一个舞台，各类应用系统均可以在舞台上进行表演。显而易见，IT基础架构对企业的业务系统起着巨大的支撑作用，其建设和完善的程度将直接影响企业的业务运转效率。

金融机构的IT建设经过了十几年的发展，目前大都已经实现了“两地三中心”的模式，同城两数据中心设备的配置也都大体相同，可以实现完全互备，数据中心间的数据同步也都是采取了存储设备间的实时同步技术。由于应用系统数量较多，人员有限，在应用系统层面一般采用分级管理策略，重要业务系统在设备以及人力资源上投入较大，力求其运行稳定，其它一些非重要系统投入的资源则相对较少。虽然近年随着IT投入的不断加大，IT建设也更加理性化，但仍然普遍存在一些问题：

系统可扩展性较差，可伸缩性不足，处理性能难以与业务量增长曲线所匹配，往往为了应对少量的峰值负载，会过度配置计算资源，导致资源利用率低下。
新业务系统上周期延长，一个新应用系统部署需要经历预算、采购、开发测试、上线等过程，周期长达数周或数月，难以及时响应业务需。
服务器、存储等硬件数量和应用系统数量不断增长，IT管理和成本压力较大。
IT技术更新过快，各种新概念层出不穷，比如云计算、大数据等等，如果一味的追求跟进，往往会面临很多问题，特别是涉及到基础架构调整的技术，如果方案设计不好，则会浪费大量的时间、人力、财力，还会措施机遇。
自动化程度比较低，当前业务需求快速增长，而人力成本也增加很快，这就需要借助自动化工具完成日常的重复性工作，以提高工作效率，而当前的基础架构现状、自动化架构，以及自动化工具开发人员的缺乏，导致目前的自动化水平还不够高。
以笔者所负责的某支付类系统为例，该系统属于高并发、交易逻辑复杂、实时性要求极高的联机交易系统，要求7*24不间断运行，承担业务比较重要，如果宕机对社会影响较大，其逻辑结构图如下：

其中APP服务器采用”Active-Active” 双活架构，六台服务器均匀分布在同城两数据中心间同时对外提供服务，DB服务器采用”Acitve-Standby”主备架构，同一时间只有一台服务器对外提供服务。各服务器均为物理服务器。该系统属于交易震荡型系统，各类节假日、电商促销日等交易量将大幅增长，为了应对此类特殊日，生产系统配置了较高的计算资源，导致平日资源利用率不足20%。另外与该系统相关的还有大量的测试服务器，包括开发测试机、投产发布机、压力测试机、UAT测试机等十几台服务器。

如果采用当下比较流行的技术来对此生产系统架构进行优化是否可行？

第一：采用虚拟化资源池技术来解决资源利用率低（平日与节假日）的问题。首先，此系统属于高并发、交易逻辑复杂、实时性要求极高的联机交易系统，在交易高峰时段，32C的小型机+高端存储的配置都捉襟见肘，所以虚拟化并非最佳选择。另外，本案例中对与资源动态调度的方式要求能够适应各类计划和非计划的自动调整，虚拟化的解决方案中，目前对于此处支持的似乎并不完美，如遇交易量突增，而系统没能申请到足够的的资源，后果将不堪设想。牺牲部分计算资源来换取生产系统的稳定运行是否值得，需要各位以实际情况综合考虑。

第二：采用存储虚拟化+RAC方式实现同城数据中心数据库服务器多活，此方法服务器资源确实都得到了有效利用，但是实际整个系统的处理性能是否得到大幅提升需要进行详细缜密的测试，受到数据中心间线路质量的影响较大，同时，应用系统业务逻辑需要进行有效拆分方能够发挥此架构的优势，投入与产出是否成正比也需要仔细斟酌。

第三：将数据库改造为分布式结构，用大数据的思维来处理。分布式系统必然会牺牲部分数据一致性，在对一致性要求极为苛刻的联机交易系统中，显然目前并不适合进行分布式计算。

金融行业IT生产系统，第一原则就是保持稳定，减少宕机时间，同时又要求提高生产效率，所以整个生产系统架构在资源利用率与要求稳定可靠的原则之间如何取舍，是一个颇为头疼的问题，需要懂得平衡之道。

反之，开发测试环境相对生产环境而言，对成本、灵活性和快速响应的要求则更高，对性能则一般无太多要求。现阶段开发测环境的管理仍然依靠人工来进行，需要多部门协调工作，从机器购买到进入机房、网络部署、IP地址分配、操作系统安装、中间件部署等等一系列工作，耗时较长，也因此而导致一些项目不能及时上线，错失良机。综合目前技术发展的现状和趋势，我认为云计算的弹性敏捷部署、资源池化、灵活调度等特点能够有效的应对当前开发测试环境面临的挑战，利用完全虚拟化以及自动管理部署等技术提高各类设备的利用率，提高开发测试环境的申请、审批、部署的效率，降低IT投入和使用成本。

云计算看起来很美好，能提供“网购式”的体验，能够自动部署、能够按需计费等等，但其规划建设过程是“痛苦”的。

在物理层和虚拟层需要部署大量的虚拟化、产品化ICS（如Flexod）或Power小型机以及X86服务器、统一存储设备、SAN交换设备和网络设备，进而具有完备的计算功能组件、网络功能组件、存储功能组件、SAN功能组件、Hypervisor、PowerVM、Virtual SAN、存储虚拟化组件、虚拟路由交换、防火墙和负载均衡组件等。

资源管理层需要部署计算资源管理软件、存储资源管理软件、SAN资源管理软件、交换资源管理软件、负载均衡管理软件和防火墙管理软件等。其中计算资源管理软件应具备虚机管理、VM热迁移、可用性和物理资源管理功能等；存储管理软件应具备数据服务、IOPS管理和LUN/Share管理功能等；交换资源管理软件应包括IP/VLAN/VXLAN、应用部署拓扑结构和网络容器功能组件。

在云服务管理层需要部署云服务管理套件，其中包括用户门户、运维门户和管理门户，主要具备服务目录管理、服务请求管理、服务用量报告、服务报表、资源自动化部署、安全/容量/可用性管理和系统监控等组件。

可见一个云计算系统后台是由多么庞大和复杂的组件所构成，如果任一环节设计的不好，后期使用过程中就很难得到预想中的良好体验。在实际建设过程中，面对原有的复杂的IT系统，如何能够将原有的技术进行有效整合，能将原有资源充分利用，这都是需要考虑的问题，处理的不好，那结果可能与预想大相径庭，不但没有得到良好的体验，还增加了整个系统的复杂度，在整个云平台上又投入了大量的人力、物力、财力，往往是得不偿失，所以企业应当根据自身特点，做好规划，首先判断当前的条件是否合适进行云建设，可以先选择成熟的计算领域进行虚拟化的实施，一定程度上提高设备使用率，加快服务部署，另外一方面又能为“云”积累一定经验，循序渐进，切忌盲目跟从。

天下大事，合久必分，分久必合！今天是大集中、虚拟化、云计算，明天也许就是分布式的天下，IT技术日异月新，更新速度之快令人咂舌，所以银行应当立足自身特点，选择适用、有效、成熟的技术，而非完全照搬时髦、先进、高端的技术，构建出能够满足业务长远发展需要的可扩展的基础架构才是重点。

架构没有好与不好，适合自己才最重要！