1. 项目概要

1.1 项目背景

随着云计算技术的快速发展和日趋成熟，特别是数字化转型的持续推进，企业的云化速度大幅提升，同时在企业业务分布式改造和业务场景化的推动下，业务逐渐扁平化、模块化、上云化及容器化，业务发布效率显著优化、运维管理效能大幅提升。

就金融行业而言，随着云计算技术在行业内加速应用实践，云平台也已成为推动金融业务发展和赋能数字金融底座的重要技术支撑。中国人民银行等部门陆续印发《金融科技发展规划（2022-2025年）》等指导意见，进一步加快云计算技术规范应用，推进信息系统分布式架构转型，提供资源高效管理、弹性供给、云网联动及多地多活部署能力，实现双态并存、集分融合目标，为数字化转型提供精准及高效的底座支撑。行业云平台应运而生，通过共享和整合资源为行业提供定制化的云计算解决方案， 以满足行业特定的需求和应用场景，从而为企业带来更高效、便捷和持续的服务。

基于以上背景，某省农商银行紧跟云计算发展趋势，理清云计算技术迭代脉搏，以云化思路实现系统快速扩容升级，以满足金融业务快速发展的需要，从而在日益白热化的市场竞争中寻求自身的生存和发展。因此行内对云平台较为重视，开展了多部门、多轮次、多厂商的沟通与交流，也进一步加快云平台的建设工作，本文以行内行业云平台建设为例进行简要说明。

1.2 建设原则与目标

行业云平台项目建设原则如下：

1、高可靠性：整个云平台的业务连续性需要大于3个9（可靠性>99.9%）。

2、平台兼容性：整个云平台对所需的服务器、网络及安全设备具备较好的兼容性；支持国产信创设备（如海光X86、ARM等），云平台满足信创验收的各类标准；支持行内所用的各类操作系统版本。

3、平台安全性：针对多租户的实现方式，满足相关云安全要求，不同租户间逻辑隔离，提供租户化的云安全服务能力。

4、平台定制化能力：平台具备对行内需求进行相应定制化开发的能力，具备与行内各类运维系统（如监控、CMDB、日志平台等）对接能力。

5、平台双活或灾备需求：平台支持双活或灾备能力，以消除平台单中心单点故障。

2. 架构设计

2.1 需求分析

行内行业云平台建设立足金融领域，在满足行内自身云资源需求的同时，也考虑逐步开展外拓云资源服务，以实现云资源充分利用和获取一定的经济收益。因此针对以上背景和目标进行详细分析，项目的需求分析如下：1、提供弹性的、高效的计算资源池，块、对象及文件等多样存储业务，缩短机器的交付周期；2、提高稳定的、高可用的服务，支持线上和线下业务；3、在网络连接上实现现有业务无缝衔接，在使用体验上与物理机无明显差异；4、虚机生命周期有效管理，虚机资产有效管理，改变现有虚拟化环境无序管理，实现虚机全生命周期管理及虚机的自动下发，减轻运维负担；5、以云化思路打造“虚物”一体、一云多芯，提供裸金属资源对外服务，丰富资源多样性。通过建设弹性伸缩、灵活扩展和敏捷交付的多活云平台底座，大幅提升资源利用率和业务连续性保障能力。

2.2 物理架构设计

行业云平台在规划之初就定位立足于金融行业，就金融行业数据的重要性而言，对平台的可靠性、稳定性和有效性方面都具备较高的要求。同时就单个数据中心云平台部署架构而言，在数据中心站点方面存在着单点故障，因此基于行内数据中心架构及业务的连续性等方面综合考虑，与云平台厂商进行多次讨论，同时与业界其它金融单位进行交流及探讨。行业云平台的整体架构如图1所示，按照行内两地三中心数据中心思路进行3DC规划部署。同城两中心通过LB实现流量切换，共同构建“两地三中心”的云平台IT基础平台架构。

图1 云平台规划架构图

2.3 逻辑架构设计

行业云平台逻辑架构如图2所示，通过云化和虚拟化技术将底层技术设施的计算节点、存储节点、网络节点及安全节点等抽象化、虚拟化及池化。通过云平台工具实现云平台系统层的镜像管理、容量管理、计量管理、流程管理、报表管理、资源池管理、资源调度、配额管理、资源编排、租户管理及弹性扩展等功能，并将此功能转化成标准化、统一化及流程化的云主机、云存储、云网络、云安全、裸金属、数据库、云备份等服务。同时其上提供运营门户，实现用户管理、服务目录管理、资源商城管理、计费管理、报表管理等可视化、租户化、定制化管理。

