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

导读

导读

目录

1. 背景概述

2. 现状及分析

2.1 IT 研发转型

2.2 IT架构转型

2.3 IT 运维转型

2.4 IT 组织转型

3. 建设方案

3.1 容器平台建设

3.1.1 容器可编排性

3.1.2 容器平台可扩展性

3.1.3 安全合规性对接

3.2 统一知识库

3.2.1 建设目标

3.2.2 建设方案

3.2.3 知识分类

3.3 统一制品发布

3.3.1 方案架构

3.3.2 代码版本管理

3.3.3 自动化测试

3.3.4 打包构建

3.3.5 运行环境

3.3.6 持续部署

3.3.7 制品交付

3.3.8 合规性检查

3.4 统一资源申请平台

3.4.1 自助资源申请服务

3.4.2 在线审批流程

3.4.3 自动化部署

3.4.4 自助运维

3.4.5 自助监控告警

3.4.6 租期回收

3.5 容器统一规范

3.5.1 容器内应用的健康检测

3.5.2 应用容器的DNS配置

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

3.5.4 应用容器的日志配置

3.5.5 集群资源管理规范

3.5.6 投产审核

3.5.7 自动化运维

3.6 高可用架构体系

3.6.1 方案概述

3.6.2 高可用部署方案

3.6.3 总体设计

3.6.4 灾备实现

4. 方案价值

4.1 IT交付新能力

4.2 IT架构新能力

4.3 IT运维新能力

1 背景概述

未来五年的发展重点是科技创新被视为推动国家发展的核心引擎，并将为此付出持续努力以构建现代化经济体系作为重要战略目标。在当前科技快速发展的背景下

在数字时代背景下，金融行业面临着数字化转型的关键挑战。容器云原生技术被选定为构建数字经济基础设施的核心支撑，并采用与公有云相同的架构和技术方案，在统一的技术生态体系框架下保障金融机构的数据权益和行业监管要求的同时，快速获取大数据、人工智能、数据库等新型云服务能力。这种 setup 满足了"安全可靠+应用创新"双重诉求，并通过容器云原生上的数据治理能力构建统一的数据治理机制来挖掘数据价值；同时利用其上的人工智能开发平台持续积累训练数据集、算法模型以及知识图谱来储备人才并探索前沿科技；最后通过应用管理、微服务建设和 DevOps 技术推动人工智能技术在金融领域的深度应用，并显著提升了系统开发和生产效率。根据各金融机构的具体情况制定解决方案以实现混合云部署目标并引入先进云服务支持灵活创新

2. 现状及分析

银行的业务应用目前主要通过多种形式部署在各自的技术架构中。这些架构主要涵盖互联网技术栈以及商业技术栈两大类。多数系统已实现对最新一代系统的全面升级，在这一过程中取得了一定成效。然而，在容器技术的持续演进推动下，越来越多的金融机构开始尝试推进基于分布式架构的应用体系改造。

考虑到银行交易的重要性不容小觑，在选择适合云原生容器化改造的系统时应当优先考虑最佳选项；而经过改造后如何与现有规范相协调的问题也随之显现出来。

对于那些对容器技术缺乏经验或仅浅尝辄止的研发团队而言，在接受新技术时会遇到较高的学习成本以及较大的改造难度等挑战

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

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

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

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

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

受互联网与金融深度融合及自主可控战略的推动，在中国金融IT领域掀起了全方位变革浪潮。传统的IT流程、基础架构以及运维模式已无法满足业务发展的新需求与产业格局的变化，在此背景下，各大传统金融机构纷纷开始探索未来IT开发模式与架构体系的具体路径。

2.1 IT 研发转型

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

互联网思维的核心在于快速反应，在激烈的市场竞争中唯有能够迅速回应用户所需方能占据先机。随着互联网+时代的到来，在金融行业的信息化建设中实现这一目标的关键在于构建适应业务需求变化且具备灵活性的IT架构以满足不同部门、客户及合作伙伴的需求。然而传统的方式已经制约了应用交付效率IT研发流程仍需优化。

2.2 IT 架构转型

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

在IT基础架构层面，大多数金融机构采用烟囱式架构设计，并认识到此类架构的主要问题是系统间资源无法共享。同时，在金融行业向普惠模式转型并积极拥抱长尾市场的过程中，传统金融IT架构已经难以满足海量长尾客户需求。随着互联网+战略的深入推进，IT基础架构必须具备更强的弹性能力以支持互联网业务所需的弹性伸缩需求

由此可见 云计算作为IT系统发展的大势所趋。许多金融机构已认识到分布式架构转型的重要性已日益凸显。然而当前大多数架构转型方案都需要承受阵痛期带来的挑战 令它们对云计算基础设施的发展步伐顾虑重重。他们迫切亟需一套能够实现无痛且渐进式的云计算迁移方案

2.3 IT 运维转型

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

该团队面临巨大挑战之大众所共认,这一状况源于金融行业对业务连续性和可用性的极端重视.然而,随着信息技术的不断发展进步,当前的金融IT环境呈现出日益复杂的局面:系统应用错综复杂、IT架构呈现出多样性、系统规模不断扩大,这些问题正迫使其不得不开发出一套全新的运维策略来应对日益复杂的IT环境带来的挑战.

2.4 IT 组织转型

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

互联网企业业务拓展与产品研发强调快速响应。在这一过程中追求的是业务交付速度、频繁迭代以及近乎实时的用户体验反馈；研发部门、运营团队等组织架构的设计中也充分考虑了上述特征所要求的目标属性与实现路径。金融行业始终将安全置于首位，在互联网快速发展的背景下如何实现高效发展的同时兼顾安全？如何通过优化组织架构，在利用先进技术保障安全的前提下，在运营环节提升效率并精简流程？这些问题不仅考验着金融行业管理者的智慧水平，在决策层也需要进行深入思考以应对这一挑战。

3 建设方案

3.1 容器平台建设

容器技术在金融行业的应用极为普遍，在从开发测试环境延伸至生产部署阶段的全生命周期中都能见到其身影。基于Docker等先进容器技术的支撑，在金融IT系统建设和业务转型过程中开创了全新的业务转型范式。

基于容器技术的应用场景分析显示，在线运行于云端且可从中获益于DevOps与微服务模式的应用场景非常广泛

3.1.1 容器可编排性

容器云平台的技术架构应当遵循云计算发展的新趋势，并以支持分布式应用为目标。在实现这一目标的过程中, 采用适合容器管理和组织管理与调度（Orchestration）工具显得尤为重要. 初级阶段的资源编排, 即针对物理机或虚拟机进行资源分配, 是整个架构的基础; 而高级阶段则是服务层面的组织与配置, 需要形成一个完整的体系结构.

Docker 技术针对的对象是一个单一的应用程序；然而，在真实的企业级云环境中,工程师面临的挑战是如何将数百类应用组成的综合系统,部署到成千上万的具体实例中. 显然,人工操作这种规模的工作量及其高昂的成本与潜在的风险是难以承受的. 因此,一种专门用于管理和调度海量容器在其生命周期内各种管理事务的编排技术就显得尤为必要. Kubernetes 已成为企业级云计算环境中广泛采用的事实标准.

Kubernetes 其名称源自古希腊文明，并译自希腊文 κόσμε 意指 '秩序' 或 '治理'。若将 Docker 比喻为一艘巨轮，则 Kubernetes 即为其指引方向的专业水手，在茫茫大海中引领 vessel 按照预定航线行驶。

Kubernetes是由Google开源项目Borg的发展而来的 container cluster management system, and it was donated to the Cloud Native Computing Foundation (CNCF). Its main functions involve:

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

负载均衡和服务发现；

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

容器负载自动伸缩；

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

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

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

如上图所示，
Kubernetes 采用符合 YAML 标准的配置文件格式来说明 Kubernetes 内部允许的所有资源类型，
涵盖 Pod、Deployment 和 Service 等关键资源类型。
其中，
Pod 作为核心调度单元，
通过组织一组紧密关联且共享网络与存储设备的 Container 集合，
为 Kubernetes 提供各项应用服务功能，
定期更新其生命周期信息并接受 Kubernetes 的管理与控制。

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

该系统成功应对了大规模应用运维带来的规模性挑战，并通过自动化技术实现了海量应用的组织调度和运行维护。

采用简单的声明式语言（如YAML）来完整地表示应用的拓扑结构和运行周期，并消除了Dockerfile在限定环境中无法完全表征系统需求的局限性；同时实现了对系统架构从代码层面逐步演进至服务部署阶段的完整表征

采用实时弹性扩容方案的应用场景中无需经历申请资源至负载上线的复杂流程。该方案能够从容应对流量高峰，并充分释放了Docker的强大功能。

通过优化流量切分与发布策略的协同工作, 保证持续交付能力; 有机整合精益管理理念; 为DevOps实践的有效落地提供支持;

开放 API 支持多样化的第三方网络及存储解决方案的能力，并且能够确保企业用户在生产过程中获得所需的技术支持。

构建基础抽象环境，并采用标准化的镜像和编排策略；对于大型应用场景同样能够随时进行迁移；无需担心会被外部系统所束缚。

除了功能支撑之外，在企业级平台选型时需重点关注编排引擎所承担的核心调度能力实现技术。该技术必须具备长期扩展潜力以满足企业业务增长需求。基于Kubernetes平台设计，在单一集群环境下最多可支持5千个节点部署，并能够处理1.5万至3万个容器组规模；同时通过集群扩展能力的提升，在生产规模支撑角度来看完全能够满足企业的未来长期发展需求。

Kubernetes本身具备了一组容器定义的对象Pod的功能模块，在包括运维效率弹性运行调度性能以及服务接入等方面展现出显著的能力。它通过接口驱动的方式为所有差异化的外围服务提供了支持体系具体包括Container Runtime Interface用于运行环境管理Container Storage Interface负责数据存储以及Container Network Interface实现网络通信整合功能。

图-Kubernetes 的 Interface 设计模式

针对一些特殊的场景，在这些情况下由于原生内部定义的资源对象（如存储类型等）无法满足企业的具体需求时，则可以通过Custom Resource Definition（CRD）这一机制来构建新的扩展型资源定义接口，并使Kubernetes平台的开放性和可扩展性得以进一步提升。

图-CRD 原理

基于这一设计，在面对各种容器运行时、网络、存储实现以及特殊的资源形态要求时，在不修改原有核心功能的前提下，Kubernetes均可通过扩展驱动机制实现有效兼容。换言之，在Kubernetes的兼容性设计中起决定作用的并非其对特定资源实体的操作能力，而是如何操作这些作为中间件的驱动程序——这使得Kubernetes成为一个高度通用且灵活运用的抽象概念。基于这一架构设计的特性，则赋予了Kubernetes与生俱来的可兼容性。只要下游环境在不修改上游代码的前提下实现了对Kubernetes的一致性支持，并行部署即可无缝衔接并发挥协同作用。

Kubernetes 已经被广泛认为是事实上的容器管理标准，在全球范围内几乎每个企业都采用它作为容器管理和编排方案的基础架构。该系统具有一些显著的优势

开源的力量

