银行云计算架构演进的三大阶段和抉择
【作者】邓毓，某农信社资深骨干工程师，主要负责Power，x86及相关存储、数据库、中间件、应用负载、监控、备份和各类虚拟化平台等的运维及管理工作，一线实施经验丰富，对双活数据中心及云平台建设和监控有着深入的见解。
一、前言
金融的本质是以简单、有效的方式连接资金盈余者和资金短缺者，服务于实体经济。金融的数字化转型方向是对金融本质的回归，通过新型科技手段，提高金融服务的效率，降低金融服务的成本，落实普惠金融，支持我国经济的转型。
金融的数字化转型是利用移动互联网、物联网、区块链、大数据、人工智能、云计算、安全等金融科技技术，对金融的数字化改造，打造“三个能力，实现一个目标”。“三个能力”是数字生态能力，链接人、物、企业，实现消费互联网、产业互联网与金融的深度结合；打造金融智能能力，以数据为生产资料，驱动业务决策，提高效率，服务长尾客户；打造业务敏捷能力，实现业务低成本试错、持续迭代和优化。“一个目标”是数字金融的目标，为客户打造极致的数字化体验，以高效的方式满足不同客户的金融服务需求，推动客户与业务的增长，实现金融的普惠。
面对这一新的能力和目标，金融同业加速数字化进程，从产品创新、客户旅程、组织体系、IT架构等方面进行数字化改造，实现从简单的产品服务线上化向全面的经营管理数字化跃升。以金融科技破解发展难题和助力商业银行数字化转型，已成为全球银行业共识。
在这样的背景下，本文将从IT架构的视角，以我行在不同数字化改造阶段，云计算架构演进的过程和思路为例进行梳理和总结，旨在厘清在云计算不断的技术变革下，我行的跟进策略和架构抉择思路，包括物理机”云”架构、集成云架构、集成 原生“混合”云架构，希望对同行有一定的借鉴和参考价值。
二、物理机“云”架构阶段
除开近年来新兴的民营银行和村镇银行，在IT架构的演变过程中，物理机架构阶段几乎是国内每家银行都必经的阶段。在这个阶段，我行当时的业务种类和信息系统没有现在这么繁多，包括核心、交易、管理和开发测试类的业务系统运行环境总共仅有30余个Power小型机分区和不到50台X86服务器，承载着我行核心、柜面、网银、手机银行、中间业务、银行卡、大小额支付、财管等主要业务系统的生产和开发测试的运行环境。后来随着我行业务的迅速发展，采购了大量的Power小型机和X86服务器，这些设备基本都随业务系统建设项目购买，烟囱式的供给，高配低用、专机专用、资源孤岛的情况普遍存在，而一些迫切需要资源扩容的系统却没办法第一时间得到满足，但总体计算下来，整体的CPU、内存等资源使用率又非常低，90%的时间在沉睡。因此，我行的迫切想法之一是通过某些技术手段来实现资源整合和共享，大幅提高资源利用率。
另外，一方面随着我行物理设备采购量的增加，数据中心机房的空间、能耗、制冷问题越来越突出，严重制约了业务的发展速度。另一方面，单机的性能也逐渐无法支撑业务应用的需求，各种系统、数据库性能调优，系统剥离、迁移工作相继开展，科技人员疲于奔波于日间运维和夜间优化，自建新机房、租用电信 IDC 机房过渡成为了当时面对机房空间问题的唯一选择，设备机房搬迁也开展多次。因此，我行的迫切想法之二是通过高资源容量的设备来集成或整合这些物理机，减轻机房能耗和空间压力。
最后，业务发展带来了大量新业务系统建设和上线的需求，然而按照之前设备随项目采购的方式，所需资源供给周期过长，进而造成上线周期非常漫长。除此之外，新系统投产前的基础运行环境准备也是非常耗时耗力，全部由人工安装、搭建、配置，参数配置不规范，也造成了日后系统的各类风险隐患，运维压力巨大。因此，我行的迫切想法之三是通过预建资源池和自动化部署的方式满足业务系统快速开发测试和上线对资源的需求，提升应用的敏捷性。
三、集成云架构阶段
在以上迫切需求和想法的刺激下，我行开始按照设备类型的不同，逐步探索相应的解决方案，并通过采取小规模试点新应用、总结试点成果并制定规范，大规模标准化部署应用三步走战略落地解决方案，例如针对Power小型机资源我行在不同网络安全分区建设了多个PowerVM资源池，每个资源池由若干台高配小型机组成；针对X86计算资源我行分步分别建设了VMWARE X86资源池和KVM X86资源池，提升了应用节点分布式的部署能力；针对存储资源我行建设了存储虚拟化资源池，纳管整合了多套异构存储，引入了存储性能分层，增强了数据跨存储迁移的灵活性。通过以上这些虚拟化和整合的技术方式，的确解决了我行在物理机架构阶段的大部分问题，落地或者迁移到虚拟化资源池中的业务系统也充分感受到了资源供给的便利性和一定的弹性，整体资源利用率得以提升，机房空间压力也大幅减轻。
然而随着资源池规模的不断扩大，应用敏捷性要求的进一步深化，大规模应用集群化部署要求的提升，资源服务化和统一管理理念的加强，都意味着散沙式的虚拟化资源池只能是架构转型过程中的临时中转站。在这个阶段，我行的迫切想法则变成了同构虚拟资源池云化、异构多云管控统一化，多云软硬件编排自动化。通过采用不同技术方案的软件，将基础资源架构（计算、存储、网络、中间件）集成到一起，在上面再做一些定制化的二次开发，最终形成所谓的集成云架构。
集成云架构深层次可以理解为：企业积极地混合多个云平台以提供一个协调的服务集合，并利用每个云计算服务/云平台的不同优势。集成云架构建立在两个基本原则之上。首先，每个集成的云平台都提供了强大而丰富的功能，可以为一个或多个业务功能提供服务。它们可以独立行动，而无需与其他云平台集成;然而，当适当地集成时，其总和大于非集成个体的能力。这些功能对于每个云平台都是独一无二的，并且在多个云平台(如单点登录支持、标准Web服务支持)之间是通用的。其次，通过集成云架构能够体验多种不同平台的资源，这些资源间并不相互排斥，可以引入专门的“聚合”接口以在一个或多个平台上实现优化和统一的体验。
在这些理念和想法的驱动下，我行分步开展了以下工作：一是同构虚拟化资源池云化，形成不同设备类型的基础设施云（IaaS），以服务的方式提供计算、存储网络等资源。例如通过PowerVC软件管控所有的PowerVM虚拟化资源池和存储虚拟化资源池，通过Vcenter软件管控所有的Vmware X86虚拟化资源池，通过CloudManager软件管控所有的KVM X86虚拟化资源池等等。二是异构多云管控统一化，采用成熟的云管平台集成多套异构基础设施云，进行多云资源、服务、和运维管理。一方面是资源层的统一，通过统一的资源适配接口屏蔽各异构资源的差异，同时支撑上层的服务编排与部署，实现对所有异构的资源的统一管理；另一方面是服务层的统一，通过将底层资源技术实现、部署策略和动态调配实现抽象化和服务化，实现自服务和服务目录的能力，同时集成行内各类运维、管理和流程的工具（如4A、ITSM、监控、CMDB等）。三是多云软硬件编排自动化，云管平台需要搭配一个界面友好、能力灵活、编排可视、广泛兼容的多云编排引擎来实现各类服务的可编排、可设计和自动化落地。例如我行采用的编排引擎为商用的Cloud Automation Manager,但其底层自动化核心为开源的Ansible，商用和开源的结合让服务编排兼具成熟性和灵活性。
四、集成 原生“混合”云架构阶段
集成云架构帮助我行实现了最初所有的想法和愿景，同时随着云计算技术的不断成熟和相关解决方案在我行落地生根，初步实现了软件平台即服务（PaaS）的Power和X86和谐共存的私有云，在软硬件资源层方面，的确产生了较大的成效，总体归结起来有五点：一是异构共存，所有资源都将在这一套云体系内共存；二是强化管理，提升了架构管控的力度，实现了软硬件编排模板的统一和规范化落地；三是提高效率，硬件编排结合软件编排，进一步提升资源的自动化部署效率；四是降低成本，一方面是提升了总体资源使用率，另一方面是降低了人工运维成本；五是统一门户，资源统一管理和运维，以业务为中心，通过服务的形式为业务提供支撑。
然而技术也是在随业务不断变革和完善的，业务需求日渐丰富、迭代速度不断加快，金融机构数字化转型需要有更为成熟的IT架构、敏捷交付流程和技术风险保障机制做支撑，最大限度地缩短新业务产品的研发与投产时间，快速响应细分客户需求，还要保证在更新和维护应用及软硬件系统时不对用户体验产生负面影响，即使在极端严苛的业务压力下也须始终保持顺畅的产品服务体验，保证业务连续性和数据安全,在这样的背景下，云计算不再只是解决业务对资源的快速响应和弹性扩展需求，更多的面向业务的先进技术进一步下沉到云计算基础设施中，包括面向分布式设计：容器、微服务、API驱动的开发；面向配置设计：一个镜像，多个环境配置；面向韧性设计：故障容忍和自愈；面向弹性设计：弹性扩展和对环境变化（负载）做出响应；面向交付设计：自动拉起，缩短交付时间；面向性能设计：响应式，并发和资源高效利用；面向自动化设计：自动化的DevOps；面向诊断性设计；集群级别的日志Metric和追踪；面向安全性设计：安全端点、API Gateway、端到端加密等等。这便是所谓的云原生架构（Cloud-Native），它是是加快业务产品发布速度、增强服务稳定性、提高计算资源利用率、降低运维成本的关键架构之道。云原生这个概念名词最初于2013年在技术社区中诞生，代表着一套先进架构理念的思想集合，包括了微服务、敏捷、DevOps、持续集成部署、容器、可靠、高弹性、易扩展等领先的概念和特性。
云原生代表着原生为云设计。详细的解释是：应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。在云原生之前（例如集成云），底层平台负责向上提供基本运行资源。而应用不仅需要满足业务需求还需要满足大量非业务需求，为了更好的代码复用，通用性好的非业务需求的实现往往会以类库和开发框架的方式提供。或者在SOA和微服务时代部分功能会以后端服务的方式存在，这样在应用中就被简化为对其客户端的调用代码。在发布应用时也会将这些非业务功能代码，连同自身的业务实现代码一起打包发布。
例如典型的微服务体系下的服务治理，通常是由中间件产品提供一个SDK给业务应用使用，在SDK中会集成各种服务治理的能力，如：服务发现、负载均衡、熔断限流、服务路由等。在运行时，SDK和业务应用的代码其实是混合在一个进程中运行的，耦合度非常高，这就带来了一系列的问题：一是升级成本高。每次升级都需要业务应用修改SDK版本号，重新发布。在业务飞速往前跑的时候，是不太愿意停下来做这些和自身业务目标不太相关的事情的。二是版本碎片化严重。由于升级成本高，但中间件还是会向前发展，久而久之，就会导致线上SDK版本各不统一、能力参差不齐，造成很难统一治理。三是中间件技术演进困难。由于版本碎片化严重，导致中间件向前演进过程中就需要在代码中兼容各种各样的老版本逻辑，戴着枷锁前行，无法实现快速迭代。而后有了服务网格之后，就可以把SDK中的大部分能力从应用中剥离出来，拆解为独立进程，以旁挂的模式部署。通过将服务治理能力下沉到云计算基础设施，可以让业务更加专注于业务逻辑，中间件团队则更加专注于各种通用能力，真正实现独立演进，透明升级，提升整体效率。
这样一来非业务需求相关的功能都被移到云中，或者说基础设施的中间件中去了，开发人员专注力完全置身于业务逻辑，开发出的应用也是原生地、最适合地部署于原生云架构中。除了微服务之外，原生云架构的其它几个关键“组件”，包括DevOps：云原生应用开发需要工程师面向更“云”化的DevOps流程来工作。开发和运营服务不再是一种前后顺序的关系，而是一种相互交织的合作关系。这种结合能带来更快更顺畅的开发进程。持续交付：持续交付使得单个更改在就绪后即可发布，而不必等待与其他服务一起打包发布或等待维护窗口期等。持续交付让发布行为变得常态且可靠，团队以更低的风险高频交付，并更快获得最终用户反馈。最终，持续交付会成为业务流程和企业竞争力必不可少的部分。容器：像Kubernetes这样的容器管理工具，帮助开发者自由的选择应用的部署方案，而不用关心那些关系到具体平台的具体实施。
基于以上云原生的理念和我行对云计算技术变革的思考，我行以现有集成云架构为基础，稳态运行现阶段业务系统，同时开始以积极的姿态投入至全新的原生云架构体系建设，形成集成 原生“混合”云架构。目前，我行已开始全面实施原生云战略转型，包括网络化转型、平台化转型、智能化转型与生态化转型四个阶段，前两步利用移动互联网、大数据、云计算实现网络化和平台化转型，推动自身敏捷化转型，后两步是利用人工智能、物联网、区块链、新SaaS，实现智能化、生态化创新。金融云平台是我行以本地部署的原生云架构为基础，推动下属法人金融机构的数字化建设，其作为分布式架构云技术平台,主要包含以下五大子平台，即IaaS、PaaS、DaaS、DevOps和MpaaS，整体架构图如下所示：
1、IaaS平台：作为云计算底座，它是实现云计算、形成通用功能的巨型计算机的核心部分。它屏蔽了底层基础设施的差异，使用虚拟化、分布式计算等技术将资源打散、分割成最小逻辑单元，进而形成网络、计算和存储资源池，提供可度量的、用户隔离的、安全的、快速可扩展的持续资源池供给。主要包含的组件包括：虚拟服务器ECS、虚拟网络（VPC）、虚拟存储（OSS）、负载均衡（SLB）。
2、PaaS平台：我行基于IaaS平台底座资源，引入了整套成熟的金融级分布式中间件，包括微服务、分布式数据库、分布式消息、分布式事务、服务网格等组件，利用这些组件帮助我行轻松构建大型分布式应用服务，同时提供应用管理、发布部署、运维编排、监控分析、容灾应急等全生命周期管理的PaaS平台能力，满足我行金融场景中经典和云原生架构的运维需求。
3、DaaS平台：我行通过采用大数据集成服务平台软件，来实现对TB/PB级数据的非实时分布式分析处理能力，提供海量数据的上传下载，SQL运算，MR计算和Graph图计算等离线计算，以及数据安全管理等功能。
4、DevOps平台：我行采用新型企业级一站式协同研发平台，它通过先进的管理理念和工程实践，提供从“需求->编码->测试->发布->运维->运营”端到端的协同服务和研发工具支撑，将敏捷研发、持续集成、持续交付、DevOps等理念融入平台中，支持公有云、专有云和混合云的协同研发，且可以整合我行内部研发资产，助力我行产品快速创新迭代和研发效能升级。
5、MPaaS平台：我行采用移动开发平台mPaaS来作为手机APP开发、测试、运营及运维提供云到端的一站式解决方案，它能有效降低技术门槛、减少研发成本、提升开发效率，协助我行快速搭建稳定高质量的手机银行等移动应用。