文章简介：

本文以中小银行数字化转型为背景，对中小银行传统应用迁移容器云平台的实践经验进行总结，探索出适合中小银行特有金融架构特征的容器云平台建设路线。从业务需求出发，通过建设以容器云平台为基础的底层IT资源平台，为业务发展提供安全、稳定、可靠、灵活的支撑。同时，本文也将针对容器云平台落地面临的容器灾备、容器云网络建设等问题进行选型和实践经验分享。

一、 建设背景

近年来，随着金融业务不断扩展，云计算技术在金融行业的发展已经经历过了第一代虚拟化、第二代资源池化，正在向以容器、微服务、DevOps为关键技术和特征的第三代云计算技术前进，以满足金融业新型业务对快速部署、弹性扩展、自动化运维等核心需求。

金融行业已经步入以容器为核心的第三代云计算技术的时代，目前国内大型金融机构虚拟化技术相对成熟，从国有五大行到区域银行都在积极向基础设施云推进，但中小银行相对缓慢，更多处于云平台的尝试使用阶段。

面对高并发、多频次、大流量的全新业务场景，银行业务系统的响应效率变的越发重要，同时金融业务的服务连续性要求也越来越高。而我行原有的基础架构平台已不足以支撑银行当前的高速信息化建设及创新发展要求。如何应对不断升级的互联网业务系统，紧跟大行科技信息化建设的步伐，建设具有中小银行特有金融架构特征的容器云平台变得尤为重要。

二、 需求分析

在银行数字化转型的进程中，传统虚拟化在一定程度上降低了运维的复杂度，提升了资源的利用率，解决了IaaS层面基础设施的问题。但在金融业务数字化转型趋势下，传统应用系统框架正加速向新型互联网金融业务框架改造和升级，银行运维管理部门面临的互联网时代下对金融IT基础架构挑战也越发明显，具体的需求和挑战主要有以下几方面：

1、基础设施建设层面。金融云数据中心一直以来都习惯采用最成熟稳定的IT技术路线通常使用国外主流厂商提供的商业产品和相关技术来构建数据中心，在技术实施、支持和运维保障等方面很大程度依赖设备供应商，这使得金融行业自身缺乏核心的技术积累；传统技术方案根据业务峰值来配置基础设计资源，造成大量的资源浪费，拉高了金融IT建设成本。因此需采用先进的成熟技术，借鉴同等规模的金融单位实际建设应用情况，同时满足信创国产化诉求，避免一家厂商绑定的情况。结合我行的VMware使用现状，现行考虑与Openstack的商业化厂商进行深度合作。

2、多云管理与服务运营。随着金融业务的迅速发展以及规模的不断扩大，金融IT系统的数量、规模和复杂度也呈现几何级数增长。金融虽然数据中心完成了大集中建设，但依然延续了传统的建设模式、传统的技术方案。因此多厂商、多云共存、多控制平面分别管理的现状，各自独立运维管理，增加了管理复杂度等问题，同时无法提供可视化的运营管理。结合我行的未来建设需求，考虑通过CMP建设统一的管理平面，解决多云统一化运维难题，同时通过服务目录设计与自服务功能，解决多云统一化运营难题。

3、业务快速响应。在金融服务互联网化以及利差市场化的挑战下，金融业务转型已经成了唯一出路，各大金融机构也将互联网化提升到了发展战略，并以此快速推出创新业务。但这些新目标所需要的海量处理能力基本上无法通过传统IT基础设施设计模式有效满足，传统商业方案的天花板是大型机模式，但高昂的建设成本和漫长的建设周期也是企业无法承受的，探索高效、弹性、成本合理的新型基础设施建设模式已经成为金融IT建设的必然选择，同时传统建设模式和方案不利于大规模弹性伸缩，为了弥补这些与生居来的问题，传统方案设计上愈来愈复杂。因此IaaS层建设通过SDDC进行实现，采用多云、多技术栈架构，应对不同的业务场景，快速响应业务需求，如通过Openstack、Kubernetes等技术，建设业务的弹性能力、快速扩容能力、DevOps能力。