随着容器应用领域的不断扩大，在事实意义上已经成为了行业标准。
由于这一技术的重要性，
您可以依赖多个服务提供商来支持其部署。
当遇到任何问题时，
Kubernetes 开发者的开放社区期待采取正确的措施。
然而，
这是一个不是仅仅开源后就停滞不前的项目，
而是每年都会发布四个大版本以保持活跃度的持续发展型项目。

成本效益

相比虚拟机（VM），容器具有较低的配置复杂性和占用空间量。 container management systems offer a simpler and more flexible approach compared to virtual machines. 通过Kubernetes实现对容器化的高效管理，在资源利用率方面同样表现出色。 通过优化配置减少错误的CPU周期以及内存消耗（RAM）, 进一步提升了系统的响应速度与稳定性。 此外,凭借其强大的负载均衡引擎, Kubernetes能够根据需求动态启动、停止以及优先调度各个容器,这些功能均能保证系统性能的一致性。

可移植性

基于其多功能性,Kubernetes能够在一个组织内部本地部署并在众多底层操作系统上运行。进一步而言,如果决定迁移至备用的操作系统环境,您无需额外调整现有工作负载配置,即可无缝整合新系统。Kubernetes通过防止供应商锁定问题,将帮助您实现随着时间的推移将逐渐趋于标准化,并逐步简化管理流程的目标。

可扩展性

Kubernetes 基于模块化设计专为容器管理和工具整合而生，在此框架下您可以灵活组合各种组件实现完全定制化的部署方案. 您可以通过配置选择最适合的应用操作系统以及应用运行时 Libs / Bins 配置文件系统处理器架构甚至云端服务. 应用程序开发者不仅能够访问 Kubernetes API 还能通过其API接口加强应用程序间的集成从而提升性能并优化管理体验.

自愈

软件偶尔会遇到异常情况（如功能失效或系统崩溃）。尽管如此，在大多数情况下您仍能继续使用服务。但是请不要担心：Kubernetes 具备强大的监控能力，并能实时监控整个基础设施配置（包括容器、节点、Pod、网络设备、硬件与操作系统）。当软件出现问题导致部分服务中断时,Kubernetes 会迅速恢复服务运行状态;而如果是由于硬件问题造成的故障,则会被检测并分配至多个 pod 运行,从而最大限度地减少停机时间

云服务

由于Kubernetes备受欢迎,因此用户无需自行管理内部功能,也无需投入硬件成本。然而,实际操作中,用户可以选择通过注册托管的 Kubernetes 解决方案来进行 PaaS 或 IaaS 部署,其主要职责是致力于通过用户的应用提供最佳体验,并将负载均衡和云服务工作分配给 Kubernetes 负责管理。

基于以上分析, 针对容器管理和编排技术的建议方案是采用Kubernetes技术. 该方案参考开源社区的版本更新规划, 并结合行业内的最佳实践进行设计与优化. 官方推荐采用Kubernetes 1.16及以上稳定版.

容器平台提供应用于编排部署的应用 visualize 管理功能，并涵盖拓扑架构图视界、组件配置视界以及系统参数设置三个核心模块。在上述基础上，容器平台还集成了一系列常用平台组件及服务（如F5设备、数据库存储与访问端口映射等），并具备相应的封装能力。这些集成化的解决方案能够帮助用户完成对各个组件进行配置参数设置以及整体架构规划等功能的支持

该系统具备完整的应用模板管理功能，并支持多种操作流程。容器平台通过丰富的管理能力实现以下功能：允许用户创建新的应用模板，并根据需要删除或修改现有模板；支持显示并编辑模版描述内容；显示模版与其关联的应用信息；提供从模版部署应用的指南；允许对不同类型的模版进行分类管理和快速查找。

应用编排管理

在应用配置管理方面：容器平台能够支持对应用进行日志记录、服务端口号设置以及多种配置参数的管理。

容器信息查询:基于应用系统的维度进行管理与监控, 可实现对应用中的各个关键指标进行深度查询, 包括但不限于容器名称及其所属宿主机的相关配置参数, 软件版本号, 当前运行状态等基础数据. 此外, 容器平台还能够提供更为详实的信息, 涵盖镜像层次结构数据, 历史变更记录以及与资源相关的元数据等.

容器操作功能:在编排功能下, 容器平台支持一系列常用的应用容器操作功能, 包括启动、停止、创建与删除等基础操作.此外, 为了方便企业级用户的日常管理, 容器平台还提供了更为全面的功能包, 具体包括从容器内下载本地化文件、通过网络向容器传输文件以及支持打开容器内部 Shell 控制台界面. 同时, 用户还可以借助平台工具一次性生成新镜像并实现对容器的重启、暂停与恢复功能. 在不影响现有服务连续性的前提下, 用户能够灵活配置容器资源配额设置.

在‘负载均衡展示’模块中, 该容器平台内建了负载均衡功能, 并能呈现应用的整体负载状况; 此外, 在线支持对接如 F5 这类外部的负载均衡设备; 不仅提供应用级别的自动平衡配置选项, 并且能够辅助处理微服务架构下的资源分配问题

容器服务的自动负载分配由平台本身预设使用Linux内核中的LVS技术管理。相较于其他软件解决方案而言该平台在负载均衡方面表现出优异且支持配置SSL证书以确保通信安全性。随着容器服务数量的增长该系统能够实时感知服务数量的变化并根据需要调整负载分配策略从而实现动态平衡资源利用率。此外平台提供了灵活的负载均衡策略可依据特定需求通过环境变量进行参数设置以实现特定策略同时保留会话功能以确保数据一致性

在版本更新过程中：针对企业级应用环境

3.1.1.1 多模式应用编排

3.1.1.1.1 应用容器编排

该系统平台具备应用可视化的编排部署管理功能模块, 包括拓扑图示化展示、组件分组布局展示以及关键配置参数呈现等功能模块. 在上述基础之上, 该系统还能够对F5负载均衡设备、数据库存储资源、DNS resolver服务以及软件负载均衡组件进行标准化封装, 实现对其配置参数设置指导以及分组布局规划支持. 该系统支持实现的编排管理功能包括:

该系统具备生成新应用模版以及撤销或更新现有应模版的能力。与此同时, 云原生技术平台管理系统提供了更为丰富的能力, 包括但不限于导入多个应模板文件, 实现增删改操作; 同时提供展示及编辑应模板内容的功能; 并能直观体现模块间的关联关系; 同时提供从模块部署的应用指导; 最后还支持模块间的分类管理和搜索功能。此外, 模板功能还能够验证公共或私人模块的存在, 并根据需求配置模块访问权限

应用编排管理：该平台具备强大的应用编排功能。它不仅兼容多种周边系统配置（包括但不限于数据库和F5设备），同时提供了更为完善的编排管理能力。例如支持Kubernetes YAML编排出队列、提供直观的编排展示界面、管理和维护基础架构资源（如日志策略和调度策略），并允许用户通过图形化界面进行编辑和维护。

应用配置管理: 云原生技术平台管理系统能够为服务安排部署应用程序日志记录以及服务接口等配置参数。

容器信息查询

该系统提供的基于编排功能的云原生物态平台管理系统的内置功能模块涵盖了企业应用中常用的 Docker 容器操作权限基础设置。
其中包含启动 Docker 容器以运行应用程序，
停止 Docker 容器以释放资源，
创建新的 Docker 容器以部署新应用，
删除已部署的 Docker 容器以清理资源。
此外，
该系统丰富了基础权限配置，
支持在云端存储的文件实时同步至本地设备，
允许企业用户将本地设备中的文件实时同步至云端存储空间。
系统还内置 Shell 控制台界面，
并允许用户通过该界面执行基本命令。
此外，
系统还支持从 Docker 容器一键生成新的镜像版本并自动生成镜像仓库地址，
提供重启停机以及资源配额调整的功能选项。
这些设置均能在不中断当前应用服务的情况下完成相应配置参数设置修改。

负载均衡展示功能:云原生技术平台管理系统内建的负载均衡功能,支持实时监控应用整体的负载分布情况.该系统不仅兼容多种如F5等外部设备,还具备按应用层级分配资源的能力,特别适用于优化适用于微服务架构的应用环境.

该系统通过云原生动态分配负载的技术实现对容器集群的服务分布与调度管理。相较于传统软件架构，在处理负载时展现出显著的优势，并且这种均衡机制支持配置SSL证书以增强安全性。当容器服务规模扩大时（随着容器服务规模扩大），该机制能够自动感知并适应后端服务的变化情况，并提供多种负载均衡策略可供选择。这些策略可通过特定环境变量进行参数化配置，并提供会话保持功能。

版本管理/灰度发布：在企业级应用的发布场景中，云原生技术平台管理系统支持在应用版本升级过程中对各个集群实施灰度升级以确保业务在升级期间的连续运行。此外，在该系统中还提供了更为高级别的灰度发布功能例如：配置并行发布的实例数量；制定处理发布失败时错误的具体机制；以及设置旧版本实例在部署过程中优雅地下线。

3.1.1.1.2 应用混合编排

在现有应用开发流程中，在提升研发效率的目标下，相关部门会预设部分数据库服务用于测试阶段。具体来说, 基于不同研发业务需求, 数据库服务种类主要包括 Oracle 服务器,MSSQL 服务器以及 DB2 服务器。

随着业务量的增长, 相应的研发生产线上呈现出多样化的发展趋势, 对研发测试部门提供的数据库服务也面临着日益繁重的压力. 在当前环境下, 研发测试部门正在面临申请数据库服务流程周期较长的问题, 各相关研发生产部门对数据库服务部门提出了更高的交付需求.

该平台采用了基于公有云的数据库编排模式，并通过实际应用验证获得了显著成效。其主要具有以下几项特点：首先，在架构设计上实现了资源的弹性扩展能力；其次，在性能优化方面采用了分布式缓存机制；最后，在安全性保障方面配备了多层防护措施。

当相关数据库准备好后,可以通过WEB页面的操作流程完成该数据库的服务注册,供研发测试团队使用.根据需求可以选择不同类型的数据库（例如Oracle、MSSQL或DB2）进行注册,涉及以下几种主要类型： Oracle、MSSQL 或 DB2 数据库.

服务管理:该系统提供Web界面支持对已注册的数据库服务进行管理功能。涵盖以下管理操作:新增数据库服务配置项、移除现有配置参数设置、修改现有配置值以及取消已授权的数据库连接请求。

服务绑定: 通过应用界面, 可实现数据库服务与应用容器之间的关联. 该过程不仅将数据库的服务实例注入到容器中, 还会将其相关信息配置为 container environment 的参数, 方便后续访问.

服务发现

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

图-混合编排架构图

该系统实现了云原生技术和数据库资源的深度整合，并通过插件形式嵌入到云原生技术平台管理系统的后台架构中。通过对接权限控制模块，该系统能够实现对特定用户的访问控制。基于 API 授权机制，系统能够精准分配权限以确保数据访问的安全性。

3.1.1.2 负载均衡

该平台管理系统可提供两种负载均衡方案：7层和4层架构，在不同应用场景下应选择合适的方案。该系统的负载均衡方案架构图如下所示：

图-负载均衡

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

