金融行业容器平台建设方案

导读

导读

1 背景概述

未来五年的核心任务之一在于科技兴国战略的实施；科技兴国被视为推动社会发展的重要引擎；同时这也是实现国家高质量发展战略的关键保障措施；各类型企业都在面临新兴商业模式的竞争压力；传统的同质化竞争策略在激烈的市场竞争中难以发挥作用；涵盖银行证券公司等金融行业及政府部门等机构的传统企业纷纷开始加快数字化转型的步伐；而在数字经济时代数据高速公路则构成数字世界的基础设施；此外科技兴国必须建立在其成功实施的前提条件上

数字经济发展过程中金融行业面临着数字化转型的关键挑战。基于容器云原生技术构建数字经济的核心支撑体系，在保障金融机构数据安全合规的同时，能够快速整合大数据、人工智能算法以及数据库资源，并通过这一综合解决方案满足"安全可靠"+"应用创新"的双重战略需求。该方案不仅能够通过 container-native 上的数据治理能力实现数据全生命周期管理与价值挖掘的能力提升，并且能够通过 container-native 上的人工智能开发平台持续优化算法模型，并构建知识图谱以储备人才及探索前沿科技方向；此外还可以通过 container-native 上的应用管理能力落地智能化金融应用系统的同时提升开发生产效率水平。建议各金融机构结合自身实际情况积极布局混合云战略，在现有公有云基础之上引入行业领先的云服务解决方案，并推动金融机构灵活应用容器云原生技术实现创新升级

2. 现状及分析

银行的业务应用目前广泛采用多种形式运行于现有技术架构中，并非单一类型的技术架构能够满足其需求。已有部分系统实现了新一代平台的升级，在这一过程中体现出较高的可扩展性特点。然而，在 container 技术快速发展的背景下许多传统金融机构开始探索分布式架构转型这一新方向。

由于银行交易具有重要意义，在选择云原生容器化系统时应优先考虑哪些最适配的系统？而经过改造后如何与现有规范兼容等问题也随之显现。

对于尚未或较少接触容器技术的研发团队而言，在面对新技术时会遇到学习成本较高以及改造难度较大的问题；

2.互联网技术栈产品直接进入不符合银行的高可用及安全要求等；

3.容器改造期间可能涉及到除容器以外的其他平台或云产品；

4.开发测试环节中生成的制品、编排文件需要经过安全审核再投产；

5.测试资源申请面临不同云平台产品的统一供给问题；

6.运维部门需要在现有运维框架下如何更快上手，并减少运维难度问题。

基于互联网+金融以及自主可控两大趋势的推动下，在中国金融IT领域发生了一场具有里程碑意义的转型运动。传统IT流程、基础设施以及运维模式已难以适应业务发展需求及行业格局的变化，在这一背景下，传统金融机构正就未来IT开发模式及架构优化方向进行探索与规划。

2.1 IT 研发转型

IT 研发转型-如何快速响应用户需求？

互联网思维的核心要素在于快速响应，在激烈的市场竞争环境下，若无法实现对用户需求的快速响应，则难以在行业竞争中获得优势地位。随着互联网技术与传统行业的深度融合，在推动"互联网+"战略实施的过程中，金融行业的信息化建设核心在于构建一个能够及时响应业务需求并适应多变商业环境的灵活高效的IT架构体系，以满足各层级部门、客户及合作伙伴的需求多样化需求。尽管如此，在推动应用交付效率与产品迭代速度方面取得显著成果的同时，传统的研发管理模式已无法满足当前应用交付效率与产品迭代速度的需求，并且IT研发流程仍需进行相应的优化升级。

2.2 IT 架构转型

IT 架构转型-烟囱式架构如何向分布式架构无痛转型？

在IT基础架构层面分析发现,许多采用IT基础架构的企业,尤其是金融行业,多采用烟囱式架构模式,这种模式的主要问题在于其体系间缺乏互联互通,导致各系统间的资源难以实现共享协作。伴随互联网+战略的深入推进,传统金融IT架构体系面临新的挑战:现有的传统金融IT架构体系难以满足新增大量长尾客户需求的需求,尤其是在普惠型金融市场快速发展的背景下,现有体系已明显暴露出不足。

鉴于此，在IT系统中推行云计算势在必行。大多数金融机构已认识到从烟囱式到分布式架构转型的必要性。然而目前多数架构转型方案都需要经受阵痛考验。他们对云化IT基础设施退缩不前？他们亟需一套可实现无阻碍、逐步向云计算迁移的方法

2.3 IT 运维转型

IT 运维转型-高复杂环境下如何确保系统的高可用性？

广泛了解的事实表明：金融IT运维团队面临的压力是众所周知的这一现象。
这种状况源自金融行业对业务连续性和可用性的严格标准。
随着金融业信息化的发展趋势日益明显，在线支付、移动 banking等新兴技术加速普及，
使得IT环境趋于日益复杂：一方面种类繁多且功能各异的应用系统不断涌现，
另一方面架构分散且不统一的IT架构方案并存，
再加上规模不断扩大带来的系统管理需求，
这些因素共同导致运维难度不断提升，
迫使其寻找创新思维以有效应对复杂环境下 IT 系统运维的压力。

2.4 IT 组织转型

IT 组织转型-如何平衡唯快不破和安全第一

互联网企业的业务拓展与产品研发强调的是快速响应。从交付速度到快速迭代再到几乎实时的用户体验，则是企业所追求的核心目标；在组织架构设计上，则会充分考虑这些特征所带来的影响——包括研发管理、审批流程权力配置安排等方面的具体表现。金融机构始终将安全置于首位，在这种背景下如何实现既保持快速发展的前提下又实现风险可控？这不仅是一个需要深入思考的问题更是一个对管理层提出的具体挑战。

3 建设方案

3.1 容器平台建设

在金融行业中，容器技术的应用场景极为广泛。无论是开发测试环境还是生产环境，在金融行业中都可采用容器技术。基于 Docker 等先进容器技术的应用，在金融 IT 领域及业务转型方面已展现出革命性的影响。

针对容器技术的应用场景分析，
特别适合使用容器技术的应用涉及多种类型：
频繁更新且易于快速迭代的应用，
能够在云端高效运行的应用，
而不仅仅是在DevOps和微服务方面受益的应用。
以下列举了采用 Docker 容器技术适用的几种典型场景：
首先是CI/CD持续交付体系优化，
其次是大规模集群管理效率提升，
接着是混合云环境下的资源优化配置，
此外还包括数据分析领域的模型部署优化，
还有微服务架构下系统解耦带来的性能提升，
最后是基于Cloud Native Application理念的设计实践。

3.1.1 容器可编排性

容器云平台的技术架构设计应遵循云计算原生技术的发展趋势，并能够支撑分布式应用的发展需求。在选择容器管理与 orchestration 工具时需特别注重其功能定位与适用场景匹配性优化。其中初级阶段的应用集中在资源调度层面即针对物理机与虚拟机进行自动化管理与配置；而高级阶段则需进行服务层面的应用规划以实现系统整体功能模块的有效整合与协调运作。

Docker 技术主要针对单一应用进行优化设计。在真实云环境中,工程师面临的挑战是构建由多种类型的应用组成的综合系统,并为此部署成数百上千的具体实例.处理这类规模的工作完全依赖于人工操作会产生巨大困难,并且伴随着高昂的成本与潜在的风险.为了高效管理大量容器的生命周期状态,则必须采用专门针对容器运行时进行编排的技术.Kubernetes 现在已经成为事实上的行业标准工具,在原生技术支持下它被广泛采用.

Kubernetes这个由来自古希腊的名字被称为'舵手'。若将Docker比喻为穿梭于海洋中的集装箱运输巨兽，则Kubernetes便如同指引大航海时代方向的核心船长，在其设定的道路上传唤前行。

Kubernetes 是Google开源的容器集群管理系统，
源自Google 多年积累的大规模容器管理技术Borg，
并授权给云原生计算基金会（CNCF）。
其主要功能如下：
支持的操作平台包括但不限于Linux、Windows以及macOS等操作系统；
提供资源调度方案；
具备自动化的容器编排能力；
包含丰富的工具集用于自动化运维；
同时具备良好的扩展性设计。

基于容器的应用部署、维护和滚动升级；

负载均衡和服务发现；

跨机器和跨地区的集群调度；

容器负载自动伸缩；

无状态服务和有状态服务；

开放 API 以获得扩展性支持。

图-Kubernetes 定义容器状态的机制

如图所示, Kubernetes采用了基于YAML标准配置语言来定义 Kubernetes 内部支持的所有资源类型, 涵盖例如Pod（容器）、Deployment（部署）、Service（服务）等多种资源类型. 它们作为基础调度单元, 共享网络与存储系统的基本特性, 并在外围提供每项应用程序所需的相应服务能力; 同时在内部接受 Kubernetes 对其生命周期与接口能力进行统一管理.

通过这样的机制，Kubernetes 可以为应用提供以下解决方案：

该系统成功应对了大规模应用运维所面临的挑战，并通过自动化手段实现海量应用的规划、编排以及全生命周期的有效管理；

采用简洁明了的形式语言（YAML）清晰描绘了系统的架构和生命历程。该方法成功弥补了Dockerfile在刻画外部环境方面的局限性，并拓展了'基于代码生成服务'的整体概念。

采用实时弹性扩展现有应用,无需经历申请资源并安装操作系统及部署现有应用等繁琐步骤,轻松应对峰值流量,充分释放Docker框架的高度可扩展性和高性能特性

通过流量切分及发布策略的协同作用, 促进持续交付目标的达成, 将精益管理理念与现有流程有机整合, 助力DevOps实践在企业中的成功落地

开放性接口旨在提供多样化的外部网络与存储系统支持能力，并为企业用户提供必要的技术基础以保障运营效率

构建基础的抽象环境，并遵循统一镜像规范和统一编排标准进行部署；即使是大规模应用也无需担心会被受限于厂商生态。

在功能支撑之外，在企业生产级平台选型过程中，则需要着重考量编排引擎作为调度核心能力的技术实现方案，并需考量其未来长期发展的扩展潜力是否足以应对企业的业务增长要求。其中，在Kubernetes单一集群中最多可容纳5,000个节点进行部署，并能同时支持15,067个容器组以及3万多个容器的数量配置；此外，在多集群扩展的支持下，则能充分满足企业的长期发展需求

Kubernetes本身提供了基于一组容器定义的对象Pod的运维能力、弹性调整能力以及调度控制的能力，并且还具备服务访问的支持。它通过接口驱动的方式为所有会根据环境特性进行差异化配置的外围服务提供了支持。如图所示：

图-Kubernetes 的 Interface 设计模式

针对一些特殊的场景，在现有内置资源对象（如存储类型等）无法满足企业需求的情况下

图-CRD 原理

基于这一设计框架，在面对各种容器运行时生态、网络协议以及存储方案等多样的资源实现需求时（包括特殊的资源形态），Kubernetes系统均可通过扩展相应的驱动程序来实现兼容性保障，并不需要对核心功能进行任何改动。这表明 Kubernetes 的兼容性主要依赖于其抽象层的设计理念——即通过操作驱动程序而非具体的资源实体本身来实现兼容效果，并非直接操作某个特定资源实体本身——这种设计理念具有极强的通用性和灵活性。基于这一设计理念构建的系统架构，则能够自然而然地具备良好的兼容性能；从原理上讲，在遵循一致的接口规范的前提下（即下游的各种部署均采用一致的兼容接口），即使各类部署均具备对Kubernetes服务的一致性扩展能力（如一致性的API支持），系统也能保证良好的可扩展性和互操作性表现。

Kubernetes 已经被广泛认可为容器管理的事实标准，在全球范围内绝大多数企业将其用作容器管理和编排方案的基础架构。该方法的主要优势体现在以下几个方面：

开源的力量

随着容器应用领域不断扩大，在 container 技术方面已逐渐发展为行业通行做法。由于这一技术的重要性，在组织的 IT 基础架构中实施它时可充分信任其可靠性和稳定性；遇到任何问题时, Kubernetes 开发者的开放社区能够解决相关问题. 但值得注意的是, Kubernetes 并不是一个只开发一次就停止更新的技术,而是一个每年有四个主要版本持续更新的持续发展的项目.

成本效益

在资源消耗方面具有极低的要求，并且相较于虚拟机（VM）而言，在配置难度上也有显著的优势。这使得Kubernetes成为一种高度灵活的应用程序容器管理平台。通过优化配置能够显著减少CPU周期并有效降低内存占用（以GB计），从而进一步提升系统的响应速度与整体性能表现。此外 thanks to its load balancing engine, Kubernetes is capable of starting, stopping, and prioritizing containers as needed without compromising system performance.

可移植性

基于其多样的功能特性，在多个底层操作系统环境中本地部署和运行Kubernetes服务是完全可行的方案。此外，在整个应用部署生命周期中选择迁移到备用的操作系统环境时，请确保现有工作负载能够轻松迁移而不必进行任何应用程序重设计或废品再构建即可无缝整合到新的架构中。通过这种机制,Kubernetes不仅能够有效避免对供应商的锁定问题,而且还能使整体应用设置更加标准化,随着时间的发展,维护成本也会逐步降低

可扩展性

Kubernetes 作为模块化容器管理工具（CM）的架构师设计目标得以实现，
通过灵活组合组件实现模块化部署。
使用Kubernetes您可以自定义运行环境配置，
包括操作系统选择、应用运行时（Libs / Bins）、存储方案、硬件架构以及云端服务。
开发人员可以直接访问Kubernetes API（应用程序编程接口）
并通过其丰富功能提升应用性能与可管理性。

自愈