图 2 云平台逻辑架构图

2.4 网络方案设计

行业云平台网络方案设计以SDN、Overlay、NFV等技术为支撑，具备产品形态软件化、功能虚拟化、控制集中化等技术特征，充分满足海量租户、网络灵活自定义、虚机迁移自跟随、网络安全、网络自动化等多种网络需求，保障行业云平台网络运行的冗余、稳定及有效。基于此云平台的整体网络架构如图3所示。

图3 云平台网络架构图

行业云平台通过网络Overlay技术构建一个或多个相互隔离的网络空间，如图4所示，为云服务器、负载均衡及云数据库等云服务资源提供网络环境，实现数据间互联互通，并通过相应的控制策略对网络内的流量进行管理和控制。

图4 云平台Overlay整体架构图

2.4.1 网络灵活自定义

传统的网络资源呈现僵化的固态形状，无法随着网络规模调整、租户业务变更等进行灵活、动态调整。通过SDN技术以控制和转发分离为基础，实现对整网的灵活化、集中化、细粒度地控制调度，SDN控制面架构如图5所示。通过NFV技术，云平台整体网络解决方案将网络功能资源进行虚拟化，使得网络资源升级为虚拟化、可流动的流态资源，Overlay模型使流态网络资源的流动范围跳出了物理网络的束缚，可以在全网范围内按需流动，呈现出网络资源的统一池化状态，最终实现了网络资源的灵活定义、按需分配、随需调整。

图5 云平台SDN控制面架构图

2.4.2 网络安全服务链

传统网络的服务链和网络拓扑有紧密的耦合，部署较为复杂，无法满足云环境里的安全访问控制需求。通过将各种软硬件的安全设备组合抽象成统一的服务链资源池，可满足数据中心内各种安全业务的应用模型。通过云平台内VCF控制器将Overlay网络、NFV设备和vSwitch统一控制和逻辑抽象，并根据业务需要灵活地对NFV设备、硬件资源进行细粒度、自定义的编排，使得业务流量按照控制器的编排顺序经过一组抽象业务功能节点，为行内行业云环境提供可靠、可调、差异化的网络安全保证。

2.4.3 网络运维自动化

传统网络的运维工作量随着网络规模的增大不断增长，通过网络运维自动化、Fabric自动化、接入自动化等方式实现网络运维自动化，来应对云平台网络规模的逐步增长，进一步降低网络运维和管理的复杂度。

2.5 云平台设计

行业云平台采用全栈安全可控技术，构建具备农商特色生态的云原生技术栈，并对业务应用提供有效承载和支撑，建设具备一定技术领先的新型全栈平台，在基础设施、云平台、安全、操作系统及芯片等全面实现自主可控。充分运用AI、云计算、大数据等先进理念和技术，按照“高效集约、开放共享、安全可靠、自主可控”的原则，以“云网一体、一云多芯”为构架，建成行业云平台，实现行内基础设施共享共用、数据资源统一汇聚、业务应用有效协同，为行内业务的发展提供有效的资源和数据支持。
云平台整体架构大致可分为物理层、资源抽象控制层、云服务层、云安全防护层、云运维层及云服务管理层这六大部分。六大部分各自实现模块耦合、功能互补，具体的平台整体架构如图6所示。

2.5.1 物理层

物理层是云平台运行所需的云数据中心机房基础设施运行环境，含计算、存储、网络、安全等物理设备。

2.5.2 资源抽象控制层

资源抽象控制层是指计算资源虚拟化、存储虚拟化、网络SDN控制器。通过虚拟化技术将底层硬件资源进行抽象，对底层硬件故障进行屏蔽，统一调度计算、存储、网络、安全资源池。其核心是虚拟化内核，将主机CPU、内存及IO等资源进行虚拟化，通过共享文件系统保证云主机的迁移、HA集群和动态资源调度。同时通过分布式交换机实现多租户的虚拟化层的网络隔离。在存储资源池的构建上，采用分布式存储技术实现服务器硬盘的虚拟化整合，并通过多副本技术保证存储数据的高可靠。