基于云原生架构的多容器系统管理平台的4层负载均衡IPVS机制主要用于弹性伸缩的应用场景，在该系统中通过端口转发技术，在弹性伸缩模式下将请求自动分配至多容器进行处理，请参考下图了解具体应用情况：

为当前场景预设了基于IPVS的负载均衡方案

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

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

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

Docker 内置机制

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

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

自动适配后端应用变化

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

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

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

云原生技术平台管理系统基于IPVS平台之上提供了7层负载均衡组件如Nginx HAProxy和Traefik等这些组件能够通过动态获取集群中各服务的域名配置信息目前该功能主要依赖于服务标签实现了自动化的负载均衡转发策略

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

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

友好的图形界面管理能力

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

高性能请求转发

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

自动适配后端应用变化

优雅的中断 HTTP 连接

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

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

提供简单的性能监控报表

HTTP2 支持

Websocket 支持

HTTPS/SSL 支持

3.1.1.3 存储管理

3.1.1.3.1 数据持久化

生成的数据不会被包含在当前的运行环境中。通过重置该存储空间并重新启动新容器会导致创建一个新的存储空间。为了更好地管理访问权限并确保安全起见，在每次重启时都会引入一个新的读取/写入层以便更好地管理访问权限并确保安全起见。如果想做到数据持久化，则必须寻找其他解决方案来实现持久化的存储机制。

该系统采用体积（volume）实现对Docker容器数据的持久化存储；这些存储类型包括本地硬盘（local disk）、远程硬盘（remote disk）以及快照（snapshot）。其中本地硬盘是直接映射到本机磁盘的；而远程硬盘及快照则需在集成中心配置并接入第三方存储服务（如ScaleIO），方能正常运行。

本地存储卷: 本地卷在容量与读写性能方面无限制（其上限由磁盘规格和性能决定）。本地卷无法生成快照。通常情况下，在构建应用程序时，应使用 Compose YAML 指定配置文件名。

远端文件系统：远端文件系统的建立及使用流程与本地文件系统具有相似之处。该系统管理模块下的远端文件配置主要包含基于NFS协议设计的独特配置项及其他类型的支持方案。在构建基于NFS协议的远端文件系统时，则需确保硬件设备具备相应的访问权限并记录相关参数信息。此外，在支持ScaleIO等先进数据管理和复制功能的场景下，默认配置会包含REXRay驱动式的远端文件系统和VMDK类型的虚拟磁盘配置方案

3.1.1.3.2 数据持久化保护与恢复

云原生技术平台管理系统负责维护存储卷的快照副本。通过访问ScaleIO的详细信息页面, 您可以看到该系统提供的快照生成功能。

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

云原生技术平台管理系统为...提供了一套界面设计...支持快照恢复操作。访问快照详情页面后即可执行复原操作:

3.1.1.4 网络方案

云原生技术平台管理系统能够全面兼容Kubernetes的各种网络方案。任何满足CNM模型要求的网络插件均可通过该系统接入以实现容器间网络通信。目前该系统已内建支持Flannel和Calico等技术，并可通过扩展插件功能来支持Macvlan网络。

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

3.1.1.4.1 Calico

Calico 是一种基于三层架构的数据中心网络方案（无需上层架构），并且与包括OpenStack、Kubernetes、AWS、GCE在内的IaaS及容器平台均实现了良好的集成。该方案通过在每个计算节点部署Linux内核来实现高效的vRouter功能，并由每个vRouter利用BGP协议将自身运行的工作负载路由信息传播至整个Calico网络。这种设计确保了所有工作负载之间的数据流量最终通过IP路由的方式完成互联。此外，在节点组网时可直接利用数据中心现有的L2或L3网络架构（无需额外引入NAT设备、隧道技术或-overlay网络）。

此外

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

Felix和CalicoAgent主要负责配置路由及ACLs等信息以确保Endpoint的连通状态

etcd是一种分布式关键值存储系统，在其运行过程中其核心作用在于维护网络元数据的一致性，并保证Calico网络状态的准确性。

BGPClient(BIRD)的主要作用在于将Felix的信息通过Kernel传输到当前Calico网络，并保证Workload之间的有效通信。

BGPRouteReflector（BIRD）是一种用于大规模部署的应用模式，在这种架构中不再采用传统的节点互联的网状模式；而是可以通过单个或多个BGPRouteReflector来实现集中化的路由分发机制

3.1.1.4.2 Flannel

Flannel以将宿主机每个分配一个子网的方式向容器提供虚拟网络。该方案基于Linux TUN/TAP协议，并通过将IP包封装在UDP协议中来构建上层网络。同时利用etcd管理平台来跟踪和维护网络资源的分配状态。

控制层上的host机器运行flanneld服务，在远程ETCD集群中获取本地及其它host机上的subnet配置信息，并将这些信息传递给相应的POD节点以分配IP地址。数据层面的flannel网络层通过Backend（如UDP封装）实现L3Overlay功能，在网络架构设计上支持两种不同的选择：传统的TUN设备或VxLAN技术。

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

udp:采用用户态 udp 封装，默认设置为 8285 端口。因为是在用户态进行封装与解包操作的原因，导致性能上存在一定的消耗;

采用vxlan标签封装的数据包需要设置VNI，并配置Port参数（默认值为8472）以及Gateway to Gateway（GW） tunnels的信息；通过主机GW进行直接路由的方式将容器网络中的路由信息直接更新至主机的路由表中，并且该方法仅限于二层网络之间可以直接通信的情况

3.1.1.5 弹性伸缩

3.1.1.5.1 弹性伸缩策略简介

弹性伸缩（AutoScaling）是一种基于不同业务需求与策略的机制，在优化资源组合方面实现了服务能力的最大化。该技术主要采用两种方式：自动伸缩和手动伸缩，在无运维干预的情况下即可对计算资源进行动态调整。具体而言，在访问量增加时提升计算能力，在访问量减少时降低计算能力；这种设计既能保证系统的稳定性和可靠性又实现了成本效益。

弹性伸缩技术在行业内分为两个主要方向：垂直扩展（ScaleUp）与水平扩展（ScaleOut）。从业务发展角度来看，在线服务系统通常更关注其水平扩展能力的强弱程度。这种能力要求系统具备无状态特性，在任何情况下——无论是增加还是减少计算资源——系统的连续性和稳定性均能够得到保障。

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

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

在弹性伸缩机制中, 该系统采用内置弹性伸缩引擎实现资源动态分配能力, 其针对不同应用场景提供高度灵活的扩展策略. 该系统现有方案支持从内存占用情况、CPU负载水平以及当前线程池剩余线程数量等多个维度进行资源规模调节. 如下图所示为系统的自动扩缩架构图

相对来说, 云原生技术平台管理系统平台的弹性伸缩功能相较于其他云原生技术平台弹性伸缩功能具备哪些特点?

采用容器化部署方案能够显著提升部署灵活性。作为云原生技术平台管理系统的模块之一，在实现资源分配时基于应用模板进行容器化部署。从而支持对各个服务实施独立且互不干扰的弹性伸缩策略。

伸缩策略具有高度的灵活性和可配置性。该系统采用弹性伸缩机制与应用实现了紧密耦合，并通过动态监控不同应用场景的具体特征及其运行表现来制定相应的弹性策略。云原生技术平台管理系统的弹性伸缩功能内置基于容器资源（如CPU及内存使用情况）以及中间件资源（如Tomcat进程线程数量及会话总数）的实时监测能力；此外，在实际应用场景中，用户可以根据具体需求自定义数据库并发控制参数、网络连接数量等关键指标。

该系统采用开放性接口设计，并具备高度的可扩展性特点。系统采用完全兼容 Docker 原生 API 的架构设计，并特别提供了相应的二次开发 API 服务。该系统中的弹性伸缩模块基于云原生技术平台管理系统的 API 独立开发而成，并支持根据不同业务场景灵活配置资源分配策略。若用户需基于平台进行深度二次定制开发，则可通过弹性伸缩模块实现功能拓展需求的满足

该系统提供南北向集成方案，并支持VMware与OpenStack良好整合，并实现虚拟机按需快速创建与有效管理

本平台不仅提供自动化的伸缩能力外，并且还支持便捷的手动伸缩功能。手动伸缩主要适用于以下几种情况：应用于需要灵活调整资源的情况，在无法设定明确的容器阈值以及无法进行收缩的情况下表现出较高的需求。通过管理系统的服务面板设置扩大和服务数量减少即可实现弹性扩缩的效果。

3.1.1.6 应用管理功能

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

该界面从应用开发到部署运行的全生命周期进行综合管理，并支持一键部署、基于镜像构建、YAML脚本编排以及基础镜像部署等多种配置方案。具体功能包括：应用启动态控制（启动/停止/下线/重新启动）、版本更新管理以及CPU资源分配（手动调整）、内存管理（手动设置）、实资源（实时监控）、应用镜像制作与存储（可自定义）、文件上传与下载操作以及文件重命名功能等。

部署方式

支持多种部署方案快速构建；通过镜像构建实现便捷配置；采用YAML编排确保配置准确无误；在基础架构下完成镜像构建

图-部署方式

应用基础功能

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

图-应用基础功能

版本更新

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

图-应用镜像版本更新

弹性伸缩

平台预设了弹性伸缩功能，并提供CPU、内存等阈值配置选项。基于设定的阈值条件自动调整资源数量，在达到阈值时会触发自动扩展或缩减行为。已部署的实例可通过标签机制实现负载均衡能力的接入，并借助拓扑结构展示当前资源在多个应用和服务中的关联情况。

图-弹性伸缩配置

图-应用拓扑

3.1.1.6.2 应用资源资源

平台提供了直观的界面来管理和配置应用资源；为实现这一目标，在应用的初始化和发布阶段提供了默认的资源配置方案；支持对已部署运行的应用进行资源优化配置，并涵盖如应用实例数量、内存分配、磁盘存储、路由设置等关键参数的调整

实现效果如下:

图-应用镜像版本更新

图-应用负载路由配置

图-自动配置路由信息

图-手动配置负载路由

3.1.1.6.3 应用状态查询

平台为租户提供一种便捷的方式（即"简单方式"），使其能够访问其发布的所有应用及其运行状态信息。这些信息包括但不限于应用程序运行状态、实例数量以及资源和服务使用情况等关键指标。此外, 租户还可以通过此功能获取相关应用程序的日志记录, 包括但不限于发布日志和运行日志, 以及其他各种类型的日志输出内容。对于平台管理员而言, 他们可以通过统一的Web界面全面查看所有相关应用程序及其对应的运行状态和日志记录信息。

实现效果如下:

图-运行应用信息

图-停止应用信息

图-日志信息

图-资源使用信息

3.1.1.6.4 配置文件

此平台支持基于配置文件实现对应用参数的管理功能，并支持基础配置方案与加密配置方案两类不同的处理方式。

图-创建配置-命令

图-创建配置-上传文件

图-加密配置文件

3.1.1.6.5 镜像工厂