软件有时会遇到奇怪的故障，并导致功能失效以及系统崩溃。然而这些陷阱终将令您陷入可靠性困境中无法自拔但请不要担心：Kubernetes 持续监控您的全面基础设施包括容器节点Pod网络硬件以及操作系统以确保服务稳定运行。当软件出现错误时会导致某些组件崩溃而 Kubernetes 会迅速恢复服务状态并将其负载分散至剩余健康组件以防止服务中断仅在必要时才进行重新配置从而最大限度地减少停机时间。

云服务

由于Kubernetes备受欢迎，在乎无需用户自行处理内部实现细节的同时也不必在硬件资源投入上大手笔支出。实际上，在线注册并使用托管的Kubernetes解决方案即可实现流程外包：无论是平台即服务（PaaS）还是基础架构即服务（IaaS）。用户的职责则是专注于提升自身应用用户体验的同时将负载均衡与云服务管理委托给Kubernetes系统负责。

基于以上分析，在容器化管理与编排技术建议方面进行优化优化方案时

容器平台支持应用可视化的编排与部署相关管理功能。该平台涵盖拓扑结构展示（拓扑可视化）、组件组成视图（组件可视化）以及配置参数设置（配置可视化）等功能。在此基础上，在此基础上，在此基础上，在此基础上，在此基础上，在此基础上，在此基础上，在此基础上，在基础上的基础上，在基础上的基础上，在基础上的基础上在基础上的基础上在基础上的基础上在 basis上 basis上 basis上 basis上 basis上 basis上 basis上 basis上basis上basis上basis上basis上basis上basis上basis上

用于实现应用模板的创建与认证。此外容器平台提供了大量应用于实现这一目标的功能模块。这些功能模块包括但不限于模块的新建、删除以及编辑等基本操作；同时 container platform 还提供了许多辅助功能模块例如批量导入多个 module 模板增加或修改 template variables 以及详细说明了各模块之间的关联关系；此外 container platform 还提供了从模版到实际部署的应用指导流程；最后 container platform 还提供了对 module 模板进行分类管理和搜索的强大功能

在应用编排管理方面：该平台提供了较为全面的功能。不仅支持与数据库以及F5等周边系统进行混合部署，此外还具备更为完善的管理能力。例如兼容Kubernetes YAML配置文件、提供可视化展示界面，并可同时配置基础设施资源。在配置阶段可指定日志管理和调度机制，在操作层面则提供图形界面进行配置与维护。

应用配置管理:容器平台可以为应用配置设置日志记录、 端口信息等配置信息。

容器平台支持用户基于应用系统的维度进行查询与管理操作，在线获取关于应用中各类型关键组件的详细参数配置数据。该平台还能够根据企业级用户的实际需求，在原有基础功能基础上提供更为全面的辅助查询服务功能模块。
包括多层次的镜像管理数据展示、完整的历史修改记录查询接口以及实时监控的各项运行参数数据等在内的多维度业务功能模块。

容器操作功能位于编排功能模块中，并涵盖了应用容器的基本操作功能包。该平台不仅支持基础操作如启动（Startup）、停止（Stop）、创建（Launch）、删除（Delete）等基本操作，并且还提供了更为丰富的高级功能包。这些高级功能包括通过简单的拖放或点击选择文件夹进行批量下载文件（Download Files），通过右键点击选择本地目录进行快速上传文件到云存储空间（Upload to Cloud Storage），使用内置的Web界面实现实例化配置并运行Shell终端命令（Launch Shell Terminal），利用预配置模板一键生成新的镜像文件并重启实例（Generate Mirror Image and Reboot Instance），以及支持手动暂停或自动悬停实例以调整资源分配策略而不影响现有服务运行状态（Pause Instance or Automatically Scale Resources Without Impacting Current Services）

负载均衡展示功能:该容器平台内置了负载均衡功能，并不仅能够呈现整个应用的负载分布情况，还具备对资源进行智能调度的能力。此外,该平台还可以与诸如F5等外部的负载均衡设备或系统进行集成连接,并且支持在应用层面实现资源的动态分配策略以适应微服务架构的需求。

该平台采用Linux内核中的LVS技术实现服务到容器的自动负载分发功能；相较于其他软件平台在性能上具有优势，并支持配置SSL证书；能够实时感知并适应后端服务的变化，并能灵活适配；该平台支持多种不同的负载均衡策略，并可通过环境变量进行参数设置；此外该系统具备会话持久化的功能。

版本管理/灰度发布:针对企业级应用的版本升级场景,容器平台在应用 versions 的更新过程中对各个集群实施灰度升级,确保业务在升级期间持续稳定运行。此外,在基础功能之上,容器平台还提供了更为高级别的灰度发布配置选项,例如设定并行发布的实例数量、配置失败后的错误处理机制以及实现旧 versions 实例在优雅退出时的状态管理。

3.1.1.1 多模式应用编排

3.1.1.1.1 应用容器编排

该系统具备应用 visualize 编排部署的相关管理功能。其中包含拓扑 visualize 优化方案以及组件 visualize 方案的核心模块，在现有基础上提供了一系列 F5 设备（F5 装置）、数据库资源以及 DNS 服务器等常见 platform components 和 services 的封装。在现有基础上提供了一系列 F5 设备（F5 装置）、数据库资源以及 DNS 服务器等常见 platform components 和 services 的封装，并实现了对 component 配置 manage 和 visual 化 arrange 积分式的集成 manage 功能。该系统提供的编排 functionality 包括：

该系统具备完整的模版管理功能。不仅支持模版的基本操作如新增删改等基础功能还提供了诸多高级功能如批量导入模版以及模块变量的增删改等实用特性。系统不仅能够直观展示并更新模版的信息内容还能清晰展现各模块与其关联的应用之间的关系便于用户进行深入分析。此外系统还提供了详细的模版使用指导帮助用户顺利完成从模版到实际应用场景的有效过渡同时实现了对公有私有模版的有效验证并能够根据需求设定访问权限确保系统的安全性和灵活性。

应用编排功能：该系统具备较为全面的应用编排功能。除了能够与数据库及F5等周边系统实现混合编排外，并且还实现了更为完善的管控行为。例如：该系统支持Kubernetes YAML格式的编码规范，并提供可视化界面进行配置；同时实现了对基础设施资源的配置管理；另外还具备根据需求设定日志管理和调度安排的设置，并提供可视化界面进行配置调整。

应用配置管理:云原生技术平台管理系统为应用安排相应的应用程序日志与应用端口等配置信息

容器信息查询

container 操作功能位于编排功能模块中，在该系统中实现了基础的 container 操作功能集合。系统内置了启动 container 运行其程序与停止 container 关闭其服务的基本能力，并支持创建新的 container 以及删除现有 container 的高级管理能力。此外该平台还配备了一个更为完善的 container 管理功能模块它不仅包含了从 container 内部下载和上传文件的能力还支持通过 shell 控制台对内部进行交互能够一键生成新的镜像并具备自动重启停机及恢复等功能同时确保原有业务服务不受影响地继续运行。

负载均衡展示功能：该系统不仅具备内置的负载均衡功能，并且能够全面监控整个应用的运行状态；同时支持与F5等外部设备兼容，并且具备按应用划分的精细粒度的负载均衡能力。

服务部署到容器实现自动负载均衡：云原生技术平台管理系统默认主要依靠Linux内核中的LVS（Load Virtual Switch）技术实现资源调度，在性能上相较于其他软件解决方案具有优势，并支持设置SSL证书；随着服务容器规模的增长，在后端服务变化时能够自动感知并进行适配；该系统提供了多样化的负载分配策略，并可通过特定环境变量进行参数化配置；在会话持久性能力方面表现突出

面向企业级发布场景的应用，云原生技术平台管理系统能够对各集群实施灰度升级以完成应用版本更新，并确保业务服务的持续运行；此外还提供了更为高级别的灰度发布配置选项包括配置并行发布的实例数量建立失败后错误处理机制以及提供优雅下线策略以处理旧版本实例

3.1.1.1.2 应用混合编排

在现有应用开发流程中，在提高研发效率的部分部门会预先配置数据库服务用于研发测试。根据研发业务的不同情况而言，在线的数据库服务种类主要包括 Oracle 服 务、MSSQL 服务以及 DB2 服务。

伴随着业务规模的扩大，随之呈现出多元化发展的趋势的研究开发生产线路也为之提供了更为丰富的选择空间，并为研究开发测试部门提供了越来越大的压力。当前环境下，研究开发测试面临着申请研究开发所需数据库的服务流程时间较长的挑战，并且必须承担为各条产品研发线提供相应数据库服务的压力日益加大的责任。

该平台采用的数据库混合编排方案遵循了公共云数据库服务的技术架构，在经过大量实际应用场景的验证后逐步完善。该平台采用的数据库混合编排方案在可扩展性、一致性和高效性等方面具有显著优势：一是实现了对多种数据类型的有效支持；二是通过统一接口保证了操作的一致性；三是通过异构环境下的优化提升了处理效率

在完成相关数据库设置后，请访问 WEB 界面并登录到 服务器管理模块完成数据库接入的注册流程。根据所需功能的不同需求，请选择相应的 Oracle 数据库 服 务、MSSQL 数据 库服 务或 DB2 数据 库服 务等进行接入设置。

经Web页面处理即可对已注册的数据库service进行管理, 管理操作包括:新增database service配置, 移除现有database service配置, 更新现有database service配置, 移除指定的database service配置。

在应用页面上实现数据库服务与容器之间的绑定，在此过程中会将相关数据配置存储至应用程序环境变量中；通过服务绑定功能将相关数据配置存储至应用程序环境变量中；以便于应用程序访问这些预先设置的信息

服务定位:该方案基于客户端进行服务定位的过程,"数据库服务定位平台"提供了RESTful API接口,并可返回结构化的配置数据给客户端系统使用。

云原生技术平台管理系统的混合编排方案架构图如下所示:

图-混合编排架构图

cloud-native platform-based management system integrates its database resource pool through a unified scheduling service. The "database service orchestration application" is deployed as an extensible application plugin on the cloud-native platform-based management system. This application will implement specific permissions for database service access by integrating with the user permission control module of the cloud-native platform-based management system. Through a permission management mechanism based on API authorization, specific users can be granted access to particular database service resources. The "database service discovery application" will establish connections with the user permission control module of the cloud-native platform-based management system, thereby simplifying the process of user permission configuration.

3.1.1.2 负载均衡

该系统提供两种类型的负载均衡策略：第七层轮询策略与第四层轮询策略；建议根据不同业务场景采用相应的负载均衡配置策略。云原生技术平台管理系统负载均衡方案整体架构图如下所示

图-负载均衡

3.1.1.2.1 内置 4 层负载均衡解决方案

该系统的核心设计目标是实现资源按需弹性伸缩，在此基础上构建了一个基于IPVS的负载均衡方案。该方案通过端口转发机制将外部请求均匀分配到多台容器中以提升系统吞吐量。具体应用场景可通过下图进行直观展示

基于该场景需求，该云原生物entially平台管理系统已集成了一款基于IPVS的负载均衡管理方案。

LVS 是一个高性能的负载均衡，并能够支持自动的服务发现功能。

云原生技术平台管理系统的 4 层负载均衡解决方案架构图如下所示:

使用 IPVS 作为负载均衡解决方案的优势:

Docker 内置机制

基于内核 LVS 技术，高效转发高性能请求转发

高可用架构(如果云原生技术平台管理系统有多个节点)

自动适配后端应用变化

自动检测后端状态，并实现容错

热更新，无中断的配置更新

3.1.1.2.2 内置 7 层负载均衡解决方案

云原生技术平台管理系统内嵌了IPVS功能，并提供了包括Nginx、HAProxy以及Traefik等在内的7层负载均衡组件。这些组件能够自动获取集群内各服务对应的域名配置信息（目前主要通过服务标签实现此功能），并根据动态变化的情况自动生成并更新负载均衡转发策略。

下图表示以 Traefik 为例的解决方案整体架构图:

使用七层负载均衡解决方案的优势:

友好的图形界面管理能力

支持用户/租户级别的 LB，适应微服务场景

高性能请求转发

高可用架构(如果云原生技术平台管理系统有多个控制器)

自动适配后端应用变化

优雅的中断 HTTP 连接

自动后端健康检查，并实现容错

热更新，无中断的配置更新

提供简单的性能监控报表

HTTP2 支持

Websocket 支持

HTTPS/SSL 支持

3.1.1.3 存储管理

3.1.1.3.1 数据持久化

运行中的容器产生的数据无法保留在"write-only"镜像中。重新启动该镜像会导致新容器初始化并引入额外的读写操作以存储数据。要实现持久化存储，则必须依赖其他方法来完成这一目标。

云原生技术平台管理系统利用存储卷（volume）实现对Docker容器数据的永久性保存。存储卷包括本地卷、远程卷以及快照三类：本地卷对应于本机磁盘空间；远程卷及快照必须在集成中心配置并完成与第三方存储服务（如ScaleIO）的集成才能使用。

本地存储卷: 不设容量及读写性能限制（其最大容量由磁盘规格与性能决定）。无法生成快照。在构建应用过程中，则可通过 Compose YAML 的方式进行配置。

远端文件系统：远端文件系统的搭建及使用方式与本地文件系统具有相似之处。云原生物体管理平台中的远端文件系统主要包括基于NFS协议的远端文件服务器以及其它远端文件系统类型。对于配置NFS远端文件服务器而言，在硬件选择上需考虑IP地址分配、读取权限设置以及目录路径配置等多个关键参数。而其他类型的远端文件系统则通常基于REXRAY驱动或者采用VMDK虚拟化技术实现。

