银行云计算架构的演进及抉择探讨.docx

《银行云计算架构的演进及抉择探讨.docx》由会员分享，可在线阅读，更多相关《银行云计算架构的演进及抉择探讨.docx（10页珍藏版）》请在优知文库上搜索。

1、以金融科技破解发展难题和助力商业银行数字化转型，已成为全球银行业共识。本文从IT架构的视角，结合某行在不同数字化改造阶段，云计算架构演进的过程和思路进行梳理和总结，旨在厘清在云计算不断的技术变革下，银行的策略和架构抉择思路：从物理机”公”架构、桀成云架构、到集成+原生“混合”云架构，希望对同行有借鉴和参考价值。一、前言金融的本质是以简单、有效的方式连接资金盈余者和资金短缺齐，服务于实体经济。金融的数字化转型方向是对金融本质的回归，通过新型科技手段，提高金融服务的效率，降低金融服务的成本，落实普惠金融，支持我国经济的转型。金融的数字化转型是利用移动瓦联网、物联网、区块跳、大数据、人工智能、云计算

2、、安全等金融科技技术，对金融的数字化改造，打造“三个能力，实现个目标“三个能力”是数字生态能力，链接人、物,企业，实现消费互联网、产业互联网与金融的深度结合：打造金融智能能力，以数据为生产资料，驱动业务决策，提高效率，服务长尾客户；打造业务敏捷能力，实现业务低成本试错、持续迭代和优化。“个目标”是数字金融的目标，为客户打造极致的数字化体52,以高效的方式满足不同客户的金融服务需求，推动客户与业务的增长，实现金融的普惠。面对这二新的能力和目标，金融同业加速数字化进程，从产品创新、客户旅程、组织体系、IT架构等方面进行数字化改造,实现从简单的产品服务线上化向全面的经营管理数字化跃升0以金融科技破解

3、发展难题和助力商业银行数字化转型，已成为全球银行业共识。在这样的背景卜.，木文将从1T架构的视角，以我行在不同数字化改造阶段，云计算架构演进的过程和思路为例进行梳理和总结，旨在厘清在云计算不断的技术变革下，我行的跟进策略和架构抉择思路，包括物理机“公”架构、集成云架构、集成+原生“混合”云架构，希望对同行有一定的借鉴和参考价值。二、物理机“云”架构阶段除开近年来新兴的民营银行和村镇银行，在门,架构的演变过程中，物理机架构阶段几乎是国内每家银行都必经的阶段。在这个阶段，我行当时的业务种类和信息系统没有现在这么繁多，包括核心、交易、管理和开发测试类的业务系统运行环境总共仅有30余个POWer小型机

4、分区和不到50台X86服务器，承载着我行核心、柜面、网根、手机银行、中间业务、银行卡、大小额支付、财管等主要业务系统的生产和开发测试的运行环境后来随着我行业务的迅速发展，采购了大量的Power小里机和X86服务器，这些设备基本都随业务系统建设项目购买，烟囱式的供给，高配低用、专机专用、资源孤岛的情况普遍存在，而一些迫切需要资源扩容的系统却没办法第时间得到满足,但总体计算下来，整体的CPU、内存等资源使用率又非常低，90%的时间在沉睡.因此，我行的迫切想法之一是通过某些技术手段来实现资源整合和共享，大幅提高资源利用率。另外，一方面随着我行物理设备采购量的增加，数据中心机房的空间、能耗、制冷问题越

5、来越突出，严重制约了业务的发展速度.另方面，单机的性能也逐渐无法支掠业务应用的需求，各种系统、数据.库性能调优，系统剥离、迁移工作相继开展，科技人员疲于奔波于日间运维和夜间优化，自建新机房、租用电信IDC机房过渡成为了当时面对机房空间问题的唯一选择，设备机房搬迁也开展多次。因此，我行的迫切想法之二是通过高资源容量的设备来集成或整合这些物理机，减轻机房能耗和空间压力.最后，业务发展带来了大故新业务系统建设和上线的需求，然而按照之前设备随项目采购的方式，所需资源供给周期过长，进而造成上线周期非常漫长。除此之外，新系统投产前的基础运行环境准备也是非常耗时耗力，全部由人工安装、搭建、配置，参数配理不规

