银行金融容器云基础设施创新实践

【摘要】

随着互联网金融的兴起，互联网企业依托互联网，特别是移动互联网为公众提供越来越多方便快捷、稳定高效的金融类服务，对传统的银行业务带来了很大冲击。作为应对，传统银行也在业务上不断创新，带来对IT基础设施和应用架构方面进行转型升级的要求,譬如银行内部的业务系统在开发、测试、部署、以及运维还以传统模式为主，无法满足业务创新要求的快速、弹性、敏捷等特性，同时也缺少整合、高效的基础设施平台支撑。

近年云计算技术发展和云原生技术的不断迭代演进，云原生产品能力也在不断成熟和完善，云原生架构逐渐成为传统银行的IT架构选型方向。传统银行基于云原生技术建设并推广适合自身的容器云平台,实现传统应用迁移上云和云原生改造，是转型升级的重中之重。

金融云平台的基础设施是金融云平台建设的基石，本文基于银行现实的基础设施需求做出相关技术分析，并结合企业生产实践，提出一些实践经验。

一、银行金融容器云平台建设业务背景

支撑突发的海量交易
由于互联网的发展，网上交易量在某些特定时间，无法准确预测峰值，需要银行信息科技系统支持快速的资源弹性扩展，满足突发海量交易的需求。
应用快速开发迭代
互联网金融产品层出不穷，各种金融应用产品开发、上线、迭代越来越快，需要信息科技系统支持分布式的应用开发场景，满足应用快速开发迭代,遵从银行已有的IT技术规范和研发管理要求，包括：支持银行自身研发管理的应用发布体系、持续集成系统、应用建模规范、高可用部署规范。对接金融云底层资源池（例如IaaS），遵从云计算资源的统一管理和分配。对接或改造容器平台的网络，以满足容器平台中应用与传统虚拟机、物理机中旧业务系统的相互通信，避免或尽可能减少对银行现有网络管理模式的冲击。对接统一身份认证、集中采用统一的租户定义、角色定义、资源配额定义等。对接漏洞扫描、集中监控系统、日志分析系统等已有周边系统。
银行快速开业、降低信息系统成本和运维复杂度
金融容器云平台需具有管理大规模容器集群的运维能力，包括：提供容器所需的高可用集群、资源池管理、网络通信方案、存储方案、编排调度引擎、微服务运行框架、镜像管理、事件告警、集群监控和日志收集等。为满足金融业务的监管和安全要求，平台还需要考虑应用的高可用性和业务连续性、多租户安全隔离、不同等级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、后台运维的4A纳管、审计日志；如果容器平台还对公网提供访问，那么还需要考虑规划DMZ区、访问链路加密、安全证书等需求。
业务连续性持续优化
重要业务系统运行的业务连续性要求异常苛刻，如停机超过半小时造成的业务损失、声誉损失估值可达数千万元人民币。所以信息科技系统灾备建设对银行来说至关重要，必须要有一个可靠的容灾系统在灾难到来时保障业务不间断运行，传统灾备建设存在IT设备资源率较低、维护成本高等问题。随着信息技术的发展，云灾备技术可以为银行建设灾备中心提供新的策略。

二、银行金融容器云平台架构设计需求分析

2.1 对容器云的云服务功能需求

关键应用在金融容器云上部署时，需要金融容器云提供以下云服务的支持。

容器服务：为关键应用提供轻量级的应用封装、管理和运行。

中间件服务：包括消息中间件、数据访问中间件、分布式事务中间件等，中间件服务具备较高性能，支持完善的日志记录，提供良好的管理界面和操作审计功能。
数据库服务：包括关系型数据库服务和非关系型NoSQL数据库服务，其中关系型数据库服务包含集中式关系型数据库服务和分布式关系型数据库服务。

2.2 容器云提供关键应用研发管理的支撑需求

关键应用在金融容器云上部署时，需要容器云提供开发框架、 DevOps 研发管理的支持。

开发框架的支持：固化银行研发管理的技术规范及约束，在业界成熟优秀的开源类库和开源框架上进行功能增强和优化，以 模块化 的方式为关键应用的研发提供各种功能模块，使开发人员能够快速开发上云应用，并获得极好的用户体验。
DevOps的支持：落地银行的研发管理体系，提供协同工作、持续交付流水线、配置管理 /源码托管工具、测试管理、自动化部署、度量分析等研发管理活动的工具支持。