3.1.1.3.2 数据持久化保护与恢复

云原生技术平台管理系统通过存储卷创建快照来保护数据。例如，在ScaleIO中访问其详情页面即可看到该系统提供的创建快照按钮：

点击创建快照，填入快照名称，点击创建快照。

云原生技术平台管理系统支持了UI界面用于快速生成和管理数据备份。访问快照详情页面后，请选择需要备份的数据并完成备份操作。

3.1.1.4 网络方案

该系统全面兼容Kubernetes多种网络架构设置。满足CNM模型要求的网络插件均可通过该系统实现容器间通信管理。该系统内置支持Flannel和Calico等技术，并可通过扩展插件支持Macvlan网络类型。

下图为基于云原生技术平台管理系统的网络方案整体架构图:

3.1.1.4.1 Calico

Calico 是一种三层架构的数据中心网络方案（无需额外的Overlay网络），并且支持与OpenStack、Kubernetes、AWS、GCE 等IaaS平台以及容器平台的良好集成。在每一个计算节点上，通过LinuxKernel实现了高效的vRouter来负责数据转发的任务，并且每个vRouter会使用BGP协议将自己的运行中的工作负载路由信息传播至整个Calico网络中——对于小规模部署的情况可以直接实现互连，在大规模部署时则可借助指定的BGP routereflector来完成通信。这样设计使得所有的工作负载之间的数据流量最终都会通过IP路由的方式实现互联。在构建Calico节点组网时可以直接利用数据中心现有的L2或L3网络结构（无需额外配置NAT、隧道或Overlay网络）。

此外，Calico 以 iptables 为基础还提供了多样且灵活的网络策略 通过各节点上的 ACLs 分别负责实现 应用间的多租户隔离 安全策略以及访问控制等功能

Calico 主要由 Felix、etcd、BGP client 以及 BGP RouteReflector 组成 ：

Felix及其CalicoAgent在其所管理的每个运行Workload的节点上执行任务，并负责配置路由及ACLs等信息以保证其连通性状态得以维持;

该系统专门管理网络元数据的一致性，并保证Calico网络状态的准确性

BGPClient(BIRD)主要承担将Felix路由信息通过Kernel发送至当前Calico网络，并保证Workloads之间的通信效率。

BGP Reflectors（BIRD）是一种广泛部署的技术，在大规模网络中采用该方案时能够有效替代传统的节点互联 mesh 模式，并采用一个或多个 BIRD 来实现集中的路由转发机制。

3.1.1.4.2 Flannel

Flannel 采用将每个宿主机划分为单独子网的方法为容器提供虚拟网络。该技术利用LinuxTUN/TAP机制实现数据传输。通过UDP封装IP包构建上层网络，并结合etcd管理网络划分情况。

管理平面上的节点本地部署Flanneld服务，在ETCD集群中同步本地网络接口地址信息及所属子网划分信息的同时完成POD网络设备IP地址分配任务。应用层通过后端（采用UDP封装）实现L3Overlay功能支持TUN设备与VxLAN技术方案。

除了 UDP，Flannel 还支持很多其他的 Backend:

udpd:在用户态打包并采用默认8285端口进行通信。打包和解包过程带来了显著的性能开销。

vxlan封装时需配置VNI、Port参数（默认值为8472）以及GBP；而host-gw采用直接路由方式，则会将容器网络内的所有路由信息直接更新至主机的路由表中。需要注意的是该方法仅适用于二层网络间实现可达性。

3.1.1.5 弹性伸缩

3.1.1.5.1 弹性伸缩策略简介

弹性伸缩（AutoScaling）旨在根据不同业务需求及策略进行动态优化其弹性计算资源配置，在最终目标上追求资源配置效率的最大化。主要采用自动化动态调节机制以支持两种主要的工作模式：自动化扩展（Auto Scaling Up）和自动化收缩（Auto Scaling Down）。这种设计使得系统能够无需人工干预即可完成对可用服务器数量的动态管理，在网络流量激增时增加可扩展性，在流量减少时则会相应地减少对系统资源的需求。这种机制既能确保系统运行的稳定性又能有效降低成本。

弹性伸缩技术在行业内主要分为两种类型：一种是垂直扩展（ScaleUp），另一种是水平扩展（ScaleOut）。从业务发展的角度来看，则应强调水平扩展的能力。这要求所有业务均处于无状态模式，并通过负载均衡机制将访问请求均匀分配至集群中的每一台服务器上。无论增加或减少服务器数量，在不影响系统稳定性的前提下都能保证服务的连续性。

3.1.1.5.2 云原生技术平台管理系统的弹性伸缩策略

云原生技术平台管理系统同时支持自动伸缩和手动伸缩两种策略。

在弹性伸缩机制方面，云原生动态伸缩系统通过内置弹性伸缩引擎实现资源动态分配能力。目前该系统支持基于资源占用情况、CPU负载指标、线程状态信息以及会话管理参数等多维度进行弹性扩缩容配置。系统的自动伸缩架构如图所示：

相较于其他平台的弹性伸缩功能, 云原生技术支持下的统一管理平台在弹性伸缩功能方面具有显著优势

容器化部署能够最大化提升部署的灵活性。弹性伸缩作为一个模块被采用，并通过应用模板的方式实现了容器化部署。能够配置不同服务的伸缩策略而不互相干扰。

伸缩策略具有高度的灵活性与可配置性。弹性伸缩与应用实现了紧密集成，在不同场景下可根据具体需求制定相应的扩展方案。云原生平台的弹性伸缩功能内置了基于容器资源（如CPU及内存使用情况）以及中间件资源（如Tomcat进程线程数量与会话数量）的动态监控机制，并支持用户在实际部署中根据需求自主配置MySQL并发控制参数以及应用程序的网络连接数量等参数。

该系统采用开放性接口设计，在满足二次开发需求的同时实现了良好的兼容性。系统完全遵循 Docker 原生 API 标准，并额外提供了丰富的一级支持接口以满足特定应用需求。该系统的核心自动伸缩功能基于云原生技术平台管理系统的API架构进行设计而来，并可灵活应对不同场景下的负载需求变化。对于希望通过深入定制实现个性化解决方案的用户来说，在此平台上构建弹性伸缩方案将能够充分发挥其灵活性与适应性优势。

伸缩资源丰富且调节灵活。该系统设计具备南北向兼容性，并支持多种扩展功能。在云原生技术平台上构建的应用架构中，默认配置了Vmware虚拟化与Openstack存储的技术组合，在虚拟化部署中实现了资源分配与网络流量的有效调度机制。

除了自动伸缩功能之外，在线服务系统还提供了便捷的手动伸缩功能。手动伸缩技术主要应用于以下场景：一是应用测试过程中需要灵活配置资源；二是无法预先设定容器阈值的情况；三是需要进行动态收缩以优化资源利用率的情形。通过访问云原生技术平台管理系统的服务页面，并根据需求选择服务扩展后的以及缩减后的容器数量即可轻松实现灵活的动态扩缩管理。

3.1.1.6 应用管理功能

3.1.1.6.1****应用生命周期管理

图形化界面从应用的开发到部署维护全生命周期进行管理，并支持一键部署选择以及基于YAML配置的编排方案等多种部署方式；该系统不仅能够完成应用启动与关闭管理以及运行状态监控功能，并且允许用户手动配置资源参数（如CPU和内存）并自定义容器镜像；此外还提供文件上传下载功能以实现数据同步，并支持对容器名称进行重命名操作的同时根据需要自动或手动更新相关镜像信息。

部署方式

支持多种 deployment 方案的平台具备快速一键 deployment 功能、基于 mirror 构建的 deployment 方案能够实现自动化管理、采用 YAML 编写的 configuration management 能够简化操作流程、平台具备基础层的 mirror 构建策略以确保稳定性

图-部署方式

应用基础功能

同时提供包括应用的启动、停止、下线、重新启动基础维护功能。

图-应用基础功能

版本更新

提供应用镜像版本更新功能，可进行新版本更新亦可进行历史版本回滚。

图-应用镜像版本更新

弹性伸缩

平台内置弹性伸缩功能，并允许用户设定特定的 CPU 和内存配置作为阈值规则。系统根据阈值动态调整实例数量：当资源超出阈值时会自动扩展实例；当资源低于阈值时会自动收缩实例。已扩展至多可用实例的标签可实现与平台负载均衡能力的无缝对接；与此同时系统还能利用拓扑关系展示当前资源在其他应用和服务中的应用情况

图-弹性伸缩配置

图-应用拓扑

3.1.1.6.2 应用资源资源

该平台配备直观的操作界面用于配置和监控应用程序资源；为新部署的应用自动分配默认配置；支持灵活优化现有运行中的应用配置包括应用实例数量、内存容量、存储空间大小以及路由设置等细节信息。

实现效果如下:

图-应用镜像版本更新

图-应用负载路由配置

图-自动配置路由信息

图-手动配置负载路由

3.1.1.6.3 应用状态查询

平台提供一种简便的方式让用户检索其发布的全部应用程序及其各自的状态信息。这些信息包括应用程序的状态信息（如正常运行或异常）、实例数量以及资源和服务的使用情况。此外，用户还可以查看应用程序的日志记录以及其中所定义的各种类型的日志输出结果。对于需要管理监控的应用程序管理员而言，在统一的标准Web界面中即可轻松访问所有应用程序的状态信息及其相关日志记录。

实现效果如下:

图-运行应用信息

图-停止应用信息

图-日志信息

图-资源使用信息

3.1.1.6.4 配置文件

平台支持通过配置文件完成对应用配置信息的统一管理，并提供基础配置文件与加密配置文件两种类型。

图-创建配置-命令

图-创建配置-上传文件

图-加密配置文件

3.1.1.6.5 镜像工厂

平台提供了镜像工厂这一功能，在其管理界面中可配置多个镜像仓库，并集成Docker注册文件库（Docker Registry）服务以保障便捷公有与私有环境下的灵活切换操作。该功能具备日常维护管理该镜像空间的能力，并允许将该镜像空间细粒度授权给个人或团队使用。根据不同需求可对不同类型的镜子空问进行相应的配置与管理；此外还支持根据设定规则实现对不同存储策略下数据的同步与备份，并提供基于此的功能模块——自动扫描与更新本地环境中的依赖项；通过预设的标准模板库以及自定义开发接口的支持方式能够满足更多应用场景的需求，并展示系统运行后的实际效果

图-空间镜像详情及创建空间

图-镜像空间设置

图-空间授权

图-镜像复制

图-基础镜像

3.1.1.6.6 部署管理

平台采用标准化的方式进行镜像交付。针对每日迭代版本的上线过程，在系统架构上采用了统一化的策略。系统设计时选择了最小化粒度为镜像来进行整体规划与优化工作，并且所有的相关操作将统一由镜像工厂处理。该系统架构设计目标是实现对基础部署、部署策略以及容器管理等多个功能模块的全面覆盖与集成优化。

实现效果如下:

图-应用部署

图-容器管理

图-灰度部署

3.1.1.6.7 应用商店

模块商店

模块中心包含两大功能区：一个是模块商店部分（Module Store），另一个是模块管理（Module Management）功能区。其中， Module Store 区域又划分为内置模块与定制服务模块两个子区域：内置模块即为自主开发通用功能模块；定制服务则根据客户需求定制专门的服务应用。在 Module 管理区域按照类型划分不同功能类型，并对各类功能提供详细的概述说明、截图展示、资源文档以及安装指导等内容。系统支持用户根据实际需求选择需要安装的功能类型，并对其已安装的功能进行相应的配置管理和启动/卸载操作。

实现效果如下:

图- 模块管理

图- 模块管理-安装

图- 模块管理-安装

图- 模块管理-模块截图说明

模块管理

该系统负责对已有的组件进行状态监控，并提供手动操作和创建新的软件组件两种功能选项。支持手动操作的是通过预装工具包或网络资源直接完成任务；而创建新的软件组件则依赖于平台开发者工具并结合自定义API实现功能定位。具体来说，在系统状态下执行管理任务时会将应用文件放入预先准备好的存储位置；随后完成相应的操作流程并将其放置回指定位置即可；已有的组件能够及时更新和移除

图- 模块管理

容器组

支持容器组下的容器运行状态信息获取。包括容器名称以及对应的配置参数设置情况，并涵盖其所属的应用类型以及相关的宿主机资源状态数据。该功能还包含镜像版本号和构建过程中的相关信息统计，并支持实时监控功能的状态显示情况。同时能够统计每个服务 container 的重启次数以及历史操作记录，并配备创建时间戳作为参考依据，并具备故障排查功能以帮助定位问题所在的位置和原因

图- 容器组信息

3.1.1.6.8 基于模板部署

平台提供了丰富多样的应用模板服务，在模板管理页面上设置了名称标识与应用分类组合定位检索等功能项；用户可通过平台管理模块完成模板功能的各项操作包括但不限于创建新模板、对现有模板进行分类归档、修改配置参数以及删除不再使用的模板；不同业务场景下的应用程序在部署策略上具有一定的相似性；借助统一化的模版资源能够实现快速构建和部署任务

图- 新增模板

图- 模板详情

3.1.1.7 服务管理

3.1.1.7.1 服务管理

支持可视化界面管理功能，并集成丰富的服务组件以满足以下需求：提供标准化的服务名称列表、应用配置信息以及镜像版本详情等基础数据查询功能，并通过统一接口实现日常维护操作的快速接入；系统还具备动态添加与配置新的服务实例的能力，并能实时监控已部署服务的状态变化及运行周期性行为特征。此外该系统能够实现对已部署服务的实时监控与全生命周期管理功能

图-服务查询及日常维护