平台配置了镜像工厂,该系统负责管理和维护多个独立的镜像仓库.集成了一个基于Docker的注册中心服务,该服务能够便捷地实现公有与私有环境之间任意版本的自由切换.系统还提供了完善的存储管理功能,能够将存储空间划分为个人账号或团队账号进行独立管理.根据不同类型的存储空间分别制定相应的管理策略或权限设置.系统支持根据规则自动完成镜像文件的远程复制操作,允许基于规则自动完成镜像文件的远程复制操作,同时也具备自动扫描与更新本地镜像库的功能模块.通过提供预定义的标准运行环境以及Java、PHP、Node.js、Ruby、Go、Python等多种语言的支持,用户可以根据需求定制更多语言版本及相应版本号.此外,系统还提供了丰富的扩展功能选项,包括但不限于自定义模板生成工具以及高级化定制化的工作流程设计能力.这些功能组合能够让不同场景的应用快速实现预期的效果

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

图-镜像空间设置

图-空间授权

图-镜像复制

图-基础镜像

3.1.1.6.6 部署管理

该平台采用统一镜像标准进行部署交付，在针对日常迭代变更的上线过程上采用了基于镜像作为管理粒度的具体方式，并实现了基础部署策略以及容器管理等功能的具体实现

实现效果如下:

图-应用部署

图-容器管理

图-灰度部署

3.1.1.6.7 应用商店

模块商店

在中心区域主要分为商品展示区和管理系统两大类，在展示区又设有预装组件以及根据客户需求定制的应用服务模块。预装组件则是基于自身能力预先配置的标准组件，在此基础之上可以根据具体需求进行个性化调整；而根据客户需求定制的应用服务模块则能够灵活满足不同场景的需求。按照分类标准为每个功能模块提供详细信息说明，并支持配置安装路径并生成相应的操作手册；同时支持对已部署的功能模块进行管理和维护，并能够对已部署的功能模块进行卸载操作；系统会自动生成相应的运维日志供后续查看；用户可选择待部署的功能模块进入控制台完成部署操作，在此过程中系统会自动生成相应的工作记录；完成部署后系统会自动生成相应的运维日志供后续查看

实现效果如下:

图- 模块管理

图- 模块管理-安装

图- 模块管理-安装

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

模块管理

该模块管理系统专注于现有安装的组件，在此基础上不仅支持手动添加现有组件，并可开发新的组件。其中手动添加现有组件的方式主要是通过镜像仓库或远程源进行部署；而新组件的开发基于开发者平台及其相关的API接口，并非直接依赖外部环境。完成新组件后将构建成果以镜像形式保存至存储库，并进行部署；现有的组件支持更新和移除操作

图- 模块管理

容器组

支持关于容器组内各容器的状态信息查询功能，并包含以下详细参数：容器名称、所属应用、对应的宿主机机器名、使用的镜像版本以及当前运行中的状态码等关键指标信息。该系统还具备相关的调试日志查看功能以及故障恢复操作步骤记录功能

图- 容器组信息

3.1.1.6.8 基于模板部署

平台预装了多种多样的应用模板资源。 管理页面具备名称与分类组合的定位检索功能。 管理人员可在管理模块中完成新增、归类、更新和移除等常规维护工作。 不同应用场景之间在部署流程上存在一定的共通性。 利用这些模板能够实现高效的 deployment 流程。

图- 新增模板

图- 模板详情

3.1.1.7 服务管理

3.1.1.7.1 服务管理

为用户提供可视化界面的管理服务。该系统支持基础信息查询与日常维护功能。用户能够新增服务并与其进行绑定操作。系统还具备实时监控并管理其生命周期的能力。

图-服务查询及日常维护

3.1.1.7.2 服务发现

平台采用 Etcd 作为基础的服务发现技术，并且同时支持通过 DNS 和 microservices 等等的分布式服务发现机制。

3.1.1.7.3 数据库服务

该平台内置了MySQL和PostgreSQL等多种数据库作为基础组件，并且还提供了消息队列等其他相关组件。它不仅能够管理数据库的基本信息以及实例信息和配置信息等等，并且还具备对数据库服务进行查询的功能。此外还能够实现数据的基本管理和维护操作：例如能够监控CPU负载情况以及内存使用状态等关键指标，并且还提供了数据备份与恢复等功能。

图-数据库模板

图-大数据模板

图-日志信息

图-操作日志

图- CPU、内存

3.1.1.7.4 存储

平台支持存储卷管理功能，支持存储卷的日常管理操作。该系统能够执行新增与删除操作，并允许配置文件编排方案以实现复杂的 YAML 配置需求。

图-存储

3.1.2 容器平台可扩展性

3.1.2.1 集群规模扩展能力

容器平台软件底层基于Kubernetes核心架构设计实现，在集群规模扩展方面主要取决于主机性能的变化。随着集群节点数量的增加,kube-controller组件的计算资源消耗分别提升至0.1倍CPU/80MB内存；而创建namespace所需的内存消耗极低,几乎可忽略其对资源的影响程度

集群内置的用户中心基于 OpenLDAP 实现；该系统架构遵循集群技术原则；通过不断扩展横向节点来提升用户的注册表规模；使用户的数量能够达到几乎无限制的程度；系统不仅提供现成的标准化接入方式（如 Active Directory），还允许用户自定义地接入其他第三方服务。

随着集群访问用户的增多，在线下线平台控制器下的单个前端实例在默认状态下可承载约150附近的并发访问量以达到预设资源极限；当用户并发超过该数值时可以通过提升前端服务的CPU/内存配置来增强其处理能力同时也可以通过增加前端控制器服务的容器实例数量实现横向扩展以进一步提升系统性能

3.1.2.2 插件扩展能力

随着云原生动态发展迅速扩展中，在整体范围内仅承担少量计算编排功能的Kubernetes系统，在实际应用场景中为其用户提供了大量来源于其他社区围绕Kubernetes进行扩展的能力支持。平台通过插件机制支持系统以稳定的架构为基础逐步扩充新增功能模块，并将Ingress/CoreDNS/HPA/Istio等作为该体系内持续迭代补充的功能集合

插件采用平台提供的API/SDK技术实现功能开发，并通过一组独立的镜像打包模块发布至平台；由插件管理中心负责安装

安装后的插件按照规定通常在独立的namespace中运行一系列的容器，在线服务均会遵循该规范。

3.1.2.3 OpenAPI 接口扩展能力

容器平台遵循OpenAPI标准提供的官方开放接口，并兼容使用Kubernetes原生API调用，在进行二次开发时需设置IP地址、请求参数和响应参数与Kubernetes官方API完全一致；通过平台提供的接口创建的对象与通过其页面操作创建的对象保持严格的一致性

3.1.3 安全合规性对接

3.1.3.1 统一身份认证

容器平台在IT信息化系统领域同样遵循统一的身份认证与管理系统，在安全与权限管理方面同样遵循统一的身份认证与管理系统。通过统一身份管理系统与企业内部认证系统的对接途径，在获取用户的身份验证信息的同时也能完成对配置信息的更新

统一身份认证系统能够集成多种身份管理系统,包括LDAP,CA以及现有的AD域安全系统.其整体架构通过下图具体展示.

图-统一身份认证

根据如图所示的内容, 统一身份认证系统采用一套安全和认证管理模块来支持以下功能.

该中心致力于维护企业用户的详细档案信息，并且负责处理用户的的身份验证和权限分配等功能。

权限管理和访问控制平台:个体用户的角色划分;策略设计与优化流程及执行监督机制;基于动态交互的安全更新流程;基于实时反馈的安全状态展示界面及审计日志分析模块

身份认证服务：为应用系统提供安全防护接口，并对中转认证与权限申请进行处理；该服务负责对用户身份进行验证并完成角色转换。

访问控制服务:通过应用系统组件从应用系统中读取单点登录所需用户的相关信息;在单点登录过程中,在线用户会向业务系统发送访问请求,并对其所涉关键敏感信息进行加密签名处理。

AD域管控中心及数字证书管理模块：负责在认证流程中所需电子签名证书的生成；并负责生成用于认证流程中使用的 USB 智能密钥

3.1.3.2 与现有监控体系对接

目前，在银行提供的各类金融服务中存在较大比例必须借助IT系统来实现。由此可见，银行数据中心的稳定可靠运行在提供优质服务方面发挥着基础保障作用。对于新增的容器平台必须纳入到数据中心的整体集中监控体系内实施实时监控对各类服务器群组和应用程序的运行参数与状态实施监控与管理同时对设备出现故障的状态也需要及时发出报警信号并采取相应处理措施。

当前阶段的银行数据中心已实现了系统监控、应用监控、日志监控以及交易监控功能；此外该系统内置了 HUB 网关 并支持接入第三方实时 监控 服务；银行 级 的 监控 系统 与 CMDB 实现 了 对接 在固定 IP 地址下可实 现 对 资 产 系 统 的 映 射 关系 获取 从而实 现 对 全 网 资 产 状 态 的 有 效 集 中 敦 斯

图-监控体系对接

3.1.3.3 与集中日志系统对接

目前多数银行的应用系统将各自的运行日志单独存储，并借助ITM平台实现对这些系统运行状态的实时监控。然而每个独立的日志系统往往仅能提供有限的信息量因此在遇到故障或预警事件时，则通常需要整合多来源相关业务系统的运行日志数据来全面识别问题根源及具体影响范围由于上述问题导致的故障定位困难及效率低下问题亟需解决为此建议

容器平台除了必须将平台日志上报给集中的日志中心外, 容器平台上运行的容器日志以及应用/服务日志也需要集中上报到同一日志中心

图-日志对接

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

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

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

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

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

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

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

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

平台日志中心应当对具备“容器感知”能力的系统实施管理，并构建多层次索引体系以实现针对复杂条件的高效检索功能；同时提供多样化的业务监控告警服务以保障系统的稳定运行。例如针对应用层面的日志检索和容器级别的信息追踪等各项功能需求进行系统化设计与实现。

3.1.3.4 与堡垒机对接

图-堡垒机对接

为保护网络及数据系统免受外部与内部潜在威胁的侵害，在综合运用运维管理和安全性的基础上，在不直接授权终端设备接入网络或服务器资源的前提下，在不直接授权终端设备进行网络或服务器操作的前提下，在不直接授权终端设备进行网络或服务器操作的前提下，在不直接授权终端设备进行网络或服务器操作的前提下，在不直接授权终端设备进行网络或服务器操作的前提下

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

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

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

基于容器平台的应用集中统一管控策略实施后

除了这些基本功能外，在实际应用中我们发现现有方案存在以下不足：一方面，在基础功能上仍需进一步完善以满足更多场景的需求；另一方面，则需要对现有的核心算法进行优化改进以提升系统的运行效率。

容器平台与堡垒机实现了连接，在此过程中，堡垒机内部存储了用户数据，并同时保留着相应的资源信息以及权限信息。为了确保资源的安全性与访问权限的一致性，在这种架构下进行了相应的设置。
为了实现组织架构下的统一管理需求，在容器平台上相应地创建了与这些组织单元相关的账号，并对这些账号进行了权限分配。

在日常维护过程中, 用户采用容器平台的低权限账户进行操作。首先, 用户会登录到堡垒机, 堡丁机基于用户的映射信息, 通过该用户的关联组账户完成对容器平台的登录。