2.3 对容器云的安全合规需求

2021年9月1日，我国正式施行《关键信息基础设施安全保护条例》。按照关键信息基础设施认定规则，银行金融容器云平台是认定为银行的关键信息基础设施之一, 需满足等保2.0 的安全合规要求。

2019年12月1日，我国正式实施网络安全等级保护制度2.0 。依据《GB/T22239-2019 信息安全技术网络安全等级保护基本要求》中的规则，需要通过等保2.0的第四级。

等保2.0一方面横向扩展了对云计算、移动互联、物联网、工业控制系统和大数据的安全要求；另一方面纵向扩展了对等级保护测评机构的管理规范、明确定级流程、扩展定级对象确定方法等。云上租户和云服务商的等级保护对象要分开定级，根据云上服务模式再分别定级。

银行关键应用进行分布式架构转型后，在金融容器云上部署。两者之间的关联关系为：银行金融容器云为PAAS云服务商，银行关键应用为云上租户，其中云服务商的职责范围包括硬件、虚拟机监视器、操作系统和中间件，云租户的职责范围为应用。安全责任边界如下图所示：

等保2.0对容器云的安全要求，如下表所示：

三、银行金融容器云平台的设计原则

银行建设金融容器云平台的目的是用来承载银行业务应用系统的，需实现IT融合、应急响应、敏捷开发、应用交付、权限认证、弹性伸缩、异常迁移、环境一致性、高可用、网络隔离、资源配额、日志收集、健康检查、监控告警等能力；中远期目标是通过采用微服务架构、DevOps方法论等逐步构建企业数字化转型的技术中台和服务中台。

银行建设金融容器云平台需要遵循建设容器云的目的和需求，满足以下设计原则：

高可用原则：关键核心组件，都要求高可用设计、高可用部署，保障在服务器宕机等故障情况下，应用不受影响。
先进性原则：平台的建设所采用的技术是业界主流云计算技术，确保平台在一定时间内具备稳定的更新和保持先进性。
成熟性原则：技术选型确保先进性的技术上，采用成熟的技术，确保平台功能稳定。
开放性和兼容性原则：标准化或通用的技术手段兼容主流的设备和系统、软件、工具等。
可靠性原则：提供可靠的计算、存储、网络等资源，在平台、服务、应用、组件等方面实现高可用，避免单点故障，保证业务的连续性。
可扩展性原则：采用分布式架构，支持在不更改整体架构的前提下进行系统扩容和业务范围的扩展。平台的计算、存储、网络资源等根据业务应用工作负载的需要进行动态伸缩。
松耦合原则：容器云平台架构采用松耦合架构，平台各组件提供开放标准的API接口，方便客户已有系统的集成或平台组件的扩展和替换。
安全性原则：安全无处不在。支持覆盖全方位的安全机制。横向：弹性伸缩、负载均衡、异常迁移等；纵向：协议层加密、网关、访问控制、过滤、限流、熔断、禁用root用户运维权限、系统资源用户受限访问、资源隔离、网络策略等。容器云平台应该在各个层面进行完善的安全防护，确保信息的安全和私密性。
用户友好原则：注重用户体验，提供简洁便利的操作体验，避免二义性，界面操作保证流畅简单。
隔离性原则：容器云平台租户之间实现隔离，租户和平台管理之间实现隔离。
生态原则：容器云平台需要构建生态体系，提供和集成认证、权限、配置、日志、监控、告警、注册发现、网关等能力，支撑银行关键业务应用系统。

四、银行金融容器云平台基础设施的技术选型

金融容器云平台应提供的业务能力、以及容器平台在银行可能和周边系统的对接关系如下图所示：

其中的“金融云基础设施/IaaS”是指机房、计算、存储、网络等基础设施和设备，是金融容器云平台的基石。金融容器云平台需使用安全可控、体系架构开放的硬件进行构建，保障安全性、可用性和可靠性。

机房
银行私有云平台的机房建设，必须选择T 3 机房或者T 4 机房。