3.1.1.7.2 服务发现

平台不仅支持基于 Etcd 的原生功能 discovery 功能（function discovery），同时也采用 DNS 与 Kube 微服务的组合式 service discovery mechanism（services discovery mechanism）

3.1.1.7.3 数据库服务

平台内置提供了Mysql、PostgreSQL、MongoDB、Redis以及Memcached和Casandra等多种服务组件作为基本模板配置，并且还提供了消息队列系统以及大数据相关功能模块。这些组件能够实现对数据库服务的各项核心操作包括检索数据存储状态以及执行启动重启等日常维护任务；系统不仅具备对数据库基本信息实例信息配置信息和日志信息进行全生命周期管理的能力还能够实时跟踪服务器资源使用状况如CPU内存磁盘及网络传输速率等关键指标，并且包含数据备份与恢复管理功能以确保业务稳定性

图-数据库模板

图-大数据模板

图-日志信息

图-操作日志

图- CPU、内存

3.1.1.7.4 存储

该平台支持存储卷管理方案；为存储卷基础维护功能进行配置；新增和删除操作以及YAML文件的高级安装编排方案。

图-存储

3.1.2 容器平台可扩展性

3.1.2.1 集群规模扩展能力

基于 Kubernetes 核心架构设计的容器平台软件底层架构，在集群节点数量及容器化运行环境两方面均受到主机性能的影响。当集群每增加一个节点时，kube-controller相关的计算负担随之增加 0.1CPU/80MB 内存；而 namespace 创建操作引起的内存占用可忽略不计。

内置的用户中心基于OpenLDAP架构设计，并支持通过集群技术实现大规模扩展。该系统能够通过持续扩展横向节点来提升用户的数量，并满足任意数量用户的创建需求。此外该系统还允许用户提供自定义解决方案以实现与其他系统的技术对接

在集群访问用户数量持续攀升的情况下，平台控制器单个前端实例的最大承载能力可达约150个并发用户，在达到预设资源峰值时即可满足预期性能需求。当前端实例的并发请求数超过该数值时，在保证系统稳定性的同时适当增加前端服务端点的CPU和内存资源配置能够显著提升系统处理能力，并通过合理规划前后端服务的比例关系进一步优化整体吞吐量。

3.1.2.2 插件扩展能力

随着云原生社区正迅速发展并不断丰富其功能，在整个生态系统中,Kubernetes主要承担少量计算编排相关的功能。然而，在实际应用场景中,大多数用户所依赖的功能都源自其他相关社区为Kubernetes扩展提供的能力,例如Ingress、CoreDNS等非核心组件却不可或缺。因此,平台采用了模块化设计，在保证系统架构稳定的同时支持新增功能组件的扩展。当前集群所使用的Ingress、CoreDNS、HPA、Istio等功能均属于在此框架下持续迭代补充的内容

插件与平台的API/SDK进行整合开发。利用一组独立镜像打包模块集合通过发布功能向平台提供服务，并由插件管理中心系统完成安装操作。

安装完成的插件按照规范运行通常位于独立的 namespace 中的一系列容器，通过平台实现统一管理。

3.1.2.3 OpenAPI 接口扩展能力

该平台遵循 OpenAPI 标准提供开放接口，并支持 Kubernetes 原始 API 的调用方式；在进行二次开发时确保设置的一致性：即配置的接口地址、请求参数以及响应参数均与 Kubernetes 官方 API 实现完全一致；同时，在对象管理方面也实现了高度的一致性：即通过接口建立的对象与通过平台界面操作建立的对象保持一致

3.1.3 安全合规性对接

3.1.3.1 统一身份认证

基于IT 信息化系统的容器平台，在安全与权限管理方面遵循统一的身份认证与管理系统。通过构建统一的身份认证系统来实现企业内部认证系统的对接，并有效获取用户身份验证信息的同时动态更新相关配置参数。

统一身份认证系统能够支持集成多种身份管理系统以提升整体安全性与可管理性问题, 其中包括LDAP, CA以及现有的AD域安全系统等主要组件。该系统的内部架构如图所示。

图-统一身份认证

根据如上图所示的情况, 统一身份认证平台由一系列安全管理和认证功能模块构成, 能够实现以下功能:

身份认证中心：维护企业用户档案库，并负责对账号属性及权限设置进行规范化处理。

该平台具备完善的权限管理和访问控制功能：支持根据用户需求制定个性化的权限分配方案;提供灵活多样的访问策略配置与优化流程;实现了基于身份的信任体系的安全更新机制;具备实时监控与审计的核心能力。

身份认证服务：该服务负责为应用系统提供安全的身份验证接口，并处理来自不同客户端的的身份验证请求；该服务的主要职责在于实现用户的的身份验证以及权限角色的转换与分配。

通过插件机制，在访问控制服务中整合了单点登录功能模块。在用户的单点登录流程中，在完成身份验证后自动发起对业务系统的访问请求，在敏感信息传输过程中通过通信端口进行安全防护；随后由服务器处理并完成身份验证认证流程，并将认证结果返回给客户端；随后在完成身份验证后自动发起对业务系统的访问请求，并将认证结果返回给客户端；随后在完成身份验证后自动发起对业务系统的访问请求，并将认证结果返回给客户端；随后在完成身份验证后自动发起对业务系统的访问请求，并将认证结果返回给客户端

AD域管控中心及数字证书管理平台：在个体用户身份认证和单点登录过程中所需电子签名证书的颁发；基于USB智能密钥的身份认证电子凭据的生成。

3.1.3.2 与现有监控体系对接

在银行提供的各类金融服务中，在线交易占相当大的比重；因此银行数据中心系统的稳定可靠的运行是其能否为客户提供优质服务的基础保障。对于新增部署的容器平台，在整个集中监控体系内实施统一管理，并对其运行参数及状态进行实时监控与管理；当发生故障时的状态需及时触发报警输出

目前银行数据中心已达成系统监控、应用监控、日志监控及交易监控的全面实施，并内置了HUB以整合第三方监控。银行监控系统通过固定IP与CMDB对接后可获取资产系统的映射关系，并实现实时告警。

图-监控体系对接

3.1.3.3 与集中日志系统对接

当下

容器平台除了需要将平台上的日志提交至集中的日志收集点外，在容器运行的日志以及服务层面的日志同样也需要提交至同一个集中的日志收集点。

图-日志对接

容器平台与日志中心集成，需满足如下需求：

◼ 针对动态增减的容器实例，保证日志收集对象的完整

◼ 涵盖平台日志和应用日志

◼ 收集容器的标准输出日志和内部应用的多个文件日志

◼ 容器平台上的应用日志需通过 Kafka 消息队列分发给集中式日志中心

◼ 上传的数据应至少包含收集时间、集群、应用、服务、容器等关键标识

◼ 对接的行内日志中心如出现异常，不能出现日志丢失或不完整的情况

◼ 支持大规模的日志上传，且不丢失数据

平台日志中心应具备"容器感知"能力，并构建多层次索引系统；提供复杂的条件查询功能；能够处理各类业务监控告警信息；包括基于应用的日志信息查询和基于容器状态的日志信息查询等。

3.1.3.4 与堡垒机对接

图-堡垒机对接

为了保护网络与数据免受外来及内部攻击者的侵扰与破坏，在设计上实现了运算管理与安全管理的整合，在终端层实现了对网络及服务器资源的直接影响获取或使用的阻止。堡垒机通过协议代理的方式实现了对外部请求的间接处理，并结合了运维管理与安全性的优化配置；从而具备以下特点：

◼ 运维人员通过堡垒机登录系统，所有操作行为被记录和审批；

◼ 堡垒机保全了全部的生产用户信息；

◼ 应用系统之前相互隔离，运维人员分别登录自己有权访问的系统；

基于容器平台的应用集中管理所引发的风险问题，在保障容器平台的安全性方面提出了更高要求。为此，在所有用户进行应用管理的过程中都必须经过堡垒机这一关键节点来实施严格的访问控制措施。

另一方面，在服务流程平台的帮助下（无需额外步骤），容器平台也具备了用户的接入与权限配置功能。为了方便实施相应的用户管理和权限控制（例如区分不同级别的账号：高级账户享有更为丰富的操作权限而普通账户仅限于查看和读取内容），并进一步优化用户的登录体验（单点登录方案能够有效降低账号的安全风险），容器平台通过中间环节协调各系统的交互过程（实现了各类用户的账号信息与其对应的访问权限设置之间的实时同步更新）。

容器平台与堡垒机实现了集成连接，在此过程中堡垒机负责存储用户信息与资源信息，并维护相应的授权信息。同时，在堡垒机上基于组织架构对用户进行分组管理，并在容器平台上为这些组建立相应的关联用户 account

在日常维护期间，用户通过容器平台使用其低权限账户。堡垒机为用户提供一个用于身份验证的入口，并基于用户的配置信息识别相应的组别。随后，该组身份验证信息将被用来完成对容器平台的登录认证流程。

在变更操作中，用户将通过容器平台的高权限账号进行操作。具体流程如下：首先，在服务流程平台上发起申请请求，并等待审批通过后，在堡垒机上进行身份验证登录。堡垒机系统将根据用户的关联配置信息，在该用户的所属安全组中获取权限，并完成对该容器平台的认证登录过程。

容器平台负责项目注册与配额信息的维护，并由管理员控制各项目的资源使用上限以及项目数量。

容器平台能够管理用户的注册与添加操作，并对本地账号进行配置以设定最低的密码强度要求。

容器平台用户的登录功能支持本地账户、LDAP认证以及与第三方SSO服务对接的身份验证服务。当一个用户完成身份验证后，系统将自动发送一个Token给该用户以进行后续的身份验证操作。针对异常情况下的用户体验保障措施包括：对连续3次以上未成功登录同一账号的情况将进行短暂禁用（30分钟内无法登录），而对于密码更新不及时或者过于简单导致长时间未更改的用户，则系统将根据设置自动提醒或强制要求更换新密码。

在架构设计上不仅负责实现用户的安全性管理功能，在实际运行中还承担着API门户的作用。当应用程序向容器平台发送API调用请求时，所有请求都将首先由该组件接收，并通过Token验证机制进行身份认证与权限核验。随后系统会根据所访问RESTful API的具体方法以及路径参数分析当前用户的访问权限，并且只有获得授权后才能将该请求进一步转发至内部处理环节。

3.2 统一知识库

在企业内部缺乏一个明确且清晰的知识定义。一旦企业建立起来就会持续不断积累并生成物质资源，在这些物质资源天然利用过程中部分资源能够被重新配置并优化以提高效率进而进一步提高资源利用率获得了‘知识属性’特征以促进其可用性增加其知识化程度。

就某个层次而言，在较高层次中将对象归类为"知识"可能更为合适；而在较低层面上则更适合用"资源"加以描述。由此可见，在企业层面来看, 知识与资源实际上属于同一概念中的两种不同表达形式, 仅在于所处层级的区别而已。这种观点下, 知识工程建设与常规性的资源建设并无本质上的分界线, 在工程实践操作中也无需过分强调其界限划分。从实际应用的角度出发, 任何能对工作产生帮助作用的资源都可被视为相关知识内容的一部分, 因此在产品研发设计过程中, 所涉及的各种有用资源都可以纳入到该领域的建设范畴内进行系统规划和管理。

3.2.1 建设目标

知识应用要实现以下几方面的建设目标：

◼ 实现各类知识的体系化管理与基础性功能应用；

促进不同领域知识与应用开发环节的融合，并构建其知识体系作为支撑

通过建立各类知识与其相关联的关系网络来形成以个人为中心的知识存储结构

◼ 实现对各类知识应用效果的分析统计；

◼ 实现各类知识的多渠道应用；

◼ 实现各类知识与工程师工作场景的融合， 达到知识 “随需而现” 的效果。

3.2.2 建设方案

旨在达成上述多个领域知识的应用目标，在规划知识运用方案时需从两个维度展开：第一维度是建立支撑性功能模块；第二维度则致力于开发多样化的应用场景。

(一) 知识应用的基础功能

(二) 知识应用的多途径

从实现效果来看，知识的应用主要包含三类方式：具体来说，则包括知识门户应用、客户端应用以及嵌入式业务系统应用。

通过构建一个智能化的知识门户系统，在浏览器端实现各类知识的全面整合与灵活运用，在研发流程中实现不同环节间的无缝衔接等。具体而言包括：智能化搜索引擎支持多维度信息检索；基于人工智能的知识地图提供直观的知识关联展示；研发流程的智能化推荐机制帮助提升工作效率；根据用户搜索记录量身定制化推荐机制；以及基于行为数据分析的智能推荐服务等

通过构建一个智能化的知识门户系统，在浏览器端实现各类知识的全面整合与灵活运用，在研发流程中实现不同环节间的无缝衔接等

知识的客户端应用：借助客户端工具对各科室中与每个研制任务相关的知识点进行系统性地分类整理和有机整合，在组织形式上涵盖输入管理输出处理流程优化质量保障以及模块组件间的关联关系等七个维度从多个维度展开包括但不限于输入管理输出生成流程优化质量评估模块组件间的信息交互及关联节点间的知识连接等细节内容。进而构建基于研制任务的知识网络系统并实现与其开发流程实现了有机衔接

嵌入式容器平台系统的知识导入：通过技术手段将专业知识传递至工程人员的操作界面，在相关领域展示并集成专业知识点。促进专业知识与工程实践的有效结合。

3.2.3 知识分类

容器平台的知识涉及与平台相关的内部内容以及外部关联系统的专业知识体系。我们将其笼统地划分为了九大类别进行管理与学习。各类资源均可根据实际需求进行更细致的分类以满足不同场景下的应用需求，并通过表格的形式直观展示各部分的具体构成