图6 云平台整体架构图

2.5.2.1 计算虚拟化能力需求

1、具备虚机的配置修改、伸缩容功能。支持虚机CPU、内存硬件添加和移除，支持虚机磁盘在线扩容。

2、具备虚机不停机在线迁移功能。支持虚机在线迁移至另外宿主机，迁移过程不丢包，文件系统可持续进行读写操作。

3、具备虚机快照功能，支持快照回滚。

4、具备宿主机负载均衡功能。

5、具备虚机高可用功能，能监控并感知到异常情况，虚机宕机后自动重启。

6、具备虚机监控功能，支持实时展示虚机的运行状态和资源使用情况。

7、具备批量纳管X86服务器（含Intel和海光架构）及ARM服务器加入虚拟化资源池。

8、具备支持Web图形界面的集中管理功能。

2.5.2.2 存储虚拟化能力需求

1、支持以LUN的方式提供存储服务。

2、具备存储容量与性能的弹性扩展接口，保证伸缩容过程中存储服务不中断，挂载方的连续使用不受影响，且不造成性能较低。

3、具备存储的高可用功能，节点故障后应通过多副本保证数据一致性。

4、具备支持Web图形界面的集中管理功能。

2.5.2.3 网络虚拟化能力需求

1、具备统一管理物理网络设备和逻辑网络设备集中化的配置操作和监控。

2、具备从链路层至应用层（2-7层）各个层面，实时展现网络用户分组之间的互访关系、流量组成和通信质量。

3、具备实时展现各网络用户分组使用的IP和MAC、vswitch和物理交换机上的分布情况。

4、具备站点级的网络灾备自动切换能力。

2.5.3 云服务层

云服务层包括云管理平台及云应用引擎等各类IaaS、PaaS及SaaS服务。其中IaaS服务提供云主机、云数据库、云防火墙、云负载均衡及云网络等各类云服务。IaaS层服务向PaaS层、SaaS层提供开放API接口调用和资源支持。用户可通过自助服务门户进行相应的服务申请，通过相应流程实现云资源的自动交付并提供用户使用。

2.5.3.1 云管理平台能力需求

1、具备用户生命周期管理手段，实现云管理平台的用户创建、权限分配和调整、销毁等。

2、支持多租户，按不同的租户体系提供资源展现、配额控制、流程审批、订单管理。

3、具备资源生命周期管理手段，实现计算、存储、网络资源的创建、伸缩、启动和停止、销毁等。

4、提供IT资源服务标准化定义。提供基于不同SLA服务水平下的计算、存储、网络、中间件、数据库、容器等服务模版。

5、具备根据不同的服务编排策略（如性能优先、成本优先、容量使用率优先等）完成各种IT服务的自动化部署。

6、具备精细化的使用信息、配置信息管理功能，实现云平台的资源可计量、服务可计价。

7、具备REST API接口能力，满足DEVOPS环境下应用系统的对接需求，快速提供应用开发部署。

8、具备云管理平台所有操作均可追溯能力，能够集成管理资源池日志。

9、为管理员、运维人员和自服务用户提供统一的门户入口，支持根据不同的用户和权限设置为各用户提供对应的访问门户。

10、监控各类服务的运行状况，异常情况可报警。实现巡检自动化。

11、云管理平台服务目录可灵活定制，实现对MPP数据库等新增组件的纳管及其服务的生命周期管理。

12、具备OpenAPI管理。

2.5.4 云安全防护层

云安全防护主要为物理层、资源抽象与控制层、云服务层提供全方位的安全防护，包括数据中心虚机间访问流量控制、出口流量访问控制、DDoS防御、漏洞扫描、主机防御、租户隔离、认证审计及数据安全等服务。

2.5.5 云运维层

云运维层主要为云平台运维管理员提供设备管理、配置管理、镜像管理、备份管理、日志管理、监控与报表等功能，满足云平台日常运营需求。

2.5.6 云服务管理

云服务管理层主要面向云管理员，对云平台的各类云服务进行配置与管理，含服务目录发布、组织架构定义、租户管理、云业务流程定制设计、资源配额与计费策略定义等功能。

2.6 PaaS层设计