在机房建设上（注：大型的设备和管理都比较完善的机房可以称为数据中心），根据美国国家标准学会（ANSI）颁布的《数据中心电信基础设施标准》，基础设施的可用性定义了四种不同等级，即Tier 1、Tier 2、Tier 3和Tier 4四个等级。

四个等级分别对应数据中心的可用性指标及年平均故障时间：

1) T1机房（通过基本认证）：可用性99.671%、年平均故障时间28.8小时；

2) T2机房（通过银级认证）：可用性 99.741%、年平均故障时间22小时；

3) T3机房（通过金级认证）：可用性 99.982%、年平均故障时间1.6小时；

4) T4机房（通过白金级认证）：可用性 99.995%、年平均故障时间0.4小时。

Tier等级标准的等级分类如下表所示：
计算资源
计算设备指提供计算能力的物理服务器，应统一纳入到计算资源池进行管理。一台典型的X 86 物理服务器的硬件配置如下所示：
存储资源
存储设备类型分为集中式存储和分布式存储。

集中式存储设备的具体要求如下:

— 采用高密度物理磁盘和高可用控制器;

— 集中式存储架构应具备较高的 I/O 处理能力，支持存储扩展。

分布式存储设备应支持将数据分散存储在不同的存储服务器中，支持存储服务器分布式扩展。
网络资源
网络设备包括了数据中心内部网络和跨数据中心网络，具体要求如下:

— 数据中心内部网络应采用高可靠、低时延、可扩展的网络架构。

— 支持按照计算、存储设备的通信需求，提供低时延处理和高并发接入。

— 支持按照管理粒度提供网络区域间的物理或逻辑隔离的功能。

银行金融容器云平台建设方案中的云数据中心网络，当前主流都是采用了商用市场普通盒式交换机搭建胖树CLOS网络，实现可扩展、不依赖特定厂商产品的网络架构。 CLOS架构基于动态路由、信元自路由技术、分布式调度等技术，可以做到严格的无阻塞（Non-blocking）、可重构（Re-arrangeable）、可扩展（Scalable），相比传统的CrossBar架构在突发流量处理、东西流量高速处理、拥塞避免、递归扩展上均有巨大的提升。（注：在1953年，贝尔实验室Charles Clos博士在《无阻塞交换网络研究》论文中提出这种架构，后被广泛应用于TDM网络（多半是程控交换机），为纪念这一重大成果，便以他的名字CLOS命名这一架构）。

一个典型的C LOS 网络架构如下图所示：

说明：采用端口数为k的交换机时，核心交换机数量为(k/2)2个，共有k个Pod，每个Pod各有(k/2)个汇聚和接入交换机，可接入的服务器数量为k3/4。并且此架构可以保证接入、汇聚、核心的总带宽一致，保证服务器接入带宽1:1的超载比。当前主流演进到服务器网卡为25GB、TOR交换机为100GB、Spine交换机为400 GB。
其他设备
银行金融容器云平台的建设还需要安装防火墙、支持国密算法的硬件加密机等其他设备。
资源池管理
金融容器云平台的资源池管理负责容器运行所需的计算、存储资源的申请、分配、容量管理，以及适合的网络通信方案。从技术成熟度、产品稳定性和生态上，银行通常会选择V Mware Cloud Foundation （简称VCF）作为资源池管理的平台。VCF是VMWARE 全新统一软件定义的数据中心(SDDC) 平台，通过 VMware SDDC Manager™ 的自动化和生命周期管理功能将 VMware vSphere®（计算）、vSAN™（存储）和 NSX®（网络）虚拟化融合到一个原生集成体系，如下图所示：
容器平台
金融容器云平台主要承载了分布式中间件、分布式数据库等关键业务，同时也需要融合了开发和运维以提升业务的敏捷度。另外，整个容器云平台也需要做到可视化、可量化和可优化等要求。

为了应对容器云对运维能力、平台安全性和组织技能等提出的挑战，从技术成熟度、产品稳定性和生态上，银行通常会选择 Redhat 公司的 Openshift 产品作为容器平台的底座，如下图所示：

五、基础设施方案设计