3.3 统一制品发布

在金融与IT领域中，容器技术的应用已成为显著提升整体交付效率的关键因素。特别是在那些直接服务于客户以及内部业务流程的应用系统中，在过去将开发、测试、运维工作划分为各自负责的不同环节中，在企业级应用交付平台与开发运维之间实现了前所未有的协同作用，在这样的体系架构下，在这种分立模式导致企业无法及时满足快速响应客户需求的需求的情况下

随着Docker的推出，在持续集成与持续交付（CI/CD）领域以及开发运维协同方面带来了全新的思路。如图所示, Docker将所有交付的内容整合到统一的Docker镜像中(类似于模块化的乐高积木),确保各个团队——包括开发者、测试员以及运维团队——都能使用标准化的Docker镜像作为基础。每个镜像是预先包含了所有必要的环境组件,基于这些标准化镜像进行协作工作后,在功能实现上达到了预期目标,并且显著减少了潜在的安全隐患。

3.3.1 方案架构

图-方案架构

全面支持Code to Cloud平台的CI/CD持续交付解决方案实现全自动化流程。开发者只需专注于核心代码层即可。这些关键环节均可由CI/CD平台自动处理。CI/CD平台利用镜像技术实现版本识别与管理，并支持灰度发布及回滚操作。

开发运维一体化场景中值得注意的是，在当前大多数金融行业应用中采用的是第三方软件开发商的技术方案，并且金融企业内部IT人员难以掌握关键操作步骤。通过引入容器化技术实现应用发布流程的统一规范，并大幅减少了对第三方软件开发商的依赖程度的同时显著提升了运维效能。

◼ 全功能产品团队，开发／测试／运维在一个组织架构下

◼ 应用有持续迭代要求，版本的每次更新都需要通过开发、测试、发布全过程

测试环境和生产环境部署主要依靠人工操作, 环境之间的差异性导致部署效率相对较低, 相关的沟通成本高昂

◼ 应用技术栈趋向于多元化，应用配置／运维／管理差异性大，管理成本高。

依托CI/CD平台支持企业持续稳定的交付流程，
构建适用于多环境且无差异性的软件交付流程，
确保企业能够高效、自动化地完成软件资产的交付。

图-交付流程

3.3.2 代码版本管理

作为企业软件资产的关键部分，在现代企业软件开发方法论中编码活动产生了丰富的成果，并被系统性地记录和保存下来。在许多现代化的企业软件开发流程中, 团队协作主要遵循基于编码规范的操作方式展开, CI/CD体系则必须确保能够对接主流的企业级编码管理系统方案, 通过灵活配置触发机制来实现由编码驱动的应用持续交付自动化

3.3.3 自动化测试

一般情况下，在进行测试之前（也就是提测阶段之前），我们会将自动化测试放在前面，并将其用于判断是否达到了提测的要求。在设计流水线时，在这一阶段结束后应该将其分为两部分：一部分是完成常规功能验证的任务模块（即完成系统功能需求的所有测试），另一部分则是专注于性能优化的任务模块（即完成系统性能优化的所有测试）。下面将介绍以RobotFramework为例说明其优势所在。

◼ 支持简单易用的表格型语法，使得可以用统一方式创建测试用例

◼ 提供可以复用既存的关键字的功能

◼ 提供 HTML 的简单易读的报表和日志结果文件

◼ 平台和应用相互独立

◼ 提供简单的 Libary API，可以使用 Ptyhon 或者 java 进行实现

◼ 提供命令行接口也 XML 格式的输出文件，非常容易进行持续集成

◼ 支持 Selenium，Java GUI 测试，Telnet，SSH 等

◼ 支持创建数据驱动的测试用例

◼ 变量的内建支持，尤其是不同测试环境下的测试

◼ 提供 test case 和 test suite 级别的 setup 和 teardown

◼ 通过平台的内置模块可以很方便的集成 Robot Framework

3.3.4 打包构建

改写说明

CI/CD 基于预先设定好的触发条件能够自动执行打包构建流程，在代码发生变化时会自动从版本控制系统中获取相应的源码进行处理。

在完成代码拉取后，CI/CD会遵循特定的编译构建描述文件（即Dockerfile文件）来进行镜像构建。整个构建过程具有可追溯性，并成功实现了软件资产与代码资产之间的关联。

在完成镜像构建后, CI/CD 系统将依据预设规则标注镜像版本号, 并将其推送到内置的企业级存储区域.

同时，在编译打包过程中通常会占用较多计算与内存资源。为了确保集群现有应用不受影响，则要求将编译打包环境与应用运行环境进行隔离设置。通过CI/CD机制，在集群中指定特定节点作为专用构建主站，则可实现计算任务的有效分配。

3.3.5 运行环境

在持续交付流程中, 为确保开发、测试与生产过程的有效衔接, 必须为团队提供一个各向异性的一致性应用运行环境. 同时, 在应用运行环境中实现各向异性后, 还需对不同角色之间的访问权限实施严格控制, 并采取相应的资源隔离措施.

基于CI/CD框架，在不同环境中设置相应的虚拟专用网络（VNet），并将相关的团队纳入可访问的VNet中以确保不同VNet间的应用可见性权限得到合理的控制。

通过将不同环境对应的主机添加到租户空间作为该租户独有的资源，确保各环境间的资源隔离。

CI/CD系统具备全面的应用部署能力和专业的运维支持功能，在实际应用中能够帮助团队迅速评估应用的运行状态

3.3.6 持续部署

自动化构成了持续交付流程的核心要素，并不仅然是为了提高软件交付速度和迭代频率的重要能力。通过在CI/CD阶段设定持续部署策略，在应用发布周期内实现版本更新与代码变更之间的无缝衔接，在CI/CD阶段设定持续部署策略，在应用发布周期内实现版本更新与代码变更之间的无缝衔接, 从而将显著降低开发及测试人员频繁切换开发环境所导致的操作复杂性, 显著提升了效率水平, 并促进团队持续创新并稳步发展。

3.3.7 制品交付

针对金融行业的应用交付特点中的一部分是企业自研的应用主要由开发团队独立构建其余则是依赖于外包软件开发商完成其构建工作因此需要为这两种不同的交付模式制定相应的交付流程其中企业自研应用的DevOps流程通过代码的方式进行

图-制品交付流程

◼ 开发团队提交代码到代码仓库

◼ CICD 自动进行编译打包，并提交到镜像仓库

◼ CICD 根据发布规则，自动将镜像发布到预生产环境中

在预发布环境中验证无误后，在服务器上完成版本编码，并将最终镜像生成后部署至生产环境下的存储池中。

◼ 手动将待发布的镜像，发布到生产环境。

应用开发商通过制品交付流程：

图-应用开发商制品交付流程

◼ 应用开发商直接提交代码到代码仓库

◼ 应用开发商提供应用安装包到代码仓库

◼ 应用开发商提供应用安装包到制品库，更新代码仓库的对应脚本文件

◼ 构建镜像，自动推送预生产环境

◼ 标记镜像，手动更新生产环境

3.3.8 合规性检查

容器平台及服务具体涵盖了认证验证、权限管理、安全监控、数据传输保证、数据机密保护以及故障容忍等核心功能，并通过一系列安全管理措施保障整体系统的安全性与稳定性

身份鉴别

在身份识别方面，在线完成了与统一身份认证平台的对接工作，并成功获取了唯一标识的身份信息

◼ 可以通过用户所在的组织、角色、姓名来人工识别该用户

该系统实现了身份唯一性验证机制，在新增或修改后的用户记录中会自动执行唯一编号的一致性检查

在系统中管理对话记录方面有明确规定，在用户体验上进行了优化设计，在此过程中实现了对服务端数据的有效管理与安全保护。具体而言，在系统运行过程中有严格的权限控制机制，在此框架下实现了对对话记录的安全访问控制与权限分配管理功能，在保障系统稳定运行的同时也有效提升了用户体验水平。

该系统设置了容忍用户的登录失误次数（默认值为5次），当用户连续多次输入错误密码导致未能成功登录时，其账户将被禁用并暂停访问30分钟。

在用户进行登录的过程中，在系统日志中将记录下用户的账号信息以及连接到该设备的ip地址信息，并且每次操作都会产生一个时间戳。这些记录将被用于跟踪用户的活动

用户密码将由统一认证平台进行配置。其最低设置为8位，并遵循一定规则。账户若长时间不用（超过3个月），将被系统自动锁定。请通过找回密码功能重新设置密码。

◼ 重新设置的密码不能与前 3 次设定的原密码相同

◼ 用户设定保存在服务端的密码采用 AES 对称加密算法安全加密

◼ 通过审查系统设计，并进行差距分析项后能够达到

◼ 为用户提供专用的登录控制模块对登录用户进行身份标识和鉴别;

为同一用户提供的多种不同的鉴方法用于实现身份鉴过程。

该系统为用户提供了身份识别功能提供者能够确保每个用户的个人数据在系统中独一无二，并且这些功能还能够有效防止他人非法复制或模仿。

该系统支持异常登录处理机制（包括在异常情况下终止对话流程、设置合法用户的登录上限以及在异常情况下自动终止进程）。这将有效提升用户体验。

向用户提供身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理等功能，并依据安全策略进行参数设置。进而基于上述安全机制的设计方案, 我们得以实现:

◼ 提供专用的登录控制模块对登录用户进行身份标识和鉴别;

实现独特的身份标识符检测机制以确保系统中没有两个相同的用户标识同时防止他人伪造或盗用这些信息

支持该功能的实现可以通过以下手段：首先终止当前会话；其次防止重复登录行为；最后触发账户注销流程。

部署 watersource 管理功能并在遵循 watersource 管理策略的基础上进行参数设置

对口令的长度、复杂程度以及定期更新进行设置要求，并且必须采用单一的账号标识符

安全审计

容器平台以及服务安全审计设计如下:

◼ 系统保存用户访问日志，会记录用户的任何操作轨迹

详细记录了格式化的信息：系统会完整记录用户的各项操作时间与内容；完整记录了用户的各项操作时间与内容；系统会详细记录用户采用的具体登录方式、所使用的 ip 地址以及相应的注销过程；确保所有操作均被完整记录

系统中的所有日志设置了访问权限, 普通用户无法访问这些日志内容, 仅限于授权的运营人员才能下载, 但不得随意更改这些记录内容, 确保其不可篡改或更改。

该系统支持对审计记录数据实施统计、查询、分析以及生成审计报表等功能；通过对其设计实施审核以及对其日志进行详细审查，并经过相关性评估后能够确保其有效性和完整性。

该系统应具备覆盖所有用户的全面安全审计功能，并对应用系统的关键安全事件实施审计。

◼ 应保证无法单独中断审计进程，无法删除、修改或覆盖审计记录;

审计记录的内容应包含发生的时间点、发起者的相关信息、记录类型、详细描述以及具体的结果信息等。

◼ 应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。

进而通过以上安全机制设计能够实现:

该系统应具备覆盖所有用户的综合安全审计功能模块，并对关键系统异常情况实施动态监控与记录；

◼ 应保证无法删除、修改或覆盖审计记录;

审计记录必须包含事件发生日期、发生时间以及发起方信息等基本要素；它们还应具备分类依据及详细说明，并以明确的结果指标来评估其完整性。

该系统赋予了独立的审计员角色，在规定时间段内能够提取相关数据，并确保数据的安全性。这些特定的责任仅限于审核人员这一群体，并不具备对外公开或处理的能力。

通信完整性

容器平台以及服务通信完整性设计如下:

为了确保通信完整性和可靠性，在通信过程以前，在通信系统内对传输的数据报文以及相关的信息实施 communications record when data is about to be transmitted. 当接收端接收到数据时，在接收端程序中实施 length verification process.

◼ 端和服务端程序会对必须数据字段进行非空校验。

在对审核流程设计以及部署方案设计的基础上，并通过对比分析找出不足后，能够采取以下措施来确保：通过使用密码技术来保障通信过程中的数据完整性。

基于上述安全机制的设计理念, 该系统将采用校验码作为验证手段, 以确保通信过程中的数据完整性和可靠性。

通信保密性

容器平台以及服务通信保密性设计如下:

通信系统采用了 HTTPS 作为安全协议，旨在确保数据在传输过程中即使被截获也不会被解密。

采用AES对称加密技术对敏感信息进行处理，在传输过程中对关键数据进行保护；只有当数据抵达目的地点后才会被解密并加以利用。

在项目实施过程中，在系统设计阶段完成审核，并在后续阶段进行差距分析后最终能够实现目标

在通信双方开始会话前, 应用系统需通过密码技术完成会话初始化验证过程

◼ 应对通信过程中的整个报文或会话过程进行加密。

进而通过以上安全机制设计能够实现：

在开始前，在通信双方建立连接时, 系统应通过密码技术来进行会话初始化验证

◼ 应对通信过程中的敏感信息字段进行加密。

其他

其他安全方案涵盖了多种措施, 包括提供必要的产品功能, 防范潜在的安全隐患, 实施数据备份与恢复策略, 完成部署及日常备份工作, 并制定系统的管理建议等, 其中这些系统管理建议具体可分为: 数据存储的安全方案, 信息使用的安全性策略, 接口调用的安全性措施, 应用层面的安全防护手段以及综合性的安全保障措施等多个维度。通过以上所列的安全机制和技术手段可以实现：全方位的安全防护目标与技术保障体系的有效构建。

◼ 系统提供安全手段防止非授权用户的非法侵入、攻击

◼ 提供的产品(包括中间件)不能包含已被发现的漏洞

支持备份与恢复系统数据，并具备分级精细度的备份策略同时提供恢复验证功能的测试环境