4、云平台容灾备份。金融云平台业务连续性要求愈发严格，运行风险日益增大，数据中心稳定运行的风险越来越突出，保证数据安全、业务连续性满足金融云的合规安全需求。因此实现主数据中心不可用情况下，备数据中心无缝割接网络及接管主数据中心业务系统，保障业务系统安全和业务服务的持续势在必行。

我行近两年已构建了基于Iaas平台的“两地三中心”基础架构，数据中心服务能力由传统主备服务能力向云上的“双活”或“多活”中心服务能力提升。为满足进一步发展建设的需求，需以围绕提升银行内部开发效率，逐步改善原有IT基础资源管理方式，提高资源利用率为目标，构建以超融合为基础的IaaS虚拟化平台和容器云平台组成的底层IT资源平台。

三、 技术路线选型及难点分析

1、现有IT架构和业务架构的痛点

我行在IT架构技术演变过程中，需要考虑到两点，分别是IT组织内部的降本增效，提升资源和产品的交付能力，同时还要具备较高且灵活的业务架构的适配，更好的支撑业务。

业务架构以实现企业的经营战略为目标，构建全面的市场化业务能力并实现对接IT架构的能力，IT架构需具备安全性、稳定性和可扩展性，提供端对端的支撑。业务架构和IT架构随着企业的业务发展，两者之间的边界已经不再泾渭分明，因此IT架构也需要通过技术的手段帮助IT团队加深对业务架构的理解，目前主流的方法是通过对IaaS能力的下沉，PaaS能力的平台化进行实现。

目前，主要痛点在于因IaaS过多的承担资源单向输出，更多的面对信息化建设场景，无法从企业战略的需求提供更优质的弹性伸缩能力，而业务需求的不稳定性也加速这种矛盾的爆发，因此这种输出能力的滞后性也带来了对于业务的高稳定性和高可靠性的挑战。

结合我行现阶段的发展情况进行规划分析，通过服务器虚拟化及容器虚拟化技术，作为基础架构底座，来建设金融云平台。基于容器技术的基础架构革新势在必行，这是面向业务“云迁移”的一个重要分支。通过容器云的敏捷性提升开发运维上线速度，提高跨环境的高一致性，提高开发交付质量；通过容器云的弹性伸缩能力，消除单点故障，提升业务访问效率；通过可扩展性，实现细粒度动态扩展和最大化的组件、资源密度，从而充分利用基础架构资源。

2、容器云建设难点分析

金融云平台整体包括IaaS和容器两部分，金融云平台为本项目建设范围，包括基础设施云平台、容器云平台、统一云管理平台、DevOpS、云安全和云灾备。

在建设容器云平台的过程中，特别是在传统的金融银行业对监管要求严格的情况之下，容器云平台的落地会面临很多的问题和挑战。

· 灾备多活

我行近两年已构建了基于Iaas平台的“两地三中心”的基础架构，核心数据库通过iaas层的存储双活方式进行构建，防范物理性的故障导致数据丢失问题；重要数据通过备份软件进行数据冷备，防范逻辑故障导致的数据丢失问题。看似架构完整，其实存在众多问题，例如：主备数据中心负载问题、应用切换问题、数据库同步及切换等问题。

我行此次的规划是建设金融行业云平台，满足金融的监管需求以外，如何满足灾备多活的建设目标，建设的难点在于容器云“多云多活”，多套容器云多数据中心，实现业务应用流量的负载及切换，数据的实时同步等。

· 容器网络

目前，行业内容器云网络建设没有标准化的建设方案，容器云网络方案可谓百家争鸣。既要满足行内本身的技术架构体系，又必须同时满足各个团队对于业务、运维等方面的诉求，如：平台内外网络能够直接打通；管理网络和数据网络分离；具备网络隔离能力，硬件隔离的强安全性和软件隔离的灵活性；网络模型力求简单，易于掌控，易于调试；高性能，低抖动的网络吞吐及增加固定 IP 的能力；能够与SDN无缝对接能力；能够支持IPv6的网络等。