金融行业由于监管较为严格，对基础平台的稳定性、高可用性及业务连续性等方面有着较高的要求。就PaaS层的设计而言，其逻辑结构如图7所示。

图7 PaaS层逻辑结构图

在建设的过程中主要考虑如下几点：

1、多租户管理：不同租户可以发布和使用不同的应用容器，在权限方面管理员可以管理集群和主机资源，成员用户可以进行应用部署和管理；

2、容器调度策略：需具备能自动按照主机资源用量进行容器调度、可指定具体主机、可通过标签策略进行调度、可调整单次下发的容器任务数量、支持亲和性与反亲和性策略等；

3、镜像仓库：需具备服务和存储高可用性、多版本管理、误删可恢复、按角色进行权限管控、增删改查等日常管理功能、可进行漏洞扫描；

4、应用及服务管理：应用模板可编排、服务健康检查、容器视图服务、提供负载均衡、会话保持、SSL支持等、地址动态更新服务不间断等；

5、应用发布：不同版本显示，应用滚动升级、回退、支持流量控制，支持多种应用发布方式；

6、系统高可用：支持控制节点、主机节点高可用，支持平台升级在线升级；

7、多中心部署：支持多中心部署、多中心容灾、应用可迁移等功能。

2.7 高可用设计

就行业云单中心架构而言，具备如下高可用性：

1、服务器高可用：系统盘冗余、带外管理单独组网、所有组件集群部署、跨机架部署，确保单台服务器故障不影响平台正常运行；

2、网络可高用：服务器双网卡bond、网路三层架构、TOR堆叠、三层多路径，确保单台交换机、光纤或网线故障不影响服务器网络访问；

3、云平台高可用：控制平面实现负载分担，管理平面主备部署，数据平面三副本实时数据复制，实现云平台管理平面高可用。

在确保单中心高可用的前提下，积极探索多中心、跨机房高可用架构，如图8所示，规划两地三中心高可用架构，在同城双中心实现业务的双活运行，同时规划异地灾备中心实现业务的灾备部署能力。

图8 云平台跨机房可高用架构图

2.8 安全设计

针对银行业监管力度的加大及金融数据的较强安全性考虑，就行业云平台安全能力提出了较高的要求，因此针对云平台的安全防护方面规划如图9所示，具备漏洞挖掘、0day跟踪、安全检查、安全分析、安全规则及威胁情报等方面能力，从物理、硬件、虚拟化、产品及运维安全五个方面进行安全防护，从而实现云平台产品和服务的全栈安全。

图9 云平台安全防护方案

针对云平台防护方案，又制定出了云平台安全管理体系等更细致的安全措施来对数据、应用、主机、网络及物理等安全方面进行防范，具体如图10所示。

3. 建设效果

3.1 项目进度计划

通过以上对行业云平台架构设计进行充分分析和论证，借鉴行业内行业云平台建设思路，参考厂商云平台产品架构及特点，进一步拓宽行业云平台建设思路，由于行内云平台技术薄弱及技术人员缺乏，通过自主开发及建设具备自主知识产权的云平台所耗精力、时间和成本都无法承受，因此通过引入厂商成熟云平台产品来满足规划的云平台需求经充分论证是可行的。于是通过前期沟通、规划架构、立项、POC测试、商务招标等完成行业云平台的选型工作，确定了行业云平台的建设厂商和技术路线。在POC过程中着重在云平台能力、计算能力、存储能力、网络能力、安全能力、可靠兼容性能力等功能能力方面进行充分验证，也发现各家厂商在云平台相关能力方面相差不大，各有千秋。行业云平台的建设进度计划如图11所示，主要分为启动、规划、实施和验收这4大阶段，其中启动和规划阶段耗费1个半月时间，主要就项目启动、厂商对行内行业云平台的技术架构、技术规划及技术方案等进行充分沟通；然后通过大约2个月的时间来完成云平台的实施建设及平台联调，其后开展试点业务上线及业务试运行，待业务试运行稳定3个月后开展云平台的相关验收工作。

图11 行业云平台建设进度计划图

3.2 平台预期效果

项目启动后联动行内多个科室部门与云厂商技术团队成立行业云平台建设团队，通过项目PMO整体牵头和联动项目的整体实施及协调项目过程中出现问题的解决，攻坚克难，圆满完成了行业云平台的整体建设任务。