为本地用户首次登录提供了强制更改密码的功能，并允许在账户锁定后自行设定解锁时间。

支持系统日志能够采用与syslog一致的格式，在本地进行记录管理的同时也能在syslog日志服务器上发布

3.4 统一资源申请平台

平台涵盖用户贯穿整个流程的自助支持功能

3.4.1 自助资源申请服务

租户通过统一云服务目录申请各种多样化的测试资源，包括：

遵循标准申请IaaS服务的要求，必须具备以下关键组件：包括虚拟服务器（VM）、云主机（云主机）、安全组配置、弹性IP地址池、负载均衡机制以及对象存储服务等必要组成部分；

◼ 申请自营 PaaS 软件服务，至少包括：Oracle、JDK、Tomcat 等；

为容器应用部署服务创建配置，在申请表单中进行参数设置以选择容器镜像、容器规格以及 Helm Chart文件。云管理平台将负责自动处理整个部署流程。

◼ 云资源使用过程中遇到问题，可提交事件、问题、变更等工单服务。

3.4.2 在线审批流程

提供云服务申请的在线审批流程

在获取资源时，在获取资源的过程中以及在申请资源的过程中等表述都可以进行替换或调整句式使其更加丰富

◼ 租户可以查看自己的审批进度和详情；

批阅人能够调整申请信息中的相关参数；该申请可能被上级批阅人拒绝处理或者由本批阅人直接拒绝处理。

当一个云服务包含跨技术服务团队的资源时，在实施审批流程时需要遵循多层次审批程序；具体与该技术领域相关的是不同技术团队拥有不同的审批权限和修改权限。

3.4.3 自动化部署

通过服务目录申请的云资源服务，可由云管平台自动化部署：

支持可视化展示、呈现自动化交付进程的动态变化以及记录具体操作日志的功能

在涉及多云资源的自动化执行过程中，在线管理平台需具备获取运行态状态的能力，并自主确定各资源的操作顺序和并行程度；通过收集各资源的状态信息来实现跨资源参数配置。

在自动化的交付过程中出现问题时，在线的云管理平台应在发生问题时以明显的图标进行提示，并向管理员发出警报信息。允许管理员在问题解决后自行决定是否重新启动该流程或继续从错误状态中恢复。

能够自动化地完成交付后并将这些必要的配置信息与访问信息发送至邮箱以及短信中以确保通知到所有申请者

云资源自动化交付服具有多样化的扩展能力。通过可视化界面实现灵活的服务编排功能，并允许用户自定义配置申请表单。针对自动化参数的配置，默认值已预先设置；对于未指定的参数项，则开放给租户进行填写。此外, 该系统还支持创建新服务, 终止现有服务以及批量复制现有服务等操作。

3.4.4 自助运维

配置自助化云服务管理功能后，在线租赁用户可在云端服务管理界面自主管理其所有租用资源，在线查看并自主完成对其所拥有的各类资源的日常维护工作及重要数据的备份还原等基本操作。

◼ 云主机，支持启停、CPU 内存磁盘扩容、安装软件、堡垒机登录

◼ 弹性 IP，支持弹性 IP 支持绑定、解绑虚拟机

◼ 安全组，支持安全策略的添加、删除

◼ 负载均衡，支持增加节点、删除节点、修改轮询和健康检查策略

◼ 对象存储，支持创建文件夹、上传文件、删除文件

◼ Container 容器镜像，支持更新副本、增加副本、调整规格

◼ 部分涉及资源变更的运维操作，需要遵循审批流程

3.4.5 自助监控告警

提供自助监控告警功能，包括：

为租户展示其IaaS和PaaS服务资源的监控，并具体包括虚拟机（VM）、软件定义负载（SLB）、对象存储（OSS）以及容器Pod等。

◼ 将租户自己的 IaaS、PaaS 资源的告警信息展现给用户。

3.4.6 租期回收

提供租期回收功能，包括：

◼ 云资源租期到期后将停止云资源服务，并放入回收站；

◼ 在保留期内（如一个月），租户可申请云管理员将云资源从回收站恢复；

◼ 回收站内资源过了保留期后，将被卸除（同时从云平台中删除）；

◼ 即将到期的资源应发送邮件或站内信息给租户；

◼ 租户可进行资源续租。

3.5 容器统一规范

3.5.1 容器内应用的健康检测

在集群中：

• 可以利用健康检查探针来评估容器的就绪或存活状态。
• 以便确保集群整体上能够维持业务容器的可访问性和可靠性。
• 集群中的健康检查探针类型：

live check (Liveness probe, Liveness sensor)：被该探针用于确定何时重启容器。当应用程序运行但无法正常对外提供服务时，能够通过此探针检测到此类异常，并从而重新启动该状态下的容器

采用该探针机制用于确认容器是否已启动完成，并能正常向外界提供服务。其中当Pod处于未处于完全启动状态时，在Service的iptables转发规则中不会配置该Pod；仅在Pod达到完全启动状态后才会被纳入Service的iptables转发规则。

3.5.2 应用容器的 DNS 配置

可以在 Pod 级别来设置 DNS，主要涉及到两个配置项“dnsPolicy”和“dnsConfig”，其中：

dnsPolicy 的类型有:

◼ Default：Pod 中 DNS 的配置会使用宿主机上/etc/resolv.conf 中的配置

ClusterFirst （如果Pod没有明确指定dnsPolicy的配置，默认为此种类型）：pod中的 DNS 配置将使用 10.96.0.2（即 Kube-DNS/Core-DNS 的配置）， pod 中集群 domain 的前缀将进行解析；而非集群 domain 前缀将转发给 Kube-DNS pod 所在宿主机上的 resolv.conf 文件中配置的 nameserver 进行解析查询。

ClusterFirstWithHostNet：当Pod采用hostNetwork网络时，默认会基于本地宿主机系统读取/etc/resolv.conf文件。若希望在hostNetwork模式下实现Kube-DNS与Core-DNS的有效通信，则可采用此配置类型。

遵循Pod内/etc/resolv.conf配置文件的重置操作（即清除其中的内容），通常会配合dnsConfig设置自定义DNS服务的相关参数设置项：

◼ nameservers：指定/etc/resolv.conf 中的 namserver 条目配置

◼ searches：指定/etc/resolv.conf 中的 search 条目配置

◼ options：指定/etc/resolv.conf 中的 options 条目配置

3.5.2.1 使用集群内部的 DNS 服务

如下“ClusterFirst”的 dnsPolicy 可以不指定，默认即使用此策略

3.5.2.2 使用集群外部的 DNS 服务

Pod 中可能部署外部 DNS 服务器，在这种情况下无需为集群内部 DNS 配置转发器即可使 Pod 内部直接解析外部域名。

3.5.3 应用容器的应用配置管理

在集群环境中部署的应用场景中，在容器化部署模式下建议应避免将应用程序的核心配置文件直接注入到应用镜像中。相反地，则应当借助平台提供的功能或机制来实现对应用程序配置文件的集中管理和统一调度

3.5.3.1 通过集群管理应用配置文件

ConfigMap 可以通过如下两种方式提供给容器使用：

◼ 生成为容器内的环境变量

◼ 以 volume 的形式挂载为容器内部的文件或目录

1. 通过环境变量方式使用应用配置

创建简单的字面格式 literal 类型 Configmap

创建 file 类型的 ConfigMap

在应用的编排文件中，可以通过环境变量方式进行引用

2. 通过 Volume 挂载方式使用应用配置

通过环境变量的方式将configmap注入到容器中，在仅当容器重启后才能使configmap内容更新；通过体积的方式挂载为，在完成configmap更新后需一定时间才能使容器内的配置文件更新。

3. subPath 挂载

通常情况下，在 configMap 对象中定义 mountPath 时，默认会将该目录下的所有文件设置为隐藏状态。如果目标仅是将一个特定的文件映射到某个目录中，则可以通过配置 subPath 属性来实现这一功能。这样做并不会干扰该目录中的其他文件。

3.5.3.2 通过外置配置中心管理配置文件

当采用外部配置中心时，只需在应用程序的编排文件中明确指定其IP地址和与相关环境变量。

3.5.3.3 应用配置文件的热加载

默认情况下，默认情况下，默认情况下，默认情况下，默认情况下，默认情况下

默认情况下，默认情况下

以应用为中心地构建配置文件...其中配置名为 app-config

3.5.4 应用容器的日志配置

3.5.4.1 容器的应用日志输出

集群环境中的应用，在基于日志输出功能的情况下，可以通过以下两种方案实现将日志发送至标准输出。

对于那些能够将日志直接发送至标准输出的应用而言，在容器中配置log4j以便将应用的日志发送至标准输出上，则方便地进行日志查看。

如果受限于标准输出的发送能力的应用，在容器环境中可以通过利用 hostPath 的 Volume接口配置为容器使用统一日志存放目录的方式实现日志收集（推荐方法）

当无法直接将日志写入标准输出时

1. 应用本身可以把日志输出到标准输出

下面是把应用的日志通过 log4j 输出到容器控制台上配置文件示例

下面是把应用的日志通过 logback 输出到容器控制台上配置文件示例

2. 应用无法把日志输出到标准输出

若应用无法将日志发送至标准输出，则可将这些日志统一发送至主机的特定存储位置（如 /logs/current/appName）

如果应用不能直接将日志输出到标准输出上，则可以通过 sidecar 容器对日志进行记录。

集群按照标准配置将所有Pod下的容器日志存储于$var/log/containers目录中，并采用"Pod名称_命名空间名称_容器名称"的标准命名规则组织文件路径。随后系统会通过预先配置的日志收集与处理代理对这些日志信息进行统一管理，并经由 designated 后端节点进行集中存储与系统性处理

3.5.4.2 应用日志规范

应用日志输出格式参考：

相关字段的描述：

记录路径：那些无法将日志直接输出至主控台的应用，在PaaS平台所部署的宿主机上会进行相应的存储位置标记；不同应用程序根据特定的路径规则进行区分识别；这些应用的日志存储路径遵循以下规则（以上文中的某系统appabc为例）。

当前应用的运行日志信息位于logs/current/appName-(容器ID).log.crn路径名字符号下的记录文件中。其中每个日志文件大小为50MB。当单个日志文件大小超过50MB时进行轮转处理

日志切换重命名规则：将原有日志文件名称增添切换时间和标记，并提供示例路径如 /logs/current/appName-(容器 ID)-yyyyMMddHHmmss.log

3.5.5 集群资源管理规范

3.5.5.1 应用容器的资源配置

在集群中， CPU 是可压缩资源， 内存是不可压缩资源， 这些资源可以被分为两种不同的状态，即期望状态（请求的资源）和当前状态（已使用的资源），根据这两种状态来评估节点的容量， 根据相应的资源需求来调度 Pod， 上面的两种状态在集群中通过如下两个参数配置：

request：资源需求量，在这种情况下（当实际消耗超过指定需求时），系统会尽力将其控制在其需求范围内。

limit：指定了容器可使用的最大资源容量；当容器的资源使用超过规定上限时会被终止执行；相关的副本管理模块将重新启动并创建新的container实例。

◼ 注：如果容器仅指定了 limit，而没有指定 request，表明两者相同

基于Pod容器在Resource中设置的request和limit值来确定Pod的QoS类型；而对于每一个Resource类别的容器，则可以划分为三种不同的QoS类别。

Fully guaranteed, if all containers in the Pod's Resource Definitions have equal and non-zero limit and request values, then the pod's QoS will be fully satisfied.

Burstable：如果Pod中的所有容器的Resource配置中request参数小于阈值，则这个Pod的QoS会被标记为Burstable。当容器Request中的资源申请量越大，在因资源不足导致驱逐时（即当系统试图根据可用资源限制容器数量），被驱逐的可能性就越低。

BestEffort：除了前面提到的两种例外情况外，在其余所有Pod的QoS类中都采用BestEffort模式。具体而言，在每个Pod内部的所有容器都不会设置任何request或limit参数；如果limit参数未被指定，则该参数默认取值为其Node节点的总计算资源容量值

当宿主机资源趋于饱和时，则会将Pod移除，并最先回收非实时流量（BestEffort类型），随后是具有抖动容忍度的队列（Butstable），最后才会处理高优先级队列（Guaranteed）。对于关键业务系统（如网络设备、数据库等重要应用场景），应努力确保请求（request）与限制（limit）参数配置适当匹配以实现QoS中的优先级策略。而对于非关键业务应用，则可以根据需求灵活设置为抖动容忍或高优先级队列。

Guaranteed 类型资源配置示例

Burstable 类型资源配置示例

在 resource definition file 中未指定 configuration 的情况属于 Effort-Optimized 类型

3.5.5.2 集群资源限制和 JVM 的内存分配

在 JDK版本号1.8中所述之场景下

◼ 堆内存：主要用于存储类实例或对象

每个线程都拥有独立的调用栈；这些 stack frames 中除了自身的方法调用列表之外还包含了原始的本地变量与对象引用；当 stack frames 被弹出或删除时会自动清理因此这里不会执行 garbage collection (GC)

◼ Metaspace：存储了相应对象的类定义以及其他一些元数据信息

Code cache：JIT编译器将原生代码存储于code cache中以便重复利用,从而提升执行效率

Buffer pools: many libraries and frameworks optimize performance by allocating buffers externally in memory. They can facilitate memory sharing between Java applications and native code, as well as caching files in memory.