另外，如何利用容器云平台同时支持开发测试场景及生产场景，且提高效率；生产场景又不同于开发测试场景，上线一套系统要求更为严格，安全、监控、流程、原有系统集成等等的建设要求都要匹配上。这些问题在容器云平台的建设过程中都是需要考虑的难点。

2、容器云技术路线选型

金融行业作为一个高度监管的行业，对服务的可用性以及数据的安全性要求相对其他行业更高，同时在初期平台架构设计与选型时也需全局综合考虑各种因素：

1) 考虑自身的技术能力，包括开发能力、运维能力；
2) 考虑现有系统对接需求，包括监控、网络、安全需求等；
3) 所选技术需符合当前潮流与未来发展趋势，有较好的生态链和较强的生命力，但同时也需在先进性与稳定性之间寻求平衡点；
4) 能满足银行业务不断的发展与创新的需求，尽量做到平台横向平滑扩展。

基于以上因素及现有架构的痛点，在众多的容器云解决方案中，我行选择了目前容器云平台最主流的解决方案，即以docker+kubernetes为代表的容器技术和应用部署方案。

Docker容器技术有几个优势，一是在一台物理机上启动多个在独立沙箱内运作的应用，相互不影响，无Guest OS，资源利用率更高；二是Docker基于镜像的方式将应用及所有依赖打包，使docker具备快速部署，快速启动，快速故障恢复，开发运维一体等优秀特性；三是以统一的方式跨平台云发布应用。

Kubernetes是用于自动部署、扩展和容器化应用程序的开源容器编排平台。当使用的容器服务增加、面临的访问量加大时，需一种工具将容器进行统一管理，实现对这些容器的自动部署、扩展和管理。

4、厂商选型

目前国内很多单位利用开源技术构建云计算架构，但是纯粹的开源软件存在诸多问题，如：开源软件的成熟度，安装部署的易用性，运维的复杂度等方面都存在着或多或少的问题，开源软件无法及时响应处理故障。

因此开源产品对于金融云平台需要高标准、高可靠等要求来说其实是个问题，所以要选择有实践经验的商业版本供应商。另外考虑到金融云未来长期的发展和一体化集成诉求及便捷性、技术可行性，所以我行选择由一家专业厂商统一建设。

同时，为了解决kubernetes落地时的网络难题，我行对目前市场容器平台的网络CNI插件进行了调研。虽然目前容器平台的网络CNI插件有多种，但主流的CNI插件对某些需求的支持并不理想，难以同时满足某些网络需求，如内外网互通、管理业务网络分离、灵活的网络隔离机制、易于运维管理和调试等需求。

基于我行目前的业务需求，技术选项阶段我行针对主流的三层网络calicao和二层网络Fabric进行了比较，最终考虑采用二层网络进行构建。以下为两者的比较结果：

结合我行的现状，通过对当前主流容器平台openshift3、openshift4、Rancher、博云等国内外容器厂商的产品进行功能、性能对比，经过综合评估，最终我行选择与在容器及容器网络方面有丰富经验的本土化容器厂商博云合作。

同时，容器云的网络建设作为本次金融云规划的重点之一，前期通过大量的调研，内部业务运维部门沟通，最终采用的是博云基于OVS自研的容器网络插件。其可以很好地利用物理网络设备，结合当前网络需求的特点，提高网络访问效率。方案上使用fabric网络组件，将容器管理网与应用业务进行分离，业务网络与管理网都为实际物理层面的二层网络，可以让容器的IP直接对外提供访问服务。

以下为使用fabric网络的应用Pod在IaaS平台中的桥接过程，即Pod桥接在各K8S节点中的OVS，K8S节点桥接在IaaS计算节点的OVS，流量最终直接进入物理交换机。

通过Fabric打造纯二层网络模式，解决了我行金融容器云网络的以下建设难题：

从运维管理角度，采用了二层网络模型，无需引入三层网络方案，同时将管理网络和业务网络进行分离，简化运维、提升工作效率。

金融容器云内部网络与外部网络互联互通，业务应用往往会在容器云平台内外同时部署，平台内外网络直接打通，POD与虚拟机/物理机同等地位，有利于与已有的云产品无缝整合。