在变更操作进行中时, 采用具有权限提升的账号参与容器平台的操作. 用户需在服务流程平台发起申请请求, 待申请获得批准后, 进入堡垒机界面. 堡堡机将基于用户的关联配置实现对该组账号在容器平台上拥有更高的权限.

该容器平台负责项目注册及配额信息的管理，并允许管理员通过配置限定项目的总数及其各子项目的资源上限。

容器平台能够管理用户的注册与添加操作，在处理本地用户时，默认配置严格的密码强度要求。

容器平台用户的登录功能包含本地账户、LDAP账户以及SSO对接账户的身份验证流程。在用户完成身份认证后系统将自动发放一个token用于后续的身份验证操作。如果出现连续多次尝试登录失败的情况将导致账号被短暂封锁；此外平台还设有针对长时间未修改密码或密码强度不足的账号自动采取相应措施提醒用户进行必要的安全维护。

容器平台的安全模块不仅负责身份认证与权限管理功能，在架构设计上还承担着API Gateway的责任。每当用户通过外部系统调用容器平台提供的API时，在发送请求之前会被优先转发至用户安全管理组件进行身份认证及权限核实，并根据用户的访问路径和方法分析其是否拥有相应的访问权限；仅在确认用户具备相应权限的情况下才会将请求进一步转发至内部处理环节进行执行。

3.2 统一知识库

在组织内部对知识并无一个明确无误、清晰明确的规定与界定。企业在创立之初便持续不断地进行着物质资源的建设与生成，并将其自然利用作为运用知识最基础的形式之一。当物质资源被投入运用时其中一些经过加工改造从而实现了资源共享与智能化运作进而提高了使用效率并使原本仅具物质特性的资源获得了知识属性

在探讨知识与资源的关系时会发现这种关系并非固定不变而是具有相对性特征两者之间存在着相互转化的可能性从具体某个层级来看其中高层级的对象被归类为"知识"而低层级的对象则被视为"资源"这种分类方式使得对于企业而言 knowledge 和 resource 实际上代表同一概念只是所处层级的不同罢了就工程实践而言 knowledge construction 和 resource construction 之间并不存在绝对分明的界限从实用层面讲那些能够在实际工作中发挥作用的价值都可以被归类为具备实用价值的知识因此在产品开发设计过程中能够带来实际效益的各种资源都可以被视为构建起完整体系的知识工程的基础

3.2.1 建设目标

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

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

整合不同领域知识与应用开发环节的结合，为其提供一个知识化的基础。

通过多种知识与开发、运维行为之间的联系起来，由个人构建出专属于自己的专业知识领域

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

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

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

3.2.2 建设方案

为了达到上述多个方面的知识应用目标建设要求 将从两个维度出发制定知识应用方案 第一部分将致力于搭建知识应用的基础框架 第二部分则将探索基础框架下的多样化应用场景

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

(二) 知识应用的多途径

知识应用的方式有三类：基于门户的知识应用场景、以客户端为特点的应用场景以及深度嵌入到业务系统的应用场景。

基于浏览器的知识门户系统作为信息浏览入口，在构建完善的体系化知识管理系统的基础上实现了对各领域知识点的高度整合，并推动跨领域知识点与企业级研发流程的有效结合。具体包括但不限于信息检索功能、智能索引服务、根据用户访问频率自适应推荐机制以及智能化推荐服务等

基于客户端的应用模式，在不同科室中整合与每个研制任务相关的专业知识库内容。涉及的知识维度主要包括输入端的数据处理能力输出结果的质量保证流程优化效率提升模板组件的标准化配置关联关系建立关联模块的知识整合等。构建一个以研制任务为核心的知识体系图谱实现了专业知识库与业务流程之间的有机衔接。

将知识融入容器平台系统的整体架构中，并通过动态推送机制，在工程师的操作界面中实时展示相关内容。在功能模块中构建专门的知识导航栏，在容器平台相关界面中实现针对性的知识链接嵌入。通过智能化算法优化显示效果的同时，在工程师的工作流程中自然融入专业知识库资源，并促进专业知识与实际工作流程的有效结合。

3.2.3 知识分类

容器平台的知识涵盖其自身相关的内容，并非仅限于此；此外还包括与之相关的外部系统知识。我们将容器平台的知识分类为九种类型：基础组件、存储管理、网络配置等大类领域，并在此基础上根据不同应用场景进行细化或进一步划分

3.3 统一制品发布

金融IT领域 container技术的主要驱动力在于加速应用交付与迭代进程,尤其是在服务客户以及优化内部业务流程的应用系统中表现尤为突出. Docker等 container技术代表,为企业的应用交付平台与开发运维之间的协同工作带来了根本性的变革.过去,开发、测试、运维被划分为独立的工作阶段,各自分别提供不同的成果:开发者输出代码,测试者提供测试包,运维人员构建环境.这种割裂式的模式导致了应用交付效率低下,无法满足业务对快速响应的需求.

Docker的诞生开启了持续集成与持续交付(CI/CD)以及开发运维协同的新范式。如图所示 Docker通过统一的方式将应用的交付件转换为标准化的Docker镜像（类似于乐高积木模块化的构建方式）。其中每个开发者测试者及运维者的交付内容均基于标准化容器镜像构建完成这些镜像是经过精心设计整合了操作系统中间件及完整的应用程序代码以确保所有依赖环境均被包含。基于这些标准容器镜像的应用构建者能够在同一平台上协同工作实现了系统及其所有依赖环境的整体交付不仅显著提升了协作效率还大幅降低了潜在的安全隐患。

3.3.1 方案架构

图-方案架构

全面且高效的CI至云持续交付方案实现了全自动化流程。开发者的重点应放在核心代码上，并可让测试阶段后自动执行构建、集成以及部署操作。该平台利用镜像技术识别并控制版本差异，并支持灰度发布与版本回滚操作。

在开发与运维深度融合的场景中, 非常值得一 mention的是, 当前许多金融机构的应用主要由外包的软件开发者负责构建, 这些机构内部的技术人员难以对系统实现有效的管理. 采用容器化技术来实现统一的应用发布, 极大降低了对外包开发者 reliance, 显著提升了运维效能.

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

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

测试环境与生产环境的部署主要依靠人工操作。归因于环境间的差异性因素，部署效率相对较低。相当高的协调成本存在。

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

基于 CI/CD 平台的支持下

图-交付流程

3.3.2 代码版本管理

作为企业软件资产的重要组成部分之一, 代码版本管理承担了支撑企业在软件开发过程中产生的代码资源这一重任. 在现代企业软件开发流程中, 团队协作主要遵循着代码版本管理的相关规范展开. 同时, CI/CD体系也需要具备对接企业常用代码版本管理系统的能力, 包括Git、SVN以及GitHub和 GitLab等主流工具. 这种系统对接通常基于灵活配置的触发机制, 实现了基于代码驱动的持续集成与交付自动化流程.

3.3.3 自动化测试

通常我们会将自动化测试前置至预热阶段，并将其作为快速验证是否达到预热要求的标准。因此，在定义流水线时,我们应当将自动化测试阶段所涉及的整体流水线的前半部分进行规划。下面我们将详细阐述 RobotFramework 测试框架的应用与优势。由于 Robot Framework因其广泛认可的特点而备受青睐

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

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

◼ 提供 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文件（即 Dockerfile文件），用于镜像构建。整个构建流程具有可追溯性，并实现了对软件资产与源代码资产的有效关联。

在镜像构建完成后, CI/CD 根据预先设定的策略发布镜像版本, 并将其归集到 CI/CD 内置的企业级镜像存储库中

与此同时，在编译打包的过程中往往会产生较大的计算与内存资源消耗。为了避免影响集群中现有应用程序的正常运行，请确保将编译打包环境与应用运行环境进行隔离。CI/CD流程能够指定集群中的特定节点作为专用构建主机以实现计算资源的有效调度

3.3.5 运行环境

在持续交付流程中，必须具备一个开发、测试、生产环境一致的应用运行环境，并对运行环境的访问实施权限管理及资源分隔。

在CI/CD流程的基础上为每个不同的环境配置对应的租户空间，并将相应的团队分配至可访问的租户空间中，并对不同租户空间的应用可见性权限进行管理。

将不同环境下的主机加入到租户空间中，并使其成为该租户独有的资源；通过这种方式以实现资源间的隔离。

CI/CD 为团队提供了成熟的部署方案以及优化的运维支持，并显著提升了应用运行效果。

3.3.6 持续部署

自动化是持续交付流程的核心要素，在CI/CD环境中设定持续部署策略能够实现应用与代码更新的同步推进，并非仅此而已，在这种机制下不仅有效降低了开发人员频繁切换环境所需的时间与资源损耗还显著提升了团队整体的工作效率同时为项目的不断优化提供了有力保障

3.3.7 制品交付

金融行业的应用交付具有显著特点：一方面涉及企业内部自行研发的应用项目；另一方面则是由外部软件供应商负责开发的业务模块。因此有必要针对这两种不同的交付模式来制定相应的交付方案。其中企业内部应用的DevOps流程基于代码交付机制下的工作流程体系

图-制品交付流程

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

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

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

在预发布阶段中，在经过严格测试后（经核实），对应用进行版本编码并标记以区分不同迭代轮次的应用版本，并将其编译后的镜像文件部署至企业级可用性测试环境下的公共存储区域（Public Storage Area for Business Readiness Testing）。

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

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

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

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

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

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

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

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

3.3.8 合规性检查

容器平台及其服务涵盖了身份识别、权限管理、安全审计、通讯完整度、通讯保密性以及软件冗余设计等各项核心功能。

身份鉴别

在身份识别上成功完成了与统一身份认证平台的技术对接，并确保了唯一识别信息的有效获取。

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

系统具备了重复身份校验功能，在新增注册的用户以及已存在的账号进行操作时都会执行判断流程。

在系统中，用户的会话被存储在服务端。注册后创建对话，在退出后进行注销。长时间未进行任何操作时，默认情况下会在15分钟后关闭。

该系统设置了针对用户的登录失误次数限制（默认值为5次），规定当用户的连续密码输入错误导致系统判定为异常登录时，则相应的账户将在30分钟内被锁定并无法正常访问。

当用户进行登录操作时，在日志中会被记录下登录用户账号及其所在的ip地址；同时在安全审计过程中进行跟踪记录。

用户的密码将通过统一认证平台进行配置。系统的最低要求为8位字符，并且设置规则时需遵循数字与字母的组合。如果账户未被使用超过3个月，则将被系统自动锁定。为了恢复账户，请使用找回密码功能进行重置。

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

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

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

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

向用户提供多种组合方式的鉴别手段以完成用户的身份识别过程

该系统具备对用户的用户身份标识唯一性和鉴别信息复杂度进行自动检查的能力，并确保在应用系统内没有重复的用户身份标识，并且防止了身份鉴别信息被非法复制或滥用。

为用户提供 login 失败处理功能的支持，并可通过以下措施实现：1. 结束会话；2. 限制非法登录次数；3. 自动退出等