在 Java 程序中，并非一味增大堆内存就等同于性能优化。Java虚拟机会定期回收堆内占用的资源，在特定时间窗口时程中触发一次彻底的Full GC回收过程。这意味着，在全GC过程中发生的内存管理开销与其占用的堆内存容量呈正相关关系。具体而言，在Full GC阶段应用程序会被暂时中断以完成垃圾回收任务。此外，在实际应用部署中发现过大的堆内存会导致系统资源利用率升高并影响整体性能表现。因此建议平台上的Java应用应基于实际运行测试数据合理规划堆内存容量。

Java虚拟机（JVM）中，默认情况下会自动分配少量初始空闲内存空间用于程序初始化等基本操作。为了优化运行效率和性能，在集群环境下建议根据具体应用需求动态调整系统资源分配策略：将最高和最低堆内存配置设为请求和资源限制内存的80%。

在容器内部，在使用 Downward API 的过程中（即借助 Downward API），我们可以访问到与容器配置相关的 request 和 limit 内存值，并基于这些信息动态地为 JAVA 应用分配堆内存资源。

3.5.5.3 租户的资源管理规范

该系统在用户层级实现了资源配额管理功能，并且能够根据实际使用情况动态设置各类型资源（如计算、存储、网络以及集群对象资源）的使用上限。

可以根据需要，对当前租户可以使用的集群资源进行限：

3.5.6 投产审核

图-投产审批服务流程平台

服务流程平台主要负责银行服务流程的管理与协调工作。通过基于该平台对投产审批过程进行管理设计，在具体实施过程中实现了对各环节的责任划分与监督标准制定。为了确保投产审批工作的顺利推进，在前期规划阶段明确了各项操作规范与执行要求，并为企业投产审批流程的管理和监督提供依据，在此基础上进行考核与优化工作安排。

3.5.6.1 配置信息

在服务流程平台上集成 CMDB 模块以管理数据中心的应用相关信息以及物理服务器的信息和IP地址等逻辑数据。随后监控系统将通过IP地址等数据从CMDB中获取相关信息后进行展示。

在服务流程平台上集成 CMDB 模块以管理数据中心的应用相关信息以及物理服务器的信息和IP地址等逻辑数据。随后监控系统将通过IP地址等数据从CMDB中获取相关信息后进行展示。

容器平台项目上线时会涉及在服务流程平台上手动记录应用信息及相关服务信息考虑到容器弹性伸缩的特点 在未来计划中将逐步实现对IP等关键数据的自动化导入

3.5.6.2 流程审批

旨在更有效地推动针对容器的应用和服务的发布、更新以及部署，并同时实施应用监控。该平台应与行方的服务流程平台实现集成，并将主要承担以下功能模块：

在容器平台中进行权限申请时，请注意用户分为高级和低级权限两类。对于拥有高级权限的用户而言，在完成申请后必须向上级流程管理平台提交请求，并在获得批准后方能成功接入。

◼ 流程审批：系统内部变更、系统上线，需要通过服务流程平台进行审批。

3.5.7 自动化运维

3.5.7.1 运维范围与目标

其中一类运维对象是基础设施部分

第二类运维对象是在IT服务运行过程中被应用于多种运算设备中的一系列资源类型，包括计算设备（如运算服务器）、存储设备（如数据库节点）、容器（如虚拟容器引擎）、服务器设备（如物理或虚拟服务器）、网络设备（如交换机或路由器）以及安全设备（如防火墙或入侵检测系统）等。

第三类运维对象涵盖资产系统以及相关的数据与安全。具体而言,它具体涵盖如IT资产平台,操作系统的各种版本,数据库管理系统的配置,中间件组件的具体功能,应用程序运行环境的设置等软件资源;此外还包括业务运行过程中的各种数据记录以及其他相关信息

第四类运维对象属于一类特殊的管理工具类别，并且其涵盖范围广泛且功能多样；具体来说，它包含基础设施监控软件、IT 监控软件以及多种类型的工作流管理系统等等

属于第五类运维对象的是资产与人员这一类别中包含了多个组成部分：首先是数据中心的技术支持团队；其次是IT运维团队中的专业技术人员；此外还有由管理机构中的管理人员组成的管理团队；最后还包括为服务提供相关支持的专业厂商队伍。

3.5.7.2 运维设计原则

1. 统一管理平台

致力于将DevOps理念融入到IT基础设施建设中而开发出的一体化的企业级业务服务管理系统。该平台面向IT支持与管理层，并以ITIL（IT Infrastructure Library）体系为核心思想为基础。通过整合一系列如业务监控、系统监控等技术手段，在保障服务质量的同时为企业提供完善的企业级业务服务管理系统。

建议有以下功能模块：

业务流监控

流量监控

主机监控

网络监控

存储架构管理

虚拟化架构管理

响应时间管理

应用系统监控

日志监控

业务服务管理

报告报表管理

多方式告警通知

基于B/S架构设计前后端功能模块分离，并采用Portal平台实现统一展示。全方位监控业务流程、基础架构及应用系统运行状态，并提供具备面向服务的端到端应用性能管理功能。不断提升用户体验水平。遵循ITIL标准流程构建基础业务服务管理体系，并利用有效的报告报表分析工具进行动态可视化追踪分析。最终致力于推动IT系统的持续优化与长期发展规划

2. 管理体系开放性

该系统满足业界标准，并且依托开放的管理系统平台遵循行业标准提供管理接口来实现对各类资源的统一管理和与其他管理软件的集成。

支持某些第三方厂商的应用集成，为系统管理的选型提供更高的灵活性

开放式的 Portal API 促进了用户应用程序界面的整合，并在系统管理中获得了扩展空间。

3. 管理系统安全性

保障管理工作的正常运行是管理系统自身安全性的关键要素。必须充分考虑到管理系统的安全性问题，并涵盖以下几个方面：

登录失败次数限制

管理信息在各个组件之间传输时必须通过加密

制定详尽的战略方案，并以应对组织环境的变化；合理分配管理人员的职责与权限。

对用户名、密码等关键信息密文保存。

具有用户登录时间限制等等。

4. 结构化和扩展性

负责范围会随着业务规模不断扩大而相应扩大,这也凸显了该平台在保障投资者利益方面的重要性.这也体现在该平台能够有效支持业务增长以及提升运营效率的能力上.

功能模块的升级项目已启动，在当前阶段主要完成网络设备及主机的管理任务；未来有望在统一平台进行各类应用的整合与后台管理系统整合；同时涉及数据库及业务服务等相关系统的后台管理

管理范围的扩展，可实现多分支的加入扩展，支持分部式管理。

系统 拥有 卓越的功能扩展性，在必要时 可以 增加 管理模块，并进行 拓展 管理节点 以 保障 现有 投资

全业务 RESTful API 支持，Https+Json+XML

5. 模块化结构和扩展性

管理规模将伴随应用的持续发展而增大；由此可见, 管理平台的可扩展性对于保护投资具有重要意义. 其核心体现在:

功能模块的扩展方案能够随着客户的业务发展、应用升级以及网络设备和主机的增加而自动适应性增长，并随时提供相应的管理服务。

扩大管理范围后可支持多分支的增加，并且能够进行分布式部署配置以确保业务管理具有灵活性

系统不仅具有卓越的功能扩展性，并且可以在需要时增添管理模块以拓展管理节点。这将有助于保障现有投资的安全性。

6. B/S 架构，使用与维护简单

基于B/S架构的系统具有界面设计统一的特点，在操作上非常简便。该系统的易于操作且维护便捷性较高，显著提升了系统管理员的工作效率，并降低了维护工作的复杂度。

7. 友好的用户界面，简单易用

现代系统界面设计具有动态美观的特点，在实现人机交互的过程中充分展现了先进性与艺术性；通过采用先进的多展示技术方案（如支持 FLASH 等展现技术），显著提高了界面的表现力与吸引力；同时提供全中文用户界面（All Chinese User Interface），显著降低了操作者的使用难度

3.5.7.3 自动化运维体系建设

1. 云环境对运维监控需求

在架构转型完成后, 应用与基础设施之间实现了解耦, 这给系统中的人、工具以及流程带来了多项新挑战. 为了构建专业化且服务化的运维体系, 银行现有的数据中心运维运营体系需要进行优化升级. 经过新型运维运营体系的支持, 在云环境下能够实现运行过程中的高可靠性保障, 同时实现成本预算的有效控制以及资源供给的高效配置. 新型运维运营体系的需求主要体现在优化管控流程, 规范服务运作标准, 调整供给模式以及重构组织结构等方面.

图-自动化运维需求

2. 运维框架规划

云运维服务目录体系

以云和微服务架构为基础构建银行数据中心的能力矩阵，在清晰定义SLA、角色职责以及输入输出流程的基础上搭建服务目录。拥有规范的服务目录将有助于更好地实施标准化工作流程和服务工具的规范化管理，并制定科学的服务考核指标体系；其中蓝色标注区域需重点搭建具体的服务目标准备方案以及 corresponding 能力支持框架。

图-云运维服务目录

云运营规划

图-云运营服务目录

− 底层资源通过统一标准化 API 接口形成产品，对外提供产品服务；

− 提供租户身份认证、权限控制、操作审计、订单账单计费管理；

− 集团账户、子账号、项目管理体系多种组织结构；

− 管理各个子公司、部门的云资源的成本和预算；

− 灵活计费方式满足分支机构或部门多种计费场景；

− 提 API 接口管理，提高新产品接入效率，增加云平台迭代敏捷性。

该系统基于新产品的引入而被构建。它围绕各 业务场景展开设计，并采用功能模块的方式实现了整体化的自动管理能力。这些功能涵盖了传统自动化的实践以及虚拟化环境下的具体方案。当该系统的建设完成时，则实现了与其他应用及周边系统的全面互联。该平台能够基于现有的 CMDB 应用及系统的配置信息，在自动化运营的过程中得以利用与消耗。借助各功能模块实现了日常运营工作的自动完成，并将执行过程及结果实时或定期传递至相关联的其他系统进行分析或进一步处理

运维自动化平台与应用系统之间的互动主要依赖于 agent 代理机制来完成，并涵盖对应用系统的巡检以及功能发布两大核心环节；而与其他系统之间的互动则多采用 API 或 JSON 格式进行配置管理，并致力于实现监控信号的同步处理及报警事件的快速响应。

总体架构如下图所示：

3.5.7.4 运维技术栈关键设计

1. 集中化任务调度管理

为了实现资源优化配置的需求, 该自动化运维平台必须具备广泛的应用能力, 其设计目标是支持多套主流开发环境, 包括Windows、Linux以及Unix系统, 并能处理Java语言、C语言以及 Perl、 Shell脚本等多种编程语言所生成的任务. 在功能架构上, 平台需要确保所有自动化作业能够统一规划与执行, 并通过实现统一调度机制, 实时呈现作业状态, 实现监控功能. 同时, 该系统还应具备事件响应能力, 同时提供日志追踪与用户权限管理等功能. 这种设计旨在显著提升整体运行效率

2. 自动化任务调度管理

自动化任务调度管理要求管理平台能够具备完成自动化任务的能力，并支持执行调度操作、定期健康检查、实时监控并发出预警信息以及异常处理机制等。

3. 标准化任务调度管理

标准化任务调度管理要求管理平台遵循自动化任务调度接口、流程、配置、响应信息与命名等技术规范的统一标准，并对相关功能进行详细定义与配置设置。该系统需确保现有与新增系统能够实现自动化任务的标准化接入与扩展功能，并以此降低自动化系统整合过程中的技术复杂性

4. 高可用模块化调度管理

高可用模块化调度管理必须包含一套确保系统高可用性的机制以及一套实现负载均衡的策略，并且该系统能够根据负载情况动态优化各模块的资源分配比例。

5. 性能压力及实现要求

自动化的关键功能是按批次发送指令并立即反馈结果。平台同时支持数百个主机的并发执行，并采用非阻塞模式处理每台主机的任务。在处理大规模的数据时可能会给服务器带来一定的负载压力。

应用系统管理运维自动化平台与受管设备之间的通信带宽主要用于脚本文件和软件安装介质的分发过程。其中脚本文件的大小通常不超过10KB，在实际运行中若同时在500台设备上进行处理，则该系统流向外部网络的数据量约为5MB左右；由于其负载压力较小，在日常运行中并不会给整体网络带来负担。然而软件安装介质可能会达到几百MB到几个GB的数据量级；为了避免给整体网络带来较大的负担，在实际操作中可以通过以下措施来处理。

控制：

由于软件安装介质的分发过程遵循FTP协议，在系统管理层面进行相应的带宽控制

在下发软件安装介质的过程中，在业务网段、第三方DMZ以及办公网段之间会按照以下流程进行操作：首先，在核心应用节点接收介质后，在该网络区域内负责存储并转发这些介质的代理节点会完成初步的分发；随后，在该代理节点存储完毕后会依次将这些介质发送至区域内的各个受管设备；这种做法不仅能够避免直接穿透防火墙的情况出现；而且还能显著降低穿过防火墙所导致的网络流量消耗

通过使用该系统进行的任务调度中，尽可能减少并行设备数的同时，在安排软件安装部署作业时，则应将其设置为非工作时间执行

6. 安全控制和要求

数据安全性：运维自动化管理平台的业务数据在物理部署环境中具有高度的安全性，在经历了多级防护措施后仍能确保其完整性与机密性；通过采用本机构统一的数据存储与备份系统，在线实时同步功能可有效提升业务连续性和恢复效率；为业务数据提供全面的安全存储与备份服务

网络安全性：自动化运维管理平台中各组件之间以及服务器自动化组件与受管服务器上代理之间的所有数据传输均采用SSL双向加密通信机制。管理用户和操作用户的账号只能通过ECC业务网段的安全终端设备访问本系统的管理门户，在线监控工作区（OMW）仅能提供巡检结果等关键数据作为查看查询使用的数据源。