网络安全性方面，支持Pod固定IP地址，应用互访跨防火墙的等场景下，POD具备固定IP地址。灵活的网络隔离：包括强安全性的硬件隔离和灵活的软件隔离。

网络性能方面，提供高性能，低抖动的网络环境。网络模型同时支持Underlay和Overlay：Underlay性能好，可以内外网互通；Overlay不依赖底层网络，灵活性强，最好可以同时支持。

对于我行未来的网络扩展方面，能够满足IPV6的建设。

四、 建设方案

我行整个金融云平台建设是从一个完整的架构角度考虑IaaS层的搭建，从VMware扩展到OpenStack，在底层各种虚拟化技术之上，通过云管平台对底层的各种资源进行纳管，而容器技术仅是我行金融云平台中采用的众多新技术其中之一。本章节重点阐述容器云平台的建设实践解决方案。

1、总体架构

从云化视角，三朵云支撑我行云化逐步落地。三朵云为：开发测试云和生产云，其中生产云包含生产和灾备两套云平台。通过博云产品提供的多云管理Portal和DevOps Portal实现底层资源管理及运维操作管理。多云管理Portal主要提供云资源的统一管理、多租户服务、自动化作业、用户自服务等能力。DevOps Portal提供容器应用持续集成和部署管理，通过代码和应用包完成一键发布、变更。生产环境中，完成应用的多中心部署和F5负载均衡自动注册，通过应用包或者镜像进行发布。

项目整体建设目标如下：

根据我行的建设要求，实际交付开发测试云和生产云，其中生产云包含生产和灾备两套云平台支撑，实现应用的云化、数据的容灾。统一管理界面将分为操作基础设施资源的云管理平台界面和操作应用容器化发布的容器管理界面，实现资源的集中化管理及变更等服务。底层架构由OpenStack架构、Kubernetes架构、F5负载均衡设备提供基础设施支撑，实现多机房、多设备、多业务系统的稳定运行、快速交付。

2、容器云平台灾备

容器云平台灾备建设也是本次建设规划的难点之一，灾备设计方案主要考虑数据级备份、应用级备份和网络切换。数据层面根据数据类型，采用行内平台承载和多地部署同步方式，保障数据一致性；应用层根据应用类型，采用多活部署和单体部署加备份方式，保障应用服务可用性和连续性；网络流量的切割依赖F5负载均衡DNS方案，保障访问流量的自动切割。

通过主备数据中心对单体应用备份和多活应用双数据中心部署的方式，结合应用数据外置挂载和主备数据中心三层网络可达的部署，保障IaaS平台应用在某数据中心发生灾难时，应用服务可以在短暂时间内迅速恢复。

2.1部署架构

基于多活的应用架构，在内网区部署容器平台管理，纳管云内网区K8S集群、云互联/外联区K8S集群、灾备云内网区K8S集群、灾备云互联/外联区K8S集群，应用在主数据中心和备数据中心同时部署，共用行内平台中承载的应用数据、应用数据库和公共中间件；基于不支持多活部署的应用架构，部署备份平台。

2.2切换架构

基于多活的应用架构，主数据中心出现数据中心故障后，访问的流量切换至备数据中心；备数据中心出现数据中心故障后，访问的流量切换至主数据中心；基于不支持多活部署的应用架构，备份平台启动备份应用虚机，承载访问流量。

2.3网络切换

2.3.1. F5负载方案
F5负载均衡在主数据中心及备数据中心各部署F5 LTM和智能DNS，通过F5智能DNS和行内DNS的合理层次结构配置，从主数据中心和备数据中心两个入口进入的访问请求，分发至对应的IaaS云平台，到达主数据中心和备数据中心云平台中部署应用服务端进行处理。

F5负载对内使用SNAT Pool方式，根据应用在各数据中心不同区域的IP地址段，在F5中设置对应的静态路由。

通过容器平台发布的应用，在支持双活部署的情况下，在主数据中心和备数据中心同时发布，应用在不同的数据中心中加入不同的Virtual Server，前面通过DNS域名提供访问，以双活方式对外提供服务。