银行建设好金融容器云平台后，就将全面推动业务系统上云。在此背景下，鉴于上云规模不断扩大，以及不同业务系统的工作负载特性不同，对金融容器云平台的基础设施算力、存储、网络和安全需求也不一样，譬如面向互联网客户的手机银行、网上银行，在极端严苛的业务压力下也须始终保持顺畅的产品服务体验，这要求基础设施提供并发处理高的算力、低时延的网络和内存加速的高IO读写支持。而大数据处理和AI人工智能的业务场景，要求基础设施提供高带宽网络、批处理调度和大容量低成本的存储支持。

受传统架构设计理念约束和技术限制等因素，在以前的技术实施方案中，针对某种类型的工作负载，是垂直性地单独建设一套的基础设施和相应的管控平台。譬如大数据和AI人工智能类的负载，是使用物理机部署方式建立集群和管控。此建设模式的益处是有强的业务隔离性、故障域爆炸半径小、分区运维边界清晰，但是缺点也很明显，表现为基础设施技术栈没有归一化，资源池小且割裂，造成运维成本高，不支持全局性资源调度和不同工作负载的混部调度，整体的资源使用率较低，从而成本高，不可持续发展。

为此，银行建设金融容器云平台的落地实施，其中对基础设施的设计，参考了公有云厂商的建设和运营经验，要遵徇技术栈的归一化、资源池的规模化、资源调度的全局化、不同工作负载的混部化的规划原则。

在基础设施领域技术发展中，早期传统的数据中心架构都是以CPU为主，并且通过传统的网卡与数据中心网络相连接。单台服务器里除了CPU，还会挂载硬盘、SSD之类的存储设备。随着数据中心规模的不断扩展，网络速度不断提升，从 2015年前的10GbE，逐渐发展到2x25GbE、2x50GbE，再到目前正在发展中的2x100GbE。除了网络之外，计算和存储的应用也在变得越来越复杂，譬如虚拟交换 OvS、Virtio虚拟IO协议，还有RDMA、NVMe传输层和存储协议等等，都正在渐渐成为数据中心的主流技术，也构成了当前数据中心的主要基础设施架构。这些技术是使用软件+CPU的方式来执行其功能或服务，存在一些典型的如性能和经济性的问题。

我们跟踪关注到当前英特尔演进到混合计算架构，从制程、连接、内存、软件、架构等五个维度推进提升算力，具体包括：从传统CPU的Scalar张量计算引擎，演进到AI所需要的Matrix矩阵计算引擎以及更多计算类型所需要的Vector向量计算引擎和Spatial空间架构计算引擎等，形成了异构计算引擎架构。英特尔搭配不同的制程、封装技术，以及针对不同的计算工作负载搭配合适的缓存、内存以及连接，在混合架构下发布了多种不同类型的计算产品。把单个计算核拼接在一起形成多核CPU时，每个计算核可以承担不同的功能。另外，跟上基础设施软硬一体化的发展趋势，英特尔也发布IPU（基础设施处理器），将基础设施功能都转移到IPU上，从而释放CPU的最大算力，用于帮助企业客户或云服务商降低成本、提高CPU性能。

英特尔的混合计算架构，是高性能CPU+高性能硬件加速单元的组合，代表了当前云数据中心的主要架构思路。英特尔面向数据中心的下一代至强新产品，将演进为 Sapphire Rapids 微架构，此架构升级改进了芯片的封装工艺、计算存储互联技术，即采用多芯片封装的结构，使用EMIB技术进行互联和通信，可以大幅提升系统的可扩展性，如内核数量、IO、缓存和存储单元的容量。另外， Sapphire Rapids里封装的每个计算单元，都采用了模块化的设计方法，分别是计算、IO和存储模块，比如计算模块可以为性能核，以及针对数据中心的硬件加速引擎；IO模块包含对于多种互联协议的支持，如PCIe 5.0、UPI 2.0、以及缓存一致性标准CXL1.1；存储模块可包含HBM、英特尔® 傲腾™ 持久内存（Intel® Optane™ Persistent Memory）、DDR5 。

