某银行云计算架构演进及思路分享.doc

? ? ? ? ? ? ? ? 某银行云计算架构演进及思路分享 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 一、前言 金融的本质是以简单、有效的方式连接资金盈余者和资金短缺者，服务于实体经济。金融的数字化转型方向是对金融本质的回归，通过新型科技手段，提高金融服务的效率，降低金融服务的成本，落实普惠金融，支持我国经济的转型。金融的数字化转型是利用移动互联网、物联网、区块链、大数据、人工智能、云计算、安全等金融科技技术，对金融的数字化改造，打造“三个能力，实现一个目标”，“三个能力”是数字生态能力，链接人、物、企业，实现消费互联网、产业互联网与金融的深度结合；打造金融智能能力，以数据为生产资料，驱动业务决策，提高效率，服务长尾客户；打造业务敏捷能力，实现业务低成本试错、持续迭代和优化。“一个目标”是数字金融的目标，为客户打造极致的数字化体验，以高效的方式满足不同客户的金融服务需求，推动客户与业务的增长，实现金融的普惠。面对这一新的能力和目标，金融同业加速数字化进程，从产品创新、客户旅程、组织体系、 IT 架构等方面进行数字化改造，实现从简单的产品服务线上化向全面的经营管理数字化跃升。以金融科技破解发展难题和助力商业银行数字化转型，已成为全球银行业共识。在这样的背景下，本文将从 IT 架构的视角，以我行在不同数字化改造阶段，云计算架构演进的过程和思路为例进行梳理和总结，旨在厘清在云计算不断的技术变革下，我行的跟进策略和架构抉择思路，包括物理机 ” 云 ” 架构、集成云架构、集成 + 原生“混合”云架构，希望对同行有一定的借鉴和参考价值。 二、物理机 ” 云 ” 架构阶段 除开近年来新兴的民营银行和村镇银行，在 IT 架构的演变过程中，物理机架构阶段几乎是国内每家银行都必经的阶段。在这个阶段，我行当时的业务种类和信息系统没有现在这么繁多，包括核心、交易、管理和开发测试类的业务系统运行环境总共仅有 30 余个 Power 小型机分区和不到 50 台 X86 服务器，承载着我行核心、柜面、网银、手机银行、中间业务、银行卡、大小额支付、财管等主要业务系统的生产和开发测试的运行环境。后来随着我行业务的迅速发展，采购了大量的 Power 小型机和 X86 服务器，这些设备基本都随业务系统建设项目购买，烟囱式的供给，高配低用、专机专用、资源孤岛的情况普遍存在，而一些迫切需要资源扩容的系统却没办法第一时间得到满足，但总体计算下来，整体的 CPU 、内存等资源使用率又非常低， 90% 的时间在沉睡。因此，我行的迫切想法之一是通过某些技术手段来实现资源整合和共享，大幅提高资源利用率。 另外，一方面随着我行物理设备采购量的增加，数据中心机房的空间、能耗、制冷问题越来越突出，严重制约了业务的发展速度。另一方面，单机的性能也逐渐无法支撑业务应用的需求，各种系统、数据库性能调优，系统剥离、迁移工作相继开展，科技人员疲于奔波于日间运维和夜间优化，自建新机房、租用电信 IDC 机房过渡成为了当时面对机房空间问题的唯一选择，设备机房搬迁也开展多次。因此，我行的迫切想法之二是通过高资源容量的设备来集成或整合这些物理机，减轻机房能耗和空间压力。 最后，业务发展带来了大量新业务系统建设和上线的需求，然而按照之前设备随项目采购的方式，所需资源供给周期过长，进而造成上线周期非常漫长。除此之外，新系统投产前的基础运行环境准备也是非常耗时耗力，全部由人工安装、搭建、配置，参数配置不规范，也造成了日后系统的各类风险隐患，运维压力巨大。因此，我行的迫切想法之三是通过预建资源池和自动化部署的方式满足业务系统快速开发测试和上线对资源的需求，提升应用的敏捷性。 三、集成云架构阶段 在以上迫切需求和想法的刺激下，我行开始按照设备类型的不同，逐步探索相应的解决方案，并通过采取小规模试点新应用、总结试点成果并制定规范，大规模标准化部署应用三步走战略落地解决方案，例如针对 Power 小型机资源我行在不同网络安全分区建设了多个 PowerVM 资源池，每个资源池由若干台高配小型机组成；针对 X86 计算资源我行分步分别建设了 VMWARE X86 资源池和 KVM X86 资源池，提升了应用节点分布式的部署能力；针对存储资源我行建设了存储虚拟化资源池，纳管整合了多套异构存储，引入了存储性能分层，增强了数据跨存储迁移的灵活性。通过以上这些虚拟化和整合的技术方式，的确解决了我行在物理机架构阶段的大部分问题，落地或者迁移到虚拟化资源池中的业务系统也充分感受到了资源供给的便利性和一定的弹性，整体资源利用率得以提升，机房空间压力也大幅减轻。 然而随着资源池规模的不断扩大，应用敏捷性要求的进一步深化，大规模应用集群化部署要求的提升，资源服务化和统一管理理念的加强