《银行云计算架构的演进及抉择探讨.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流程来工作.开发和运营服务不再是种前后顺序的关系，而是种相互交织的合作关系，这种结合能带来更快更顺畅
17、的开发进程.持续交付：持续交付使得单个更改在就绪后即可发布，而不必等待与其他服务一起打包发布或等待维护窗口期等。持续交付让发布行为变得常态且可赤，团队以更低的风险高频交付，并更快获得最终用户反馈。最终.持续交付会成为业务流程和企业竞争力必不可少的部分。容器：像KUberneIeS这样的容器管理工具，帮助开发者自由的选择应用的部署方案，而不用关心那些关系到具体平台的具体实施，基于以上云原生的理念和我行对云计算技术变革的思考，我行以现有集成云架构为基础，稳态运行现阶段业务系统，同时开始以积极的姿态投入至全新的原生云架构体系建设，形成集成+原生“混合”云架构.目前，我行已开始全面实建原生云战略转型，
18、包括网络化转型、平台化转型、智能化转型与生态化转型四个阶段，前两步利用移动互联网、大数据、云计算实现网络化和平台化转型，推动自身敏槌化转型，后两步是利用人工智能、物联网、区块链、新SaaS.实现智能化、生态化创新.金融云平台是我行以本地部署的原生云架构为基础，推动下屈法人金融机构的数字化建设，其作为分布式架构云技术平台,主要包含以下五大子平台,即IaaS、PaaS、DaaS、DeVOPS和MpaaS,整体架构图如下所示:I、IaaS平台：作为云计算底座，它是实现云计算、形成通用功能的巨型计算机的核心部分。它屏蔽J底U基珈设施的差异，使用虚拟化、分布式计算等技术将资源打散、分割成最小逻辑单元，进
19、而形成网络、计兑和存储资源池，提供可度量的、用户隔离的、安全的、快速可扩展的持续资源池供绐。主要包含的组件包括：虚拟服务器ECS、虚拟网络（VPC）、虚拟存储（OSS）X负载均衡（S1.B）。2.PaaS平台：我行基了IaaS平台底座资源，引入了整套成熟的金融级分布式中间件，包括微服务、分布式数据降、分布式消息、分布式事务、服务网格等组件，利用这些组件帮助我行轻松构建大型分布式应用服务，同时提供应用管理、发布部署、运维编排、监控分析、容灾应急等全生命周期管理的PaaS平台能力，满足我行金融场景中经典和云原生架构的运维需求.3、DaaS平台：我行通过采用大数据集成服务平台软件，来实现对TB/PB
20、级数据的非实时分布式分析处理能力，提供海量数据的上传卜载，SQ1.运算，MR计算和Graph图计算等离线计算，以及数据安全管理等功能。4.DeVOP$平台：我行采用新型企业级一站式协同研发平台，它通过先进的管理理念和工程实践，提供从“需求-编码。测试。发布-运维-运营”端到端的协同服务和研发工具支撑，将敏捷研发、持续集成、持续交忖、DCVOPS等理念融入平台中，支持公有云、专仃云和混合云的协同研发，I1.可以整合我行内部研发资产，助力我行产品快速创新迭代和研发效能升级“5、MPaaS平台：我行采用移动开发平台mPaaS来作为手机APP开发、测成、运营及运维提供云到端的一站式解决方案，它能有效降
21、低技术门槛、减少研发成本、提升开发效率，协助我行快速搭建稳定高侦员的手机银行等移动应用.云原生架构的演变过程人类的需求始终是技术快速发展的内置动力，云原生的快速发展也在于此。从去中心化、微服务到SerVerIeSS,服务在变、架构在变，新技术应用所带来的问题也在不断变化。云原生生态体系中的任何项技术、任何家J.商、任何个终端用户，都在解决、适应乃至拥抱这种变化,用技术解决技术所带来的问题，由此出现了云原生“可观测性1.但在云原生庞大的生态体系中，K8s也好、可观测性也好，都属于沐山一角，背后有更多更杂的技术作为支撑。当我们在“享受”云原生所带来的变化的同时，也理应追溯云原生技术的演进脉络，思考
22、云原生的技术价值与发展未来.（K8S技术分水岭）从上这张图说起吧要想完全掌握如图K8S的技术拓扑，亮不客气的讲：实在太难了！然而，K8S也只是云原生体系中的一环。譬如诺豆公司化名使用K8S已经2年了，而最近遇到的Nodc节点NotReady的问题，还不能完全凭借自有运维团队的能力解决，最终还是依靠公有云技术支持才得以定位到问题，在解决问题的过程中有如下插曲：根据日志报错，完全搜索不到相关技术贴怀疑公有云厂商修改了K8S的调度脚本J:大量非关键日志掩盖,ar1.ogmeSSage中K8Sp1.eg核心报错，经验不足,忽略关键日志，错失关键切入点：某公有云厂商的首次诊断结果是：rune通道阻寒，需
23、更换自研OS方可解决；方案被严厉拒绝后，派遣高工介入，修改结论为：docker1935版本rune有BUG,升级至19.3.15可解决。核因并未找到，怀疑max_Pid和U1.imi1.不足、机器负载高、及COmainer领繁CXeChCaIIhChCCk导致runchang,但无实据，而服务器状态很健康。继而引发的思考：问题：如何在公有云上获得更自主可控的运维管理能力：问题二：版本升级成本高昂，如何平滑升级：问题三：（上述问邀出现在测试环境J,生产环境出问题的S1.A如何保障。问题一和三很容易解决，多云或者混合云方案，加强对供应商管理与对接。问题二很难，纵观整个行业，少有公司掌握自我升级能力
24、，基本都要依赖公有云方案或者第:方协助.核心原因依旧在于K8S和云原生的技术门槛太嬴“但云原生和K8S大火是客观存在的事实，今天我们来聊聊云原生时代下技术演进。一、架构演变70-80s90s2000200620142018（大型机到微服务架构演变）自20世纪70年代开始，无论是软件架构还是服务托管，都在逐步从中心化向去中心化转变，从宏服务向微服务转换，从大型机到微型机转换。在中国去IoE指导方针卜该现象尤为突出。1.1 中心化-去中心化70年代，早期的IT基础设施不成熟，以大型机为主，中心化运算、存储、调度，客户端终端只具备最基础的输出和展示功能。该思想一直沿用至今，软件工程上诸如:Satst
25、ack%PUPPCt-OPenStaCk等。去中心化的代表：Ansib1.e.Git,P2p协议、区块族技术、共识机制。前两者具备去中心化思想，后两者属丁完全去中心化,两者没有绝对的好与坏.，现代工程软件多为两者结合。1.2IaaS-PaaS-SaaS-Scrvcr1.css互联网早期以机房托管为主，BiJIaaS.陵若公有云发力与成熟，逐步向云托管转向，有如下优势：各职能各司其职，关注各自领域即可：资源按需付费，相对自建，中小规模卜.有较大成本优势：即性架构设计：服务开箱即用等。近年云原生概念逐步普及并落地，强调软件应用应该生于云上，长于云上。云原生本质并非一门确切的技术或者定义，而是整套完
26、整的生态体系，或者理解为愿景。云原生给予的标准化架构及解决方案、高度运维自动化、自愈及配套基础设施等运维能力，倒逼运维向更高层领域转向。据公有云财报，目前，IaaS仍在市场上占据最大份额，云原生协助厂商打造不可变基础设施，本质上讲云原生是系统化能力，因此，未来PaaS、SaaS一定会后来居上。1.3AninOne微服务PMP提山的软件开发模式主要仃BUiId-andFixMode1.模型：瀑布模型：迭代模型：增假模型：喷泉模型：演化模型：敏捷开发模型：混合模型无论哪种模式均不是万能解药，最终目标都是准确快速交付。交付结果通常依赖：软件开发模型：项目周期长短：技术人员水平但以上都无法解决“1个孕
27、妇IO个月生胎，IO个孕妇1个月生胎的问题。微服务解决了如上问题，且提供各接口遵循gRPC或ReS1.fU1.接口。但在服务切割、解耦、依赖关联上无法细化，经验主义。过相的拆分效果不佳；过细的拆分，导致微服务爆增，资源浪费严重，接口和服务维护成本高昂：需求变更导致过去拆分策略不佳：无论以上哪种情况，最终都要面临微服务暴增导致的“死星”式调用链.该情况并非只发生在巨头身上的极端情况。（死星调用徒路）最终，还是要回归到去中心化思想，回归到云原生。我们一再强调，云原生提供的解决方案,是系统不可变基础设施“服务网格（Scrviccmcsh）,边车（SidCear）、服务编排和容器之类的新兴架构模式可以
28、有效地阻止基于云的世界中出现的各类错误实践。二、云原生的架构随着云平台的面世，尤其是出现J像KUberne1.eS这样的容器编排技术后，服务网格就开始引起人们的关注。服务网格是应用程序服务之间的桥梁，它带来了许多附加功能,如流量控制：服务发现：负载平衡;弹性：可观察性:安全性等,它使应用程序可以从应用程序缎库中卸载这些功能，并允许开发人员专注于业务逻辑.（云原生技术应用演进）诸如IS1.io之类的某些服务网格技术还支持混沌注入之类的功能，以便开发人员可以测试他们的应用程序，以及多达数卜种相互依赖的微服务的弹性和健壮性。应用和云通过SideCar旁路容器作为桥梁交互，每个容器通过代理应用将本身所
29、需要的进出，所以云就可以非常容易地通过这样一个代理，调节流量、做流量切分，这也是ScrviccMcsh的基本原理。服务网格非常适合放在平台即服务（PaaS）和容器即服务（CaaS）之上，并通过这些通用平台服务提升推行云计算过程的体脍。2.1 无服务器架构在坡近的云原生演进中，另一个备受关注的趋势是无服务器架构，也称为无服务落计算，基于公有云厂商筑力，运行COding。无服务器比PaaS模里更进一步，因为它将服务器基础架构从应用程序开发人员那里完全抽象出来。开发只需关注代码即可。在无服务器中，我们将业务服务编写为函数，并将这些函数部署到云基础架构中。无服务器技术的一些例子包括Amazon1.am
30、bdaSPringC1.OUdFUnCtion、GOOg1.eC1.OUdFUneIiOnS和MiCrOSOnAZUreFUnCIiOnS等。无服务器模型位于云托管范围内的PaaS和SaaS之间，如下图所示：Ooud4ContainersAServedessOrigina1.OoudComputingMode1.OoudNteArchitecture（各类服务架构）对比单体服务与微服务，并非所有解决方案都应作为函数来实现.我们也不应使用无服务器函数替换所有微服务，就像我们不应替换所有单体应用，或将其分解为微服务一样。只有诸如用户身份验证或客户通知之类的细粒度业务和技术功能，才应该设计为无服务涔
31、函数。小结：合适的才是最重要的，无所谓先进。根据我们应用程序的功能性和非功能性需求（例如性能和可伸缩性以及事务边界等），我们应该为每个特定用例选择适当的单体、微服务或无服务器模型.常见的情况是，我们可能需要在一个解决方案架构中使用所有这三种模式。如果设计不当，无服务器解决方案最终将变成纳米片，其中每个函数都与其他函数或微服务索密结合，并且无法独立运行。2.2 服务编排当我们在说容器编排的时候，我们在说什么？在传统的单体式架构的应用中，开发、测试、交付、部署堆个组件不存在编排概念。而云原生时代，生要为了解决微服务和容器通信和HPA.VPA场景，运维将面临新挑战：我们需耍将单体式的架构拆分成越来越
32、多细小的服务，运行在各自的容器中，那么该如何解决它们之间的依赖管理、服务发现、资源管理、高可用等问题?在容器环境中，编排通常涉及到三个方面：资源编排负我编排服务编排Kubernetes常见控制器编排方式：Dep1.oymentStatcfuISetDacmonSctCronJobJob（K8S编排调用链）2.3 暇务网格与传统的微服务架构相比，基于服务网格的解决方案在连接性、可靠性、安全性和可观测性方面提供了诸多好处。连接性：流量控制（路由、分流）网关（入口、出口）服务发现A.，B测试、金丝雀服务超时、重试可靠性：断路器故障注入/混沌测忒安全性：服务间身份验证(mT1.S)证书管理用户身份独证(JSONWcbTokens)用户授权(基于角色的访问控制)数据加密可观测性：监控遥测、仪表盘、指标分布式跟踪服务图服务网格技术常见实现：Istio1.inkerdConsii1.Conncci(面对K8S的托管服务网格)三、总结日扁最术日新月异，技术不是终点，只是工具的种,协助达成目标的过渡过程：云原生不是工具,而是体系架构和生态，是一套系统解决方案，更是标准基础设施：架构是演变出来的，不是设计规划出来的。