同时，VMware的软件定义数据中心（SDDC）产品VCF，全面支持了英特尔的产品。 VMware VCF通过结合第三代英特尔®至强®可扩展处理器提供强算力、英特尔® 傲腾™ 持久内存（Intel® Optane™ Persistent Memory）和英特尔® 3D NAND技术的固态盘的高速缓存、以太网融合网卡提供稳定的网络带宽和低网络延迟等最新硬件技术，提供出计算、存储、网络资源，能够承载为银行金融容器云平台所需要的稳定可靠的基础设施。

VMware vSphere 充当 VCF 中的计算组件，依赖于 CPU和内存资源来执行工作负载，而工作负载往往也对CPU和内存提出进一步的需求来满足业务需求。随着处理器升级换代，其核心数量往往也大幅增长，使得单个主机上支持更多的虚拟机，进一步随着虚拟机的增多，又会导致每个服务器的内存需求增加。同时，随着各种业务的演进，大量常用应用对内存的需求也在不断增加，同时越来越多内存密集型工作负载在企业中也在显著增加。采用英特尔® 傲腾™ 持久内存（Intel® Optane™ Persistent Memory），会是一种有效的解决方案来满足那些需要1TB 或更多内存需求的工作负载。

在构建VCF等平台时，正确的架构是关键，因为整体设计对性能、效率和总拥有成本的影响是巨大的。

VMARE VCF对英特尔的产品支持的典型样例如下图所示：

其中，VMWARE VCF 产品是于2019/4 开始支持英特尔® 傲腾™ 持久内存（Intel® Optane™ Persistent Memory）。 vSphere 中的虚机可以通过两种方法来使用：
lvPMEMDisk (Virtual Persistent Memory Disk)：内存被映射成为一块虚拟硬盘提供给虚机使用，这种模式下虚机里的操作系统和应用都不需要知道非易失性内存，传统的操作系统和应用都可以正常使用这种模式。
lvPMEM (Virtual Persistent Memory)：内存被映射成为虚机中的非易失性内存 (NVDIMM)，这种情况下要求虚机中的操作系统能够支持 NVDIMM (例如 Windows Server 2016 和 RHEL 7.4)，然后把它映射成为存储设备提供给上层应用；如果是 PMEM-aware 应用的话，也可以在虚机里直接访问 vPMEM。

VMWARE VCF产品对Kubernetes CSI、Kubernetes CNI的支持，银行金融容器云平台获得了基础设施层面的稳定、可靠和高性能的计算、存储、网络资源，并且能够创新地构建基于英特尔® 傲腾™ 持久内存（Intel® Optane™ Persistent Memory）技术的Redis 集群、内存数据库等新服务。VCF对Kubernetes CSI、Kubernetes CNI的支持，如下图所示：

银行金融容器云平台使用OpenShift OCP产品负责容器工作负载的调度，其宿主机节点是由VMware VCF的虚拟机创建的，通过在宿主机上打标签，银行金融容器云平台获得了归一化的基础设施资源，一个典型的O penShift OCP宿主机节点如下图所示：

六、新基础设施的收益

银行金融容器云平台启用基于VMware VCF+第三代英特尔® 至强® 可扩展平台的新基础设施，一方面获得了稳定可靠的计算、存储、网络资源池，能够聚焦在云服务、业务应用层进行创新; 另一方面，也达成了基础设施技术栈的归一化、资源池的规模化、资源调度的全局化、不同工作负载的混部化的规划目标。上云2年多，已经承载了 300 多个业务应用系统，规模超过 20 多万个容器实例。

另外，在银行金融容器云平台也实施了若干创新，譬如：用英特尔® 傲腾™ 持久内存（Intel® Optane™ Persistent Memory）取代普通的DDR 内存，在Redis 集群性能几乎没有损失的前提下，大幅降低TCO 采购成本。另外，使用了阿里云容器服务团队和蚂蚁金服安全计算团队针对英特尔® 软件防护扩展 (SGX ) 联合开发的sgx-device-plugin （基于 Kubernetes Device Plugin 规范），对Open Shift OCP 宿主机节点打标签，在应用部署模板里指定nodeSelector或者亲和性的方式，实现在OpenShift OCP集群应用 S GX提供的隐私计算的能力，无需开启容器特权模式即可使用SGX，并支持自动获取EPC内存大小以及支持容器声明式EPC内存分配 ,能够为业务应用系统提供加解密的支持。