对于服务发布在Kubernetes集群中的应用，通过F5 CC控制Kubernetes集群中的Pod自动向对应的Partition中注册node信息，并自动创建Pools，同时使用iRules控制入口流量向对应的Partition中Pool。

2.3.2正常网络访问
双活部署应用流量访问：

互联网进入的访问流量，进入行内DMZ及防火墙等网络后，从主数据中心入口进入的流量进入由DNS处理后主数据中心的云互联/外联网络F5负载，根据应用部署架构进入相应的Web服务器，再进入内网的应用服务；从备数据中心入口进入的流量由DNS处理后进入备数据中心的灾备云互联/外联网络F5负载，根据应用部署架构进入相应的Web服务器，再进入灾备内网的应用服务。

内网进入的访问流量，由DNS处理后，内网主数据中心的访问流量进入主数据中心的内网F5负载，根据应用部署架构进入相应的Web服务器和应用服务器；内网备数据中心进入的访问流量进入备数据中心的灾备内网F5负载，根据应用部署架构进入相应的Web服务器和应用服务器。

单体应用流量访问：

从互联网进入的访问流量，进入行内DMZ和防火墙等网络后，经过DNS处理进入主数据中心云互联/外联网络F5负载，根据应用部署架构进入相应的Web服务器，再进入内网的应用服务。

内网进入的访问流量，由DNS处理后，进入主数据中心内网F5负载，根据应用部署架构进入相应的Web服务器，再进入应用服务。

2.3.3灾备网络切换
双活部署应用流量访问：

互联网进入的访问流量，在主数据中心整体故障后，流量进入行内DMZ及防火墙等网络后，无论从主数据中心或者备数据中心进入的流量由DNS处理后进入备数据中心的云互联/外联网络F5负载，根据应用部署架构进入相应的Web服务器，再进入内网的应用服务。

内网进入的访问流量，由DNS处理后，仅备数据中心内网可进行灾备内网的应用的访问，访问流量进入备数据中心的灾备内网F5负载，根据应用部署架构进入相应的Web服务器和应用服务器。

单体应用流量访问：

互联网进入的访问流量，在主数据中心整体故障后，流量进入行内DMZ及防火墙等网络后，无论从主数据中心或者备数据中心进入的流量由DNS处理后进入备数据中心的云互联/外联网络F5负载，根据应用部署架构进入相应的Web服务器，再进入内网的应用服务。

内网进入的访问流量，由DNS处理后，仅备数据中心内网可进行灾备内网的应用的访问，访问流量进入备数据中心的灾备内网F5负载，根据应用部署架构进入相应的Web服务器和应用服务器。

4、环境规划

规划建设开发测试环境容器平台与生产环境容器平台，开发测试环境作为应用上线前，进行功能测试、性能测试和预生产发布测试的应用持续集成与持续部署环境，生产环境容器平台主要通过经开发测试环境验证后可发布的容器镜像进行应用发布，部署的K8S集群由容器Portal统一做资源管理，并创建租户，配置配额供用户使用。

用户登陆Portal后，基于不同的用户角色对平台的操作范围进行控制，当前平台支持平台管理、租户管理、租户用户等多级管理。平台对不同的角色有默认的操作范围设置，同时也支持对各角色的操作范围进行自定义设置。

五、 实施经验及效果

1、实施经验总结

1）建议采取从外围系统开始逐步迁移的实施路线；
2）建议考虑将渠道类系统、客户营销系统和经营管理等辅助性系统尝试使用相关行业云服务；

• 非金融辅助性业务系统安全等级较低，系统问题不会导致巨大的业务风险；
• 提升系统管理的灵活性，降低运营成本，也大幅提升了相关的用户体验；

2、实施效果

通过本次容器云平台建设，规范应用上云标准及上云流程，统一应用全生命周期管理，提供容器应用持续集成和部署管理；通过代码和应用包完成一键发布、变更；生产环境中，完成应用的多中心部署和F5负载均衡自动注册，通过应用包或者镜像进行发布；实现应用在开发、测试、仿真和生产区的多环境持续交付。