该系统能够为用户提供身份鉴别功能、用户身份标识唯一性检查功能、用户身份鉴别信息复杂度检查功能以及登录失败处理功能，并依据预先设定的安全策略配置相关参数。基于以上安全机制的设计方案实施后，则可预期达到预期的安全保障目标：

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

该系统具备鉴识能力及识别机制的综合评估能力，并确保系统内避免出现同一名用户的多重认证记录；同时防止他人盗用或模仿.

◦ 支持异常登录处理机制，并可采用以下措施：首先，在发生异常时将会话终止；其次实施基于IP地址的登录控制；最后触发后将账户自动注销

集成了一种基于身份验证的系统架构，并在以下几个方面进行了优化：首先是对用户唯一性进行验证；其次是对身份信息多样性进行评估；最后是实现了异常登录处理机制。同时，在安全策略的基础上设置了相应参数值。

应制定关于口令长度、复杂度及定期修改的规定要求，并确保所有操作均使用单一的账号标识。

安全审计

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

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

该系统对用户的登录与注销过程具有详细的监控能力。系统能够精确追踪用户的登录方式，并通过该 ip 地址完成登录与注销操作。此外系统能够实时跟踪并详细记录每位用户所进行的所有操作流程并且保证所有操作都被完整记录确保所有操作都被完整监控

系统所有日志设置了针对访问人员的权限控制：非授权用户无法查看日志记录；仅限于特定运营人员可进行日志的获取操作；该系统对日志内容设有无修改权限的保护机制；日志记录具有不可篡改性特征。

该系统支持对审计记录数据的统计、查询、分析及生成审计报表等功能；通过审核系统设计与审核系统日志设计，并经过差距分析之后能够实现：

应支持对每个用户的全部安全审计功能进行覆盖，并实施对应用系统中重要的安全事件的审计

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

审计记录的内容应当涵盖事件的发生日期与时间、发起人信息以及相关的分类、详细说明和最终结果等内容;

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

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

建议配备涵盖所有用户的网络设备安全审计功能，并对应用系统中出现的关键安全事件实施监控

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

审计记录的内容必须包含发生日期、发生时间、发起方资料、分类、详细说明以及最终确认结果等信息;

该系统赋予独立审计员角色权限，在规定时间段内可提取相关审计记录；而其他所有角色无能力查看或提取这些记录

通信完整性

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

为了确保通信的完整性，在传输前系统会针对通信报文和相关数据进行长度登记；随后，在接收端程序接收到待处理的数据时会执行长度校验。

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

在审核系统的前后阶段进行设计与部署安排，并通过对比分析各环节间的差异。最终实现通信过程中的数据传输安全。

进而通过上述安全机制设计的能力得以实现, 可采用校验码技术以确保通信过程中的数据完整性;

通信保密性

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

采用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）、服务负载 Balancer（SLB）、对象存储（OSS）以及容器Pod等。

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

3.4.6 租期回收

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

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

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

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

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

◼ 租户可进行资源续租。

3.5 容器统一规范

3.5.1 容器内应用的健康检测

在集群环境中，在线监控系统可通过健康探测器持续评估各个容器的状态。这些实时监测数据有助于在线优化资源分配并及时发现并解决潜在问题。不同类型的健康探测器可针对不同的应用场景进行配置。

存活检查（liveness probe, 存活探针）是一种用于检测容器是否进入不可用状态的技术：通过此探针能够检测容器何时进入不可用状态，在程序运行但无法向外部系统提供服务时能够捕获这一异常情况，并触发对该状态下容器的重启操作

该方法采用（readiness probe）机制来进行容器健康检查，在容器完全启动并正常提供服务的基础上建立关联关系。具体而言，在Pod处于非健康状态时无需与Service的iptables转发规则相关联，在健康状态下则会与其建立关联关系以实现流量转发的稳定性。
当Pod处于非健康状态时其流量不会被转发至未处于健康状态的Pod以避免影响Service的正常运行；只有当Pod处于健康状态时才会与其对应的Service建立iptables转发规则从而保证数据传输的安全性。

3.5.2 应用容器的 DNS 配置

在Pod级别上实现DNS服务的配置过程，在Pod级别上实现DNS服务的配置过程，在Pod级别上实现DNS服务的配置过程

dnsPolicy 的类型有:

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

当Pod未明确指定dnsPolicy配置时，默认采用ClusterFirst类型；该配置中Pod中的DNS设置会采用10.96.0.2 IP地址作为公共DNS服务器地址，并基于Kube-DNS/Core-DNS服务进行解析；对于属于集群域名称前缀的DNS查询请求，则会直接由Kube-DNS服务进行解析；而对于非集群域名称前缀的DNS查询请求，则会转发给位于Pod宿主机目录下的etc/resolv.conf文件中已配置好的nameserver地址进行解析查询

ClusterFirstWithHostNet：通常会将Pod配置为基于hostNetwork网络的架构，在这种架构中，默认情况下会继承宿主计算机的/etc/resolv.conf文件配置信息。如果希望在hostNetwork模式下同时支持Kube-DNS和Core-DNS功能，则应采用这种配置类型

删除 Pod 所在位置的/etc/resolv.conf 文件配置。
通常会结合 dnsConfig 参数来定制 DNS 服务配置信息，并对其中与 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服务器；这样一来，在Pod内部就无需对集群内部的DNSServer进行任何配置设置，即可方便地解析来自外部域名。

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

避免将配置文件放入到应用镜像中，在集群环境中部署应用程序时应当特别注意这一点。借助平台实现对应用配置文件的集中管理。

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

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

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

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

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

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

创建 file 类型的 ConfigMap

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

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

利用环境变量机制将configmap注入至容器内；采用volumes挂载方式时，在更新configmap之后，则需一定时间才能完成更新

3. subPath 挂载

在默认配置下，当configMap的mountPath指向某个路径时，该路径下的任何文件不会被显示。若仅需将一个特定的文件挂在某个目录中，则可配置subPath属性。该设置对挂载目录中的其他文件无影响。

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

当采用外部配置中心时，则只需在应用的编排文件中设定其地址，并配合相关的Profile环境变量进行配置即可完成

3.5.3.3 应用配置文件的热加载

需要对上述技术内容进行详细说明或补充说明

需要对上述技术内容进行详细说明或补充说明

以应用为中心生成 bootstrap.properties 文件，并基于命名为 app-config 的 Configmap

3.5.4 应用容器的日志配置

3.5.4.1 容器的应用日志输出

应用在集群中的部署基于其日志输出功能可以通过以下两种方法将日志发送到标准输出

对于能够向标准输出发送日志的应用程序而言，在使用log4j时可以直接将该系统的日志输送到容器的标准输出端口上。这样一来，则使得通过kubectl logs命令来查看日志成为可能。

如果一个应用程序难以将日志输出到标准输出，则可采用hostPath的Volume配置方式将宿主机的日志存储目录连接至容器（推荐方法）。

对于无法直接向标准输出设备输送日志的应用程序而言, 另一种解决方案则是利用Sidecar容器来进行处理。为了实现这一目标, 在Pod内部必须预先准备相应的存储卷, 以便于两者之间的信息同步。随后可以通过Sidecar容器将这些信息传输至标准收集点, 从而完成完整的日誌记录流程。这种方案的优势是可以使所有存储的日誌具有统一的路径及格式规范, 然而其缺点在于会增加额外的资源开销与维护负担

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

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

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

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

如果应用无法将日志输出到标准输出上，则可以通过以下方式实现：通过配置让应用程序将所有运行时产生的系统信息收集后发送至宿主机的日志存储路径。

当应用程序无法直接将日志发送至标准输出时，则可借助 sidecar 容器实现日志的发送。

集群预设将Pod中的所有容器的日志存储在[var/log/containers]位置下，并按照‘Pod名_命名空间名_容器名’的格式命名。随后这些日志可以通过相应的日志代理进行收集、过滤，并被发送至日志存储与处理系统的后端。

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和内存的角色：其中CPU是一种可调整资源而内存是不可调整的资源；这些资源可以划分为两种不同的类型：一种是请求中的资源需求（期望值）另一种是已使用的现有资源（当前值）。基于这两种类型的状态进行节点容量评估，并根据具体的任务需求进行Pod调度；最终的状态信息将由以下两个配置参数实现：

requesting: container-requesting resource allocation, if the container exceeds its allocated resources, it will attempt to cap its resource usage at the specified limit.

limit参数表示系统中可用的最大资源量。当系统中的任何container资源使用超过设定limit时（即当container的resource消耗超出其限定值时），系统将停止运行该container，并相应地触发backup controller重新启动并开始一个新的container实例

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

基于Pod容器在Resource中设置的request和limit值来确定Pod的QoS类型；每个资源类别都可以划分为三种QoS类型。

保证式：当且仅当其所有容器的Resource定义中的limit和request均相等且不等于零时，则该Pod的QoS即为保证式。

当Pod中的所有容器的Resource定义中的请求值都低于设置值时，则该Pod的服务质量QoS即定为Burstable。当容器内的资源使用越多，在因资源不足导致驱逐时，这些高使用率的容器被驱逐的可能性会降低。

除了前面提到的两种情况外，
其他Pod QoS Class都是best-effort，
这意味着所有Pod内部的所有容器都没有设置任何request或limit参数。
当未指定limit值时，
这些容器的有效容量等于Node的总计算能力。

当宿主机资源出现瓶颈时，则会对Pod进行驱逐操作,依次回收BestEffort、Butstable和Guaranteed类型的Pod设备,其中前者优先于后者再后者].因此,对于一些关键性服务(如网关、数据库等),建议为其配置相应的请求上限(N/A)和队列大小参数,使其处于QoS级别中的优先级保障层.而对于非关键业务则可灵活选择Butstable或BestEffort类型服务

Guaranteed 类型资源配置示例

Burstable 类型资源配置示例

当在资源定义文件中未配置 resources 时，默认采用 BestEffort 类型

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

在 JDK 1.8 版本中运行时所使用的 JAVA 应用程序所占物理内存主要包含以下几个方面：主存、元空间以及非主存区域（包括调用栈、缓冲区以及所有 JAR 文件中的静态库，并且还包括虚拟机自身运行所需的代码）。

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

线程堆：每一个线程都拥有独立的调用堆，在这些stack中排除了作为自身功能部分的方法调用列表，并保存了原始的本地变量以及对象引用信息。
当stack frames从上下文环境中被剥离时，
该堆将被自动释放并归还给内存管理机制。
这意味着此处无需进行垃圾回收操作。

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

JIT编译器将原始代码存储于Code\ cache中用于重复利用从而提升性能水平

缓冲区池：大量库和框架通过外部分配缓冲区来提升效率；这些缓冲区池不仅可以在Java代码与原生代码之间实现内存共享，并且能够将文件缓存到内存中。

在Java语言中，并非一味增大堆内存就能带来最佳效果；JVM会定期执行内存回收操作，在特定时间点时系统会触发一次全面的Full GC回收过程，在这一阶段的应用程序将会暂时中断运行；由于Full GC涉及整个堆内存空间的扫描工作因此其对系统性能的影响程度与其占用的空间规模直接相关；对于部署在平台上的应用程序而言其合理的堆内存配置应当依据系统的实际运行状况来确定；此外还需要考虑非堆内存资源以及GC算法相关参数的具体设置情况以确保整体系统的稳定性和高效性