6、范，也造成r日后系统的各类风险隐患，运维压力巨大。因此，我行的迫切想法之三是通过预建资源池和自动化部署的方式满足业务系统快速开发测试和上线对资源的需求，提升应用的敏捷性。三、集成云架构阶段在以上迫切需求和想法的刺激下，我行开始按照设备类型的不同，逐步探索相应的解决方案，并通过采取小规模试点新应用、总结试点成果并制定规范，大规模标准化部署应用三步走战略落地解决方案,例如针对Power小型机资源我行在不同网络安全分区建设了多个PowerVM资源池,每个资源池由若干台高配小型机组成：针对X86计算资源我行分步分别建设了VMWAREX86资源池和KVMX86资源池，提升了应用节点分布式的部署能力：针对

7、存储资源我行建设了存储虚拟化资源池，纳管整合了多套异构存储，引入了存储性能分层，增强了数据跨存储迁移的灵活性。通过以上这些虚拟化和整合的技术方式，的确解决了我行在物理机架构阶段的大部分问题，落地或者迁移到虚拟化资源池中的业务系统也充分感受到了资源供给的便利性和一定的弹性，整体资源利用率得以提升，机房空间压力也大幅减轻。然而随着资源池规模的不断扩大，应用敏捷性要求的进一步深化，大规模应用集群化部署要求的提升，资源服务化和统一管理理念的加强，都意味着散沙式的虚拟化资源池只能是架构转型过程中的临时中转站。在这个阶段，我行的迫切想法则变成了同构虚拟资源池云化、异构多云管控统一化，多云软硬件编排自动化。

8、通过采用不同技术方案的软件，将基础资源架构（计算、存储、网络、中间件）集成到一起，在上面再做一些定制化的二次开发，最终形成所谓的集成云架构。集成云架构深层次可以理解为：企业枳极地混合多个云平台以提供一个协调的服务集合，并利用每个云计算服务/云平台的不同优势。集成云架构建立在两个基本原则之上。首先，每个集成的云平台都提供r强大而丰富的功能,可以为一个或多个业务功能提供服务，它们可以独立行动，而无需与其他云平台集成;然而，当适当地集成时，其总和大于非集成个体的能力。这些功能对于每个云平台都是独无二的，并且在多个云平台（如单点登录支持、标准Web服务支持）之间是通用的.其次，通过集成云架构能够体验多

9、种不同平台的资源，这些资源间并不相互排斥，可以引入专门的“聚合”接口以在一个或多个平台上实现优化和统一的体验。在这些理念和想法的驱动下，我行分步开展了以下工作：一是同构虚拟化资源池云化，形成不同设符类型的基础设施云（IaaS）,以服务的方式提供计算、存储网络等资源。例如通过PowcrVC软件管控所有的PowcrVM虚拟化资源池和存储虚拟化资源池，通过Vcentcr软件管控所有的VmWareX86虚拟化资源池，通过CIoudManager软件管控所有的KvMX86虚拟化资源池等等.二是异构多云管控统一化，采用成熟的云管平台集成多食异构基础设施云，进行多云资源、服务、和运维管理。一方面是资源层的统

10、一，通过统一的资源适配接口屏蔽件异构资源的差异，同时支掾上层的服务编排与部署，实现对所有异构的资源的统一管理：另一方面是服务U的统一，通过将底U资源技术实现、部署策略和动态调配实现抽象化和服务化，实现自服务和服务目录的能力，同时集成行内各类运维、管理和流程的工具（如4A、ITSM、监控、CMDB等）。三是多云软硬件编排自动化，云管平台需要搭配个界面友好、能力灵活、编排可视、广泛兼容的多云编排引擎来实现各类服务的可编排、可设计和自动化落地。例如我行采用的编排引擎为商用的Q。UdAUIomaIionManag5但其底层臼动化核心为开源的AnSib0商用和开源的结合让服务编排兼具成熟性和灵活性。四、

11、集成+原生“混合”云架构阶段集成云架构帮助我行实现/最初所有的想法和愿景，同时随着云计兑技术的不断成熟和相关解决方案在我行落地生根，初步实现了软件平台即服务（PaaS）的PoWCr和X86和谐共存的私有云，在软硬件资源层方面，的确产生了较大的成效，总体归结起来有五点：是异构共存，所有资源都将在这套云体系内共存：二是强化管理，提升了架构管控的力度，实现了软硬件编排模板的统一和规范化落地；三是提效率，硬件编排结合软件编排，进一步提升资源的自动化部署效率：四是降低成本，一方面是提升了总体资源使用率，另一方面是降低了人工运维成本：五是统门户,资源统一管理和运维，以业务为中心，通过服务的形式为业务提供支