通过有效整合开发测试环境的计算资源、网络资源、存储资源等各类软硬件资源，不仅能满足开发测试环境中各类资源和服务的统一管理，更能够满足业务交付灵活化、资源调整智能化、环境运维自动化、环境管理精细化等需求，并能够实现企业级统一化、标准化、可视化和流程化的管控机制。

1）应用上云：将传统应用向容器平台进行迁移，支撑银行互联网应用快速开发测试上线，支撑创新业务发展，加速数字化转型。如,某业务平台每日平均会有30W+交易量，峰值会有100W交易量。通过把业务抽象为微服务，规划服务群组，对原系统进行解耦重构，按照分布式微服务的架构，构建于私有金融云平台之上。通过容器化多活部署上线，已超过1000多家企业客户迁移到平台中，后续还将陆续迁移。
2）应用弹性赋能：通过容器云平台建设，提供基于K8S的分布式应用基础设施，让容器化应用实现在线快速扩缩容。
3）资源统一管理：开发测试环境硬件资源（计算资源、存储资源、网络资源）的统一纳管、软件资源（操作系统、中间件、数据库等）的自动化安装以及应用服务的自动化部署，有效降低了开发测试环境管理的难度。
4）基础设施云化：解决基础资源交付的问题，包括虚拟化的计算、存储、网络，底层硬件资源对接。实现提升资源利用率、降低计算设备成本，提高管理效率，降低运维工作的人力成本。
5）多集群管理+应用维度的租户管理，实现敏捷开发测试；多集群管理+环境维度的租户管理，实现稳定生产管理。
6）系统使用效果：

• 在开发测试环境中：容器云平台支撑数十个应用测试业务， CICD构建次数达到2000多次，在开发容器集群、测试容器集群和仿真容器集群运行近200个容器。
• 在生产环境中：容器云平台支撑业务中台业务多活部署上线，20多个组件容器化生产上线，运行近70个容器。

3、建议实施落地原则

1）需求驱动

• 紧密结合业务场景；
• 有明确场景需求的情况下，优先考虑进行与此相关的基础架构落地实施；
• 对于那些目前还未明确业务场景需求的情况，根据系统优化和改造需求，进行安排；
• 业务应用和系统建设暂无明确需求的情况，暂缓进行架构落地。

2）现状考量

• 充分考虑现实难点；
• 在结合明确业务需求的情况下，要从执行难度、实施成本、实施风险和影响范围等多个方面充分考虑现实情况，根据难易情况拟定架构执行的优先顺序和执行内容。

3）循序渐进

• 先易后难、先新后旧、先小后大；
• 根据现实情况拟定优先级，循序渐进；
• 基础架构的建设是一个过程，不是一个结果，需要不断根据业务应用的需要进行迭代式的开发和建设。

六、 未来规划和建议

我行的整体金融云平台建设方案是基于我行的现状情况定制的解决方案，整体包括IaaS和PaaS两部分，其中容器云平台为本次主要的实践分享，属于IaaS平台建设的一部分，IaaS平台建设包括基础设施云平台、容器云平台、统一云管理平台、DevOpS、云安全和云灾备。

整体金融云平台纳入的除了容器云，还有PaaS层组件、微服务、DevOps等新技术。综合这些，同时本着自主可控的原则，逐步建设一个从IaaS到PaaS的私有云框架，分阶段逐步推进实现业务上云，在不远的未来建成一个完整的金融云平台。

但基于各金融机构各自状况不同，建议通常的建设规划路线如下：

1、IaaS云平台建设：

• 一期：完成基础的openstack云平台建设；
• 二期：根据应用需求进行集群扩容，完成适合的业务上云。

2、PaaS云平台建设：

• 一期：基于IaaS搭建容器管理平台，在生产环境完成一个互联网金融应用上云试点；
• 二期：多个应用改造迁移，推进新建应用以微服务开发；
• 三期：生产环境与测试环境网络打通，全部互联网应用改造上云，推行Devops开发流程。

3、云管理系统建设：

• 一期：搭建以资源自服务、虚拟机纳管为主的云管理平台；
• 二期：增强纳管能力，包括物理机、小机、数据库等。