就整个行业云平台的管理而言基本实现五个统一管理，即统一门户实现多维度用户统一管理、统一运维实现一体化云运维、统一运营实现精益化运营管理、统一服务实现敏捷化云服务交付及统一纳管管理实现多元化云资源纳管，如图12所示，从云、管、端“三位一体”业务管理模式，以云实现各类云平台、云资源的标准化、可配置化；以管实现管理标准化、资源及运维服务化、交付自动化、运维场景化、运营持续化；以端实现各类用户群体的个性化管理。多层次、多结构、多步骤实现云平台统一串联及管理，初步达到云平台规划效果。

图12 云平台运营实现效果

3.3 社会及经济效益

通过行业云平台项目的建设，平台采用微服务架构、存算分离、云网一体、一云多芯等思路进行打造，标准化、统一化、流程化及可视化重新定义云平台效能。同时平台支持国产CPU服务器、国产操作系统、国产中间件及国产数据库等信创名录产品，满足国家信创验收的各类要求，显著提升行内基础设施自主可控能力，消除了供应链内在风险，还通过业务系统分布式改造，推动了基础设施架构转型升级及业务云化。

在整体解决方案相比传统架构可大幅度降低软硬件成本，使得单业务系统运维管理成本降低为传统的1/5-1/10，资源申请周期缩短为传统的1/5，系统中断时间较之前降低5倍。

3.4 业务上云推动

随着云化步伐的加快，行内传统业务面临着分布式改造及云化改造的抉择，去“IOE”浪潮的推动下分布式改造也初见规模效果，大部分系统已初步完成分布式改造，并运行在虚拟化上。基于虚拟化平台的稳定及对云环境的担忧导致业务上云速度较为缓慢，因此针对业务上云进行规划及设计，具体的上云流程如图13所示，分为现状调研、需求分析、上云评估、上云设计、技术验证、上云实施、试点运行及批量上云这几个步骤，通过先规划、有步骤、分批次等有序推动业务上云任务。

图13 业务上云规划流程图

3.5 云平台运行情况

项目一期落地云平台服务器规模台数400余台，其中开发环境150余台，生产环境250余台，开发和生产两套环境物理隔离部署。云平台提供多种云服务（含计算、存储、网络、安全、中间件、数据库及大数据等）快速贴合行内需求，从安全防护、WEB出口、APP应用、中间件到数据库，纵向解决整个业务系统的各种所需，在短时间内快速实现业务上云，整个部署效率同传统相比缩短到1/5。通过建设行业云平台到云平台业务试运行，再到业务正式上线运行，至今已过去几个月，随着业务的持续上云部署及信创的推动，云平台承载的业务不断增多，期间云平台也开展了多次组件的扩容，整体规模增长至500余台。

为更好地保障行业云平台的稳定运行，行内规划及设立云平台运维团队来进行保障，通过每日2-3次云平台巡检、风险点修复及消除、漏洞修复及版本升级、容量管理及阈值清理等多种手段确保云平台稳定运行，同时定期开展深度巡检、应急演练等进一步消除隐患。期间云平台业务平稳运行，未发生故障。但服务器硬件故障（如CPU、内存故障等）导致服务器宕机或重启，导致服务器上虚机重启迁移等现象时有发生，但无法避免，通过对应用进行集群化改造，避免单台业务节点运行等方式消除隐患，同时进一步加强云平台监控及故障联动处理机制。

3.6 存在问题及注意事项

当然在行业云平台在建设的过程中也会遇到诸多问题。例如：

1、安全性方面，行业云服务涉及到大量的金融敏感数据和客户敏感信息，而互联网上各类黑客层出不穷，面临的互联网防护压力也逐年增大，因此安全性是行业云行业面临的主要问题。

2、标准化方面，行业云的发展尚处于初级阶段，行业标准尚未完善，监管体系尚未成熟，给行业云的发展带来了一定的挑战。

3、云平台双活及灾备方面，针对云平台跨机房双活或容灾需求，如何进行规划建设，是否满足业务要求及建设成本是否接受等都需综合考虑。

4、云平台运维方面，由于云平台各厂商技术路线不一样，技术专有度较高，行内相应人员缺乏，云平台的运维目前只能暂时依靠外部力量，自主性较差。