12、掠.然而技术也是在随业务不断变革和完善的，业务需求日渐丰富、迭代速度不断加快，金融机构数字化转型需要有更为成熟的IT架构、敏捷交付流程和技术风险保障机制做支探，最大限度地缩短新业务产品的研发与投产时间，快速响应细分客户需求，还要保证在更新和维护应用及软硬件系统时不对用户体验产生负面影响，即使在极端严苛的业务压力下也须始终保持顺畅的产品服务体脸，保证业务连续性和数据安全.在这样的背景卜.，云计并不再只是解决业务对资源的快速响应和弹性扩展需求，更多的面向业务的先进技术进步下沉到云计算基础设施中，包括面向分布式设计：容器、微服务、AP1.驱动的开发;面向配置设计:一个镜像，多个环境限置：面向韧性设计

13、：故障容忍和臼愈；面向弹性设计：弹性扩展和对环境变化负载）做出响应：面向交付设计：自动拉起，缩短交付时间；面向性能设计：响应式，并发和资源高效利用：面向自动化设计：自动化的DeVoPs：面向诊断性设计：集群级别的日志Me1.riC和追踪：面向安全性设计：安全端点、APIGa1.CWay、端到端加密等等。这便是所谓的云原生架构（Ck）Ud.Native），它是是加快业务产品发布速度、增强服务梗定性、提高计算资源利用率、降低运维成本的关键架构之道。云原生这个概念名词最初于2013年在技术社区中诞生，代表若一套先进架构理念的思想集合，包括微服务、敏捷,DCVOPS、持续集成部署、容器、可靠、高弹性、

14、易扩展等领先的概念和特性。云原生代表着原生为云设计。详细的解糅是：应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。在云原生之前（例如集成云），底层平台负货向上提供基本运行资源,而应用不仅需要满足业务需求还需要满足大量非业务需求，为了更好的代码复用，通用性好的非业务需求的实现往往会以类阵和开发框架的方式提供。或者在SOA和微服务时代部分功能会以后端服务的方式存在，这样在应用中就被简化为对其客户端的调用代码.在发布应用时也会将这些昨业务功能代码，连同自身的业务实现代科一起打包发布。例如典型的微服务体系下的服务治理，通常是由中间件产品提供一个SDK给业务应用使用，在SDK中会集成各种服务治理

15、的能力，如：服务发现、负载均衡、熔断限流、服务路由等。在运行时，SDK和业务应用的代码其实是混合在一个进程中运行的，耦合度非常高，这就带来J一系列的问题：一是升级成本而。每次升级都需要业务应用修改SDK版本号，田：新发布。在业务飞速往前跑的时候，是不太愿意停卜来做这些和自身业务目标不太相关的事情的。二是版本碎片化严重。由于升级成本高，但中间件还是会向前发展，久而久之，就会导致线上SDK版本各不统一、能力参差不齐，造成很难统一治理。W是中间件技术演进困难。由于版本碎片化严至，导致中间件向前演进过程中就需要在代码中兼容各种各样的老版木逻辑，戴着枷锁前行，无法实现快速迭代。而后有了服务网格之后，就可

16、以把SDK中的大部分能力从应用中剥离出来，拆解为独立进程，以旁挂的模式部署.通过将服务治理能力下沉到云计算基珈设施，可以让业务更加专注于业务逻辑，中间件团队则更加专注于各种通用能力，其正实现独立演进，透明升级，提升整体效率。这样来非业务需求相关的功能都被移到云中，或者说基础设施的中间件中去，开发人员专注力完全置身丁业务逻辑，开发出的应用也是原生地.最适合地部署于朦生云架构中。除了微服务之外，原生云架构的其它几个关键“组件”,包括DcvOps:云原生.应用开发需要工程师面向更“云”化的DevOps流程来工作.开发和运营服务不再是种前后顺序的关系，而是种相互交织的合作关系，这种结合能带来更快更顺畅的开发进程.持续交付：持续交付使得单个更改在就绪后即可发布，而不必等待与其他服务一起打包发布或等待维护窗口期等。持续交付让发布行为变得常态且可赤，团队以更低的风险高频交付，并更快获得最终用户反馈。最终.持续交付会成为业务流程和企业竞争力必不可少的部分。容器：