在 Java JVM 中：

• 初始堆内存容量被配置为 -Xms 选项。
• 最大堆内存容量被配置为 -Xmx 选项。
• 建议将集群应用中的堆内存量最大与最小设定为其请求（Request）与限制（Limit）内存量的 80%。

同时，在容器内部，我们可以通过调用Downward API来获取container configuration中指定的请求内存和资源限制内存，并用于按需分配JAVA应用的堆内存。

3.5.5.3 租户的资源管理规范

集群在租户级别具备了资源配额管理功能，并且能够对当前租户所使用的计算、存储、网络以及集群对象资源实施总量限制

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

3.5.6 投产审核

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

该平台作为银行服务流程管理的核心中枢发挥作用。 依托该平台可对投产审批过程进行规范化管理。 通过系统规划和建设工作明确各环节责任分工。 此类业务活动提供了全面的管理体系框架。 确保企业运营规范高效运行。

3.5.6.1 配置信息

在服务流程平台上集成CMDB模块，并用于存储数据中心的应用相关信息、物理服务器配置以及IP地址等技术参数。其他相关监控系统将通过获取CMDB中的IP地址相关信息来展示与物理服务器配置及应用运行状态的关联情况。

上线时，在系统中必须手动填写应用信息及服务相关信息。基于容器弹性伸缩特性，在后续版本中打算实现自动化导入IP等相关信息。

3.5.6.2 流程审批

为推动基于容器的应用/服务的上线、变更、部署及应用监控而存在。 container platform must align with rov service flow platform and implement the following functions: instance creation, configuration management, status monitoring, and log management.

容器平台用户的权限分为高权限和低权限两种类型；对于需要接入系统而言, 高权限用户必须向流程管理平台提交相关申请材料, 并在审批后方能接入系统.

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

3.5.7 自动化运维

3.5.7.1 运维范围与目标

在运维领域中，基础设施部分属于一类运维对象。具体而言，它涵盖了风、火、水、电等基础能源资源以及环境相关资源。

第二类运维主体是在IT服务运行过程中所涉及的各种IT设备资源。这些设备涵盖计算设备（如服务器）、存储设备（如数据库）、容器化设备（如Kubernetes）、服务器系统（如IaaS）、网络设备（如交换机）以及安全防护等关键资源。

第三类运维对象涵盖资产及系统资源，并涉及与数据相关的安全问题；其具体范围包括多种 IT 资源如终端设备及其操作系统；此外还包括数据库管理系统的中间件与应用软件等。同时涉及业务运行所需的各项数据如业务数据记录；配置文件用于参数管理和日志记录管理。

第四类运维对象属于管理工具，并非仅仅局限于现有的应用类型。它不仅包含基础的基础设施运行监控软件以及IT 业务监控软件，并且还涵盖了更为复杂的作业流程管理系统和数据报表系统等各类功能模块，并非仅仅局限于现有的应用类型

属于第五类运维对象的是资产与人员。其中涵盖的是数据中心的技术支持团队、IT运维工程师以及管理团队等，并延伸至第三方服务提供者的人力资源部门。

3.5.7.2 运维设计原则

1. 统一管理平台

融合DevOps理念潜心研发基于ITIL的企业级业务服务管理平台

建议有以下功能模块：

业务流监控

流量监控

主机监控

网络监控

存储架构管理

虚拟化架构管理

响应时间管理

应用系统监控

日志监控

业务服务管理

报告报表管理

多方式告警通知

采用 B/S 架构模式进行软件开发，在前端与后端之间实现了功能划分，并借助 portals 提供统一展示界面；实现了对业务流程、基础架构及应用系统的全方位监控，并实施了基于服务的应用性能管理方案；持续提升用户体验水平的同时严格遵循 ITIL 过程标准；通过数据驱动的方法进行实时监控分析并实时追踪IT基础架构与业务服务之间的动态关联情况；构建企业级的服务管理系统以实现IT系统持续优化目标

2. 管理体系开放性

该管理系统不仅满足行业标准，并且采用了开放平台架构，并配备管理接口以实现资源统一管理和与其他管理系统的集成。

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

开放性设计的Portal API能够提供用户应用程序界面的整合功能，并赋予系统管理在内容扩展上的潜力空间

3. 管理系统安全性

该系统作为保障工作顺利开展的核心要素之一，在设计和实施过程中必须给予高度关注，并特别重视其安全性和稳定性。

登录失败次数限制

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

制定全面的战略方案与组织架构，并以适应组织结构的变革，在配置管理人员的职责与权限时体现出灵活性

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

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

4. 结构化和扩展性

随着应用规模持续扩大而管理范围相应增加,因而管理平台的可扩展现实着对其保护投资的价值发挥着关键作用。具体而言,这种可扩展现实着主要体现在以下几个方面:首先,它能够有效提升资源分配效率;其次,它在不同系统间实现无缝对接;最后,它能够支持业务规模的持续扩大

功能模块的扩展方面已取得进展，在当前阶段主要集中在网络设备与主机的管理上。未来有望在统一平台范围内实现功能拓展，并涵盖包括数据库以及其他业务服务相关管理在内的各项事务处理工作

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

系统拥有强大的功能扩展能力，在必要时增添管理模块，并拓展管理节点以保障现有投资。

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

5. 模块化结构和扩展性

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

功能模块的延伸，在客户的业务发展、应用升级以及网络设备和主机等资源的变化中实现动态扩展，并及时响应客户需求。

"该系统通过优化设计实现了业务范围的延伸；支持多分支的增加与扩展；增强了分布式部署能力；确保业务管理具有灵活性。"

系统拥有显著的功能扩展性，并且可以在需要时增添管理模块来扩展管理节点以确保现有资产的安全。

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

采用 B/S 架构设计的系统具有高度统一的界面设计，并且操作简便。易于操作且维护较为简便的系统不仅显著提升了系统管理员的工作效率，在降低整体的维护工作负担程度方面也表现突出。

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

系统界面富有动感，并非仅限于支持 FLASH 等展示技术等。全中文管理界面能够简化操作流程。

3.5.7.3 自动化运维体系建设

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

架构转型完成后，在线应用与基础设施之间实现了松散的解耦状态，并对人力资源管理、“技术工具”运用以及业务流程优化带来了新的考验。应基于现有银行数据中心的运维运营管理架构构建专业化的云环境运维管理体系，并以专业化和便捷化的服务模式构建相应的运营管理机制，在云环境下的持续稳定运行中实现"安全性"保障及成本预算控制。该 new 系统设计需重点关注业务管理流程优化、“服务质量"提升、“资源供给"效率改进以及组织架构进行相应调整的需求

图-自动化运维需求

2. 运维框架规划

云运维服务目录体系

基于云计算与微服务架构的基础上, 将银行数据中心对外提供的核心业务能力和资源进行系统性划分与配置, 同时对内部资源进行优化整合, 明确服务质量 Level of Service (SLA)、岗位职责、功能模块的输入端口、输出结果以及处理流程, 最终构建业务功能与支持系统的完整服务体系; 建立清晰的服务体系图谱后, 则有助于制定标准化的业务操作流程与工具集, 并能为后续制定科学的服务考核指标体系提供可靠依据; 其中需重点完善的是需要建立的服务体系组织架构以及强化的能力评估机制

图-云运维服务目录

云运营规划

图-云运营服务目录

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

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

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

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

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

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

本项目基于新产品的建设而成的本系统，在各关键业务场景下采用功能模块模式实现自动化运维工作流。项目建成后将全方位联接至应用系统及其周边子体系，并整合现有CMDB数据及配置信息支持其运行与应用。借助各功能模块协调处理日常维护工作并定期同步运行状态及结果到相关子系统供其分析处理

运维自动化平台与应用系统的交互主要以agent代理为基础进行实现，并涵盖对应用系统的巡检及发布等任务；与周边系统间的交互则主要基于API或JSON的方式进行对接，并实现了监控与报警的联动响应。

总体架构如下图所示：

3.5.7.4 运维技术栈关键设计

1. 集中化任务调度管理

集中化调度管理意味着该平台必须覆盖现有各个应用系统，并支持不同开发环境（Windows、Linux 和 Unix）。平台需处理多种编程语言（如Java、C、 Perl、 Shell 以及 Windows图形界面操作等）所开发的自动化任务。其目标是实现任务的集中定义、展示、调度与监控功能，并整合集中事件管理、日志管理、用户管理和资源监控等功能。通过这些设计目标和功能需求的实现途径，在保障系统稳定运行的同时优化资源配置效率。

2. 自动化任务调度管理

自动化任务调度管理要求管理平台具备自动化的任务执行能力，并自动进行调度运行。该系统需实施健康检查机制、实时监控与预警响应、故障排查与恢复处理，并提供人工干预操作权限。

3. 标准化任务调度管理

该平台涵盖自动化任务调度接口、流程、配置参数以及响应信息等标准化规则，并设定统一规范和参数配置；实现现有及新增系统的自动化任务标准化集成与扩展；减少系统间整合自动化处理的难度。

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

冗余能力强的模块化调度管理系统必须具备高可靠性、负载均衡等核心功能，并能够灵活配置各模块的资源分配比例。

5. 性能压力及实现要求

自动化功能的核心模块是按批量方式发布指令并立即反馈结果；平台设计的最大承载能力为1000台主机同时在线运行；采用异步处理技术确保每个主机都能及时得到响应；当处理大量请求时，服务器的CPU负载可能会有一定的压力

该平台与受监控设备之间的通信带宽主要用于分发脚本文件以及软件安装介质。其中单个脚本文件通常不大于10KB，在线情况下测试发现，在500台设备同时运行该程序，则从该平台向外发送的数据量约为5MB（即每台设备带来约1KB），其流量对于整体网络影响较小。然而软件安装介质通常会达到几百MB甚至更大的容量（例如数百MB到数GB不等）。为防止对网络带宽造成不必要的负担，请采取相应的防护措施。

控制：

由于软件安装介质通过网络传输协议被下发，在应用层面该平台对FTP网络传输协议的数据速率进行控制；

业务网段、第三方DMZ以及办公网段在设备下发软件安装介质时会首先通过核心应用节点将介质转发至该网络区域内的代理节点，并由这些代理节点缓存后依次分发给该区域内的所有受管设备；这种做法不仅确保了安装过程的高效性还显著降低了穿越防火墙时的网络流量。

借助该系统的任务调度功能，在操作过程中尽量减少同时进行的设备安装数量，并建议将这些部署操作安排至非工作时间段。

6. 安全控制和要求

数据安全：运维自动化管理平台通过严格的物理部署防护措施保护业务数据的安全性；采用我行统一存储与备份平台构建了安全的数据存储与备份系统。

网络安全性：自动化运维管理平台中的各组件之间以及服务器自动化组件与其受管服务器上的代理之间均采用SSL双向方向加密的数据传输方式。管理端和操作端账号必须使用ECC业务网段终端接入HTTPS协议后才能访问本系统管理门户，在办公网段仅限于显示只读形式的报表数据（如巡检报告和其他相关信息）供用于日常办公环境下的查询查询者进行查看。