安全性能方面，在用户登录管理门户中具备通过业务域 AD 进行认证的能力，并将继续实施用户在登录过程中进行的业务 AD 认证。统一管理系统负责对管理门户中的所有本地应用账户进行集中管理，并确保在任何情况下使用本地应用账户都需经过统一管理系统。

3.6 高可用架构体系

3.6.1 方案概述

采用主备数据中心实施单体应用备份及多活应用的双数据中心部署方案，并结合应用数据外置挂载及主备数据中心三层网络可达的部署方案，从而确保该IaaS平台在某数据中心遭受灾难时的应用服务能在短时间内迅速恢复正常运行。且该平台不仅支持自主实现主备功能，还能满足企业级业务的双机热备及冷机备份需求。

3.6.2 高可用部署方案

图-高可用部署

container platform supports a multi-level high availability design, without any single point of failure, ensuring the safety and stability of the business.

3.6.2.1 容器的故障恢复

一旦服务器发生故障时，
平台系统会在其他服务器上自动重新启动容器，并为其分配资源，
从而实现秒级重启，
确保业务持续运行，
实现高可用性运行

3.6.2.2 镜像仓库的可用性

经过对单机版的镜像仓库进行升级为集群形式，并在 Registry server pool 实现了负载均衡。这不仅提升了性能水平，并且显著增强了其可用性。成功实现了注册服务器的无状态设计。

图-镜像仓库高可用

3.6.2.3 容器的可用性

该系统设计通过严格保证不同Docker容器间的应用实现完全隔离，并通过严格的通信流量管理和权限控制实现全面管理。采用经过数字签名认证的Docker镜像能够保障系统的可靠性，并且系统内的资源分配受到严格限制。同时设计具备抗干扰能力，在不影响其他Docker容器的情况下依然能够提供稳定的服务运行环境。

3.6.2.4 集群管理主机的可用性

平台旨在提升 Kubernetes 集群的整体可靠性，在每个计算节点部署守护进程以确保集群稳定运行。这些守护进程负责定期地进行检查，并一旦检测到相关服务出现故障，则将该计算资源标记为不可用状态。在必要情况下, 系统将按照既定程序启动修复流程，并重新部署所有服务以恢复集群功能。

图-集群管理主机高可用

系统设计能够支持跨越地域和数据中心网络部署云服务功能，并具备数据中心级别的高可用性

图-容器平台集群高可用

依据高可靠性的架构设计（...），容器平台有能力支持用户持续不断线的服务系统：

◼ 系统可用度：不低于 99.999%；

◼ 采用集群或双机冗余设计，不存在单点故障；

为了提高系统的可靠性，在容器环境中运行的应用程序与其他容器中的应用程序之间实现了严格隔离状态。当服务器发生故障时，平台系统会通过主动式管理机制，在其他服务器上自动重新启动相关容器并进行资源分配配置操作，并在必要时触发业务重试流程以确保服务连续性；该系统通过部署多容器实例负载均衡策略以及弹性伸缩功能等技术手段，在所有情况下都能保证运行在平台上的应用程序 containerized applications 的系统可靠性指标达到至少 99.999% 的高可用水平；

镜像仓库的服务可访问性和可靠性均较高。通过集群架构实现服务保障机制,确保服务可靠运行。该系统的服务可靠性达到 99.999%

支持集群管理主机的可用性方案的应用, 确保集群管理服务稳定运行

3.6.2.5 平台组件备份设计

容器平台具备全面的.backup功能,涵盖节点配置数据及相关文件;包含元数据库.backed up;涉及服务注册模块;包含认证证书;覆盖应用镜像存储库;包含代码存储库;实施数据库复制过程;执行核心表的数据恢复操作;涵盖特定时间点的数据保护措施;实现操作系统数据的全量还原过程;完成应用程序及中间件的完整复制操作;实现系统配置文件的全面还原操作;并保存详细运行日志信息

该容器平台推荐的存储备份方案存储的数据具有数据完整性的特点。这意味着当整个集群处于完全不可用的状态时,可以通过存储备份的数据完整地恢复集群,其状态与备份时刻的一致,具体包括平台组件的状态、业务应用的状态以及源代码的状态等信息。

1）备份数据完整性：

容器平台完整的备份如下数据

◼ 系统的各种类型的证书。

◼ Etcd 中存储的所有应用的元数据 （服务注册、 应用配置、 环境配置等） 。

◼ Master 和 Node 的配置文件。

◼ 镜像

◼ 源代码

2）备份方案如下，可以通过 Ansible 配置成定时任务：

恢复方案如下：

3.6.3 总体设计

图-总体设计

3.6.3.1 平台部署

3.6.3.2 部署架构说明

主网络区域A：在内网区域内安装容器管理平台（主要功能），集成主数据库，并负责管理A区域内的Kubernetes集群以及备机房B的Kubernetes集群

备用机房B：在内网区安装备用容器管理平台port（备用），连接到本机数据库（备用），纳入管理该备用机房B内的K8S集群。

应用采用备用入口，在备用机房进行同步发布；而无需依赖灾备的系统，则通常仅通过主入口在主机房进行发布。

3.6.3.3 负载均衡设计

通过基于 DNS 的智能解析机制，在多个数据中心之间实现流量负载均衡与资源冗余。该系统的核心思路在于动态维护多台备用数据中心对外提供访问接口，并根据预设算法为每位用户提供最优匹配的目标访问接口。当某一台数据中心的服务端口出现故障时，系统会立即停止为其提供通信连接，并将后续请求自动路由至仍保持正常服务状态下的备用服务器以确保网络可用性。这种设计不仅能够有效提升网络的整体抗跌 gracefully,还能最大限度地减少服务中断对业务的影响,从而实现稳定的业务运营水平.

内部负载均衡建议使用平台配置的软件负载均衡器支持。

在主备方案实施时，默认情况下负载均衡器会将所有请求路由至主数据中心；仅当主数据中心发生异常无法提供服务时，则会自动切换至备用数据中心进行处理。

互联网中的访问流量，在发生主数据中心整体故障时，则会依次经过DMZ以及防火墙等网络。这些流量无论是来自主数据中还是备数据中，在经过DNS处理之后进入了备中心用于云互联及外联连接F5负载部分，并按照应用部署架构流向相应的Web服务器，并最终提供内网的应用服务。

经过 DNS 处理后的内部网络流量将允许数据中心内部网络对灾备内网应用进行访问。这些经过处理后的内部网络流量将通过相应的 F5 加载器接入到灾备中心，并根据应用部署架构配置到相应的 Web 服务器和应用服务器上。

本方案建议选用F5或其他包含GTM功能的负载均衡系统；如无此配置，则需手动切换DNS

3.6.3.4 切换架构

通常情况下利用 DNS 域名访问主 portal 实现平台操作，在主数据中心 A 机房出现问题时：

◼ DNS 把流量切到 B 机房备用 portal、备 DB

◼ DNS 也切换到备用镜像仓库。

3.6.4 灾备实现

灾难备忘方案着重考虑了数据级别的备份、应用级别的备份以及网络切换策略。在数据层面,本方案依据数据类型特点,并采用主备机制,建议利用现有机制进行配置以确保数据一致性;从应用层出发,在满足应用类型需求的同时兼顾灾备策略,使整个系统能够实现多活与冷备功能,从而保障访问流量自动进行切断处理以确保服务可用性

3.6.4.1 数据备份

依据采用的数据库类型制定基于不同层次架构的容灾备份策略，在单个数据中心部署主库层，在另一侧数据中心配置为备用库层，并采用基于存储引擎的技术实现异步数据同步与恢复

数据备份方案如下：

3.6.4.2 应用层备份

主要实现了多数据中心的应用同步部署及主备运行的服务保障工作。其中在应用层的主要服务保障工作主要依靠应用层方案的一致性安排

在容器云架构中：基于 Docker 容器, 推荐采用‘多集群应用统一管理’方案, 实现跨数据中心的应用集中部署及灵活迁移。企业用户可通过统一的‘多集群应用管理入口’创建并运行应用程序。系统会自动将应用程序划分至各集群并独立部署, 平台持续监控各集群中的服务状态并实时更新负载数据。多集群服务统一管理页面如下：

图-集群服务统一管理页面

图-集群管理页面

基于新环境建设规划，并结合容器平台设计的数据信息，在分析容器平台设计数据的基础上选择适合的数据备份方案，并详细制定相应的数据备份策略与实施步骤。

冷备应用实现说明：

当多个集群完成发布后，在这两个集群中分别标记为主机和备用，在这种情况下，主应用能够保持正常运行状态；同时备用应用的副本数量自动归零，并处于关闭状态

备应用按照定时任务配置每隔一小时运行一次，并持续监控主应用的状态信息。一旦检测到主应用出现异常情况，则会自动启动相应的服务容器以进行修复。

建议推荐使用双活 NAS 配置策略，在没有相应配置的情况下，则必须依靠脚本配置来实现定期定时地同步相关数据。

3.6.4.3 平台灾备说明

容器平台 Portal 的故障不会对容器平台发布的应用产生任何影响；由此可见, 容器平台 Portal 的恢复优先级处于较低的位置。

备用数据中心启用后,不建议在其上进行应用的创建与发布操作,主要用于查看处于发布状态的应用相关信息.一方面,这种做法旨在降低容器平台Portal上数据的一致性差异,从而减少不必要的回切工作.另一方面,由于主数据中心Kubernetes集群此时仍处故障状态,无法对已经失效的主数据中心中的任何Kubernetes集群执行新申请或部署操作,因此所有相关功能都仅限于查看状态信息.等待主数据中心恢复至正常运行状态后才能通过该平台完成相关功能的重新激活.

3.6.4.4 回切场景

主数据中心恢复后，通过完成以下场景的回切主 portal：

4 方案价值

容器技术在云计算领域的快速发展源于它对标准化的支持，在这一过程中其标准化能力使其成为云计算领域的核心。其关键优势在于实现了对云服务的统一规范，在这一过程中过去传统的应用架构往往将功能整合在一个实体中；而今随着容器时代的到来，在这一新的架构下应用软件通过模块化设计实现功能分离并以独立的组件形式存在；这种转变不仅提升了系统的灵活性还显著提高了资源利用率与扩展性

图-应用的标准交付件

这一项IT方法论带来了根本性的变革，在实现应用软件生产和运维流程的标准性和模块化处理的同时也提升了效率水平

将企业 IT 分为应用开发阶段和上线后两个阶段，则容器为企业 IT 转型提供了两大核心能力：一是快速实现功能并适应快速变化的需求；二是优化运维效率。

4.1 IT 交付新能力

IT 交付新能力-持续交付和持续创新

随着互联网与金融深度融合的发展趋势出现，在这个背景下推进金融IT革新面临着诸多挑战。其中最突出的困难在于如何加快更新节奏以迅速满足用户需求，并以此作为衡量企业互联网化程度的重要标准之一。然而，在传统软件开发模式下企业产品迭代速度始终难以跟上时代需求。这种模式下各个阶段职责分离导致各自负责不同的交付内容：开发者输出代码 测试人员提供测试包 运维人员则负责部署运行环境 在这样的协作机制下 软件系统的迭代能力已经达到了极限 无法有效应对互联网融合时代对快速迭代的迫切需求 此外 由于开发测试环境与生产环境之间的不一致 导致统一管理成为难题 存储安全风险也随之而来

Docker 的诞生打破了传统软件部署模式的技术瓶颈，在推动应用快速迭代方面开创了全新思路。通过容器技术实现云服务的一体化部署，在各个应用场景下都能满足需求：从开发到测试再到运维各环节均需提供容器镜像，并通过公共存储空间进行协作。在项目周期中，在产品发布阶段需完成模型更新与新版本提交，在项目上线阶段，则由运维团队负责容器架构规划与日常维护工作。这种标准化使得整个软件生命周期更加协调一致，并显著提升了系统性能表现

4.2 IT 架构新能力

IT 架构新能力-混合云+微服务架构

在烟囱式 IT 架构转向混合云架构的过程中（或：转型过程中），有两个关键点：首先是从大而全的整体架构升级至灵活的微服务架构；其次是从专用计算资源转向分布式架构。

随着 Docker 等容器技术的出现，在烟囱式 IT 架构转向混合云架构的过程中发挥了无与伦比的作用。其中一项关键举措是 Docker 对微服务架构的支持。微服务架构具有高度多样性，在经过切分后可形成独立的功能模块，并由不同团队独立开发维护这些模块的同时还可以采用多种编程语言实现功能开发这也加大了系统运维工作的难度。然而 Docker 容器通过统一的方式将各模块封装成标准镜像文件从而实现了自动化运维流程的巨大简化。此外在应用部署中采用容器镜像形式后这种模式下构建大规模分布式系统及其运维变得更加简便易行

4.3 IT 运维新能力

IT 运维新能量-高效运维

高可用性是金融行业IT运维领域始终无法回避的核心议题。在"互联网+"时代背景下,用户体验的重要性日益凸显,其中服务的可信赖性和稳定性自然成为衡量系统性能的关键指标之一。如何有效保障复杂IT环境下的系统稳定运行,已成为当前"互联网+"背景下推动金融IT革新的一项重要课题。互联网时代的核心IT运维理念在于:任何一个单独的IT系统都有可能面临不可靠的风险,因此,运维的关键就在于从分布式系统的管理软件层面构建持续可靠运行的保障机制。基于容器架构设计的理念,通过优化资源分配策略来提升系统的容错能力已展现出新的技术潜力。这种基于容器架构的设计理念强调了其轻量化特性及其快速启动的优势,从而为分布式系统提供了更加可靠的运行保障。