在用户登录管理门户中实施基于业务域AD的安全认证机制，并将基于业务AD的安全认证要求纳入系统设计。此外，在管理门户中对所有本地应用账户实施统一管控措施，在实际使用过程中要求所有本地应用账户均需通过统一系统进行管控，在操作过程中必须使用统一系统赋予的权限账号进行操作

3.6 高可用架构体系

3.6.1 方案概述

采用主备数据中心作为单体应用备份及多活应用双数据中心部署的基础，并结合数据外置挂载策略以及基于三层网络可达性的主备数据中心部署方案。确保在某数据中心发生灾难情况下（即灾难恢复场景），该系统能够快速响应并实现资源的有效转移与重建工作流程。平台本身实现了主动防御机制，并支持双机热备用及冷机备份策略以应对突发情况下的业务连续性需求

3.6.2 高可用部署方案

图-高可用部署

容器平台支持多层次冗余架构设计，在确保无单一薄弱环节的情况下，能够保障业务运行的安全性和稳定性。

3.6.2.1 容器的故障恢复

当服务器发生故障时

3.6.2.2 镜像仓库的可用性

采用升级单机镜像存储为集群架构的方式，并在注册表服务器池中实施负载均衡策略, 从而显著提升了系统的性能表现，并增强了其可靠性. 实现了注册表服务器的无状态设计, 从而有助于提升服务的整体稳定性.

图-镜像仓库高可用

3.6.2.3 容器的可用性

保证运行在容器内的应用与其他容器的应用完全分离，在通信流量与管理方面提供全面的权限。
选择的 Docker 镜像都经过数字签名认证以确保可靠性，并且资源有限制。
即使其中一个应用遭受攻击也不会影响运行于其他 Docker 容器的应用。

3.6.2.4 集群管理主机的可用性

平台会通过守护线程来提升 Kubernetes 集群的整体可靠性。系统会在每个节点部署守护进程，并定期检查各节点的运行状态。一旦检测到某个节点服务出现故障，则会立即标记该服务为不可访问。如果有必要的话，系统将根据预设流程启动修复机制

图-集群管理主机高可用

系统设计能够跨越多个地域分布于多个数据中心部署云服务，并且具备数据中心级别的可靠性

图-容器平台集群高可用

基于该系统的高可用性架构设计下，在线容器平台能够向用户持续提供可靠的一次性不可中断的服务：

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

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

系统的可用性得到保障：确保不同容器间的隔离运行，在服务故障时系统会自动切换至备用服务器并分配资源以维持业务连续运营，并提供高可靠性服务；通过多实例负载均衡与弹性伸缩等技术实现所有运行于该平台的应用 container 的可用率达到 100%以上，并保证其稳定运行

该系统采用了集群架构设计，有助于提升系统的高可用性。该系统提供的服务可靠性达到 99.999%以上。

支持维护主机的可用性, 提供一套完整的维护方案库, 并确保集群管理服务正常运行状态

3.6.2.5 平台组件备份设计

该平台具备完善的备份能力，并且能够实现以下几种类型的备份：节点配置信息及文件、meta数据库、服务注册组件、证书、应用镜像库、代码库、数据库复制、关键表复制、特殊时间点复制等。

基于容器平台推荐的最佳实践所设计的备份方案存储的数据具有高度的可靠性。当整个集群处于完全不可用状态时，通过完整的数据备份可以在集群完全不可用时恢复其运行状态。确保包括但不限于平台组件运行状态、业务应用工作状态以及源代码版本信息等关键数据的一致性。

1）备份数据完整性：

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

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

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

◼ Master 和 Node 的配置文件。

◼ 镜像

◼ 源代码

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

恢复方案如下：

3.6.3 总体设计

图-总体设计

3.6.3.1 平台部署

3.6.3.2 部署架构说明

主机房A：在内网区进行容器管理平台portal的主要功能部署（主要功能）。与机房数据库实现主要对接。全面管理主机房A内网区域的Kubernetes集群，并涵盖备机房B内网区域的Kubernetes集群。

备用机房B：于内部网络区域安装备用容器管理平台portal，并连接至机房数据库；纳入管理范围的是备用机房B内部网络区的K8S集群。

应用可以通过主 portal 在主备机房内同时发布；而无需灾备的应用通常仅会通过主 portal 在主机房进行发布。

3.6.3.3 负载均衡设计

跨数据中心之间的负载均衡通常依赖于DNS智能解析系统，在此机制下各中心数据之间的流量分布与冗余配置得到优化。DNS智能解析的核心思路在于，在DNS服务器中动态维护多个备用数据中心的出口IP地址，并根据预设算法筛选出最适合响应当前请求的最佳输出IP地址。当某一备用数据中心出现故障或性能下降时,DNS服务器则会暂时关闭该失效或低效IP地址,并将后续的所有DNS查询重新路由至剩余正常运行中的备用数据中心出口,从而在整个网络架构中实现资源分配与负载平衡。

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

在主从方案中：负载均衡器将日常所有请求分配至主数据中心。当主数据中心发生故障无法服务时，则会切换至备用数据中心。

通过互联网接入的访问流量，在主数据中心出现整体故障时会转移至DMZ以及相关的防火墙等网络系统中进行处理。DNS处理后的流量将被路由至备用数据中心的云互联/外联网络F5负载上，并按照应用部署架构流向相应的Web服务器，在完成服务交付后再返回至内部网的服务。

内网进入的访问流量经DNS解析后被分配至备用数据中心内的灾备内网进行应用接入。该流量通过备用数据中心内的F5负载转发到相应的Web服务器和应用服务器。

本方案将采用 F5 或其他具备 GTM 功能的负载均衡能力；若不具备该功能，则需通过手动切换 DNS 设置来实现。

3.6.3.4 切换架构

通常情况下会通过 DNS 域名解析访问主门户来进行平台操作，在主数据中心 A 机房出现问题时：

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

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

3.6.4 灾备实现

灾难备援设计方案以数据层面的备份方案为基础，并结合应用层面的冗余设计与网络切换策略作为核心考量。从数据层面出发进行类型分析与规划时，建议采用系统的主从架构进行配置，并结合现有机制优化策略；针对不同应用场景及灾备需求，在应用层实现多线程运行并具备应急切换能力；确保关键业务流量在负载均衡时能快速隔离与转移，并配合NAT跳转策略优化应急响应效率。

3.6.4.1 数据备份

根据所采用数据库类型的差异性特点，在不同环境下的主从关系下制定相应的数据层灾难恢复备份方案。其中一部分数据存储在主数据中心，在线时可直接访问；另一侧数据中心则作为备用存储节点，在线时通过现有备份技术进行异步复制机制实现数据同步与更新

数据备份方案如下：

3.6.4.2 应用层备份

该中心主要负责多个数据中心间的应用同步部署以及主备架构的服务提供工作。其中应用服务的提供主要依赖于底层保障系统的支持。对于多活/主备模式而言，在底层架构方面采取了一致的设计方案。

基于 Docker 容器，在容器云架构下

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

图-集群管理页面

基于新环境建设规划的基础上，并结合容器平台设计的数据情况，请选择适当的备份方案。具体而言，请详细说明以下内容：

冷备应用实现说明：

在多集群发布之后，在两个集群分别标识为主机和备用机。主应用正常运行中，备用应用的副本数量自动归零，并进入关闭状态。

备应用通过定时任务以每小时一次的频率进行监控，并在一旦检测到主应用出现异常时立即触发启动容器。

建议推荐使用双活 NAS；若无该设备，则仅需借助脚本配置同步规则，并定期同步相关数据。

3.6.4.3 平台灾备说明

该故障对容器平台发布的应用没有任何影响由此可见该系统的恢复的优先级相对较低

在备用容器平台启用后，在主数据中心避免进行应用的创建与发布操作。建议仅将该平台用于查看应用发布状态等读操作。一方面可以降低容器平台Portal的数据差异程度，并减少不必要的回切工作；另一方面，则无法在故障中的主数据中心Kubernetes集群上进行应用的创建与发布。

3.6.4.4 回切场景

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

4 方案价值

container technology has achieved rapid growth, emerging as the most sought-after technology in cloud computing, largely due to its ability to standardize cloud deployment units. traditionally, application software existed as a comprehensive system, but within the container framework, it is divided into modules based on specific business logic and packaged as individual containers.

图-应用的标准交付件

这项IT方法论带来了根本性的变革,它实现了对应用软件生产和运维流程的标准化与模块化管理,而这通常意味着更高的效率。无论是项目初期的研发阶段,还是项目后期的运维阶段,标准化的产品在企业中的价值也极为显著。正是因为这一点,有人认为容器技术开启了应用软件工业4.0时代的先河。

将企业IT分为应用交付前与交付后两个阶段。容器不仅体现了企业IT转型的能力。这种转型能力主要体现于两方面：一是应用交付前的快速实现；二是提升企业的高效管理和运维能力。此外，在应用交付后的管理效率上也得到了显著提升。

4.1 IT 交付新能力

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

随着互联网+金融的发展趋势下

Docker的技术革新性地突破了传统软件交付模式所带来的诸多限制与挑战，在云计算环境下开创性地提供了应用快速迭代的新解决方案。通过实现云环境下的标准化交付流程，在整个应用生命周期中实现了从需求分析到最终部署的一站式管理服务。具体而言，在迭代周期中，开发团队需要完成最新的功能版本构建并及时提交最终版本的镜像及镜像构建脚本。在发布前的质量把关环节，则由不同角色的人员（包括开发者、测试人员和运维人员）负责构建和提交容器镜像，并通过统一的镜像仓库进行协作。在迭代过程中，在开发阶段完成后需完成镜像的编排与部署工作；而在发布后的运维阶段，则需负责容器编排系统的优化与维护工作等环节的具体操作规范。这一系统化的管理流程使得整个软件开发过程能够实现高度的一致性和规范性，在提升效率的同时也显著降低了人为失误的可能性，并且将标准化的服务理念贯彻到了每一个环节中去

4.2 IT 架构新能力

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

在传统型 IT 架构向混合云架构转型的过程中存在两个主要转折点：一方面应用体系结构从大而全的整体化布局向模块化的微服务体系转变；另一方面集中式计算资源逐步转向分散化的技术模式

随着 Docker 等容器技术的出现

4.3 IT 运维新能力

IT 运维新能量-高效运维

高可用性是金融行业 IT 运维的一个永恒的话题。在互联网+金融的趋势下，用户体验至关重要，其中一个非常重要的指标就是服务的高可用性。如何实现复杂 IT 环境下的高可用性是互联网+金融趋势下金融 IT 变革的又一个重大课题。互联网 IT 运维的核心观点是——任何一个 IT 系统都有可能是不可靠的，因此， 运维的关键就变成如何从分布式系统的管理软件层面去确保系统的连续性和高可用性。容器的轻量级特性和秒级启动能力为金融 IT 的运维带来了新的思路。由于容器本身非常轻量级，具有秒级启动的能力，因此，在分布式系统中的任意一个容器出现问题，可以立即秒级启动另一个容器，从而确保整个系统的连续性和高可用性。