一、项目背景

随着近几年银行业国产化、数字化转型的不断深化以及线上业务模式不断创新和规模不断扩大，银行客户对银行服务的消费习惯已发生改变。银行业整体趋势为线下业务在逐渐萎缩，线上业务规模在持续扩大，通过国产化、数字化技术随时随地开展银行业务，及时为客户提供全方位、多元化的服务以满足快速变化的客户需求已经是银行业目前的核心关注点。

自2022年开始，我行逐渐步入以容器为核心的新一代云计算技术的时代，开始将测试环境及部分生产环境上容器。从而满足金融行业新型业务转型对快速部署、弹性伸缩、高效运维的需求。但总体原生平台的体系建设及DevOps的融合尚未完善。我行积极响应国家加快数字经济建设要求，发扬“敢为、敢闯、敢干、敢首创”的“四敢”精神，目前正全面推进我行国产化、数字化转型。结合近几年国产化、信创工作的相关要求，建设一套完善、安全、快捷、可靠且具有前瞻性的容器云平台体系成为容器云平台持续迭代的建设目标。

我行在推进全面国产化的过程中，结合新建数据中心的契机，同时考虑到当下我行应用基于分布式、微服务化的特性，重构我行基础计算资源架构，已容器技术作为后续应用迭代的主要手段。

二、项目目标&创新点

容器云平台“一云多芯”，跨网络区域的统一纳管，调度异构CPU集群。在一期建设的基于X86架构的容器云平台进行升级改造，完成异构arm集群的统一纳管、调度。

深入践行应用容器化工作方针，建设全场景应用容器化方案，融入到行内DevOps体系。

三、项目技术方案

1.面向平台架构侧

原有容器云平台在设计之初即考虑到后续异构集群纳管的需求，已提前将管理平面与业务平面分开部署，并切使用融合版镜像进行集成，平台原生支持纳管异构资源池能力且支持异构同池能力。考虑到日常运维便捷程度及可靠性，本次项目通过新建信创资源池来满足新建应用信创改造需求，具体平台架构图如下：

2、面向应用容器化、发布侧

制定准入标准及技术规范，让应用开发人员知道怎么去做应用容器化改造及应用制品的晋级路径，深入开展容器化使用培训，将技术的实际应用融入到平时工作中。

首先明确应用容器化接入流程，具体如下：

为了确保应用能够顺利接入容器云环境，通常需要采取一系列的评估和准备工作。具体来说，应用在接入容器云之前，必须经过一个详尽的自我评估过程，这一过程通常通过填写和应用自评表来完成。

自评表是一种结构化的工具，它包含了一系列的评估项目和标准，旨在帮助开发者和运维团队全面了解应用的当前状态，以及是否具备接入容器云的条件。自评的过程不仅有助于识别应用与容器云兼容性方面的潜在问题，还能够揭示出应用可能需要改进或重构的地方，以适应容器化环境的特殊要求。

在自评过程中，应用需要满足一系列关键的要求和标准。这些要求可能包括但不限于：

1、应用的架构设计是否符合微服务原则，以便能够在容器环境中灵活部署和扩展。

2、应用是否已经实现了资源隔离，以确保在容器云中运行时，不同应用之间不会相互干扰。

3、应用是否具有足够的日志记录和监控能力，以便在容器云环境中进行有效的故障排查和性能优化。

4、应用的配置是否已经参数化，以便于在不同的环境中灵活部署。

5、应用的依赖管理是否清晰明确，以确保在容器云环境中能够正确地拉取和管理所需的依赖库和组件。

6、通过这些自评标准的检查，应用团队可以确保其应用在技术上准备好接入容器云，并且能够充分利用容器云提供的灵活性、可扩展性和高可用性优势。自评过程完成后，应用团队将能够根据自评结果制定出详细的迁移计划，从而确保应用向容器云的平滑过渡。

对当前应用进行自行评估，分为强制规范和建议规范，强制规范必须满足。具体规范如下：

架构评审

架构评审是一个关键的过程，它涉及到对软件架构设计的全面审查。在应用上容器云的场景中，架构评审的目的是确保所设计的架构能够满足云环境和容器化技术的要求，并且能够支持应用的高效运行和灵活扩展。

在架构评审环节，通常会有一系列的检查点和标准，通过这些评审标准，团队可以确保应用在迁移到容器云环境时，其架构设计是健壮、高效且符合业务需求的。

通过架构评审确定该业务应用是否适合在容器云平台上发布。

容器云环境资源申请

业务应用通过架构评审后，已确定要在容器云平台上发布后，发起对应业务系统上线流程，申请容器云环境和资源。

容器云应用接入

容器云环境申请完成后，选择应用接入方式。目前容器云上应用接入方式如下：

一、有源码构建接入，适合行内有源码的业务应用；

二、应用包接入，适合不提供源码，但可以提供制品包的应用；

三、容器镜像接入，适合采购的厂商应用，直接提供了容器镜像和 K8s Yaml文件。

四、云效平台接入，适合镜像从测试环境晋级到生产，需要周期性迭代应用，需要提供dockerfile文件集成流水线。

如果应用接入方式为第一、第二类，需要按照容器镜像制作规范编写Dockerfile，制作容器镜像；然后按服务发布规范进行容器云平台的部署发布。

应用命名规范

针对中英文两组应用namespace命名规范如下：

Namespace-英文名称：环境（dev、sit、uat、prd、prd-gray）-四位系统编号（科技运营平台）

Namespace-中文名称：系统编号-系统名称-环境（dev、sit、uat、prd）

应用中服务命名规范如下：

应用服务名称规范：应用编号（六位科技运营平台）-机房编号（两位-yg（燕谷）、da（档案）、zh（总行））

镜像命名规范：

镜像默认由行内统一制品Nexus库通过单向同步链路同步至容器云Harbor镜像仓库，同步策略为：harbor.boc.sit.csrcb/docker-prd/系统编号/应用编号-应用英文名称:版本

四、项目过程管理

第一阶段：明确应用容器化改造思路。改造容器云集群。完成如麒麟基础镜像，jdk，nginx，nacos等行内常用中间件的信创镜像打包工作。

第二阶段：CI侧，应用使用平台自带流水线集成容器应用。CD侧，采用平台自身能力进行发布。

第三阶段：CI侧，应用使用行内DevOps工具云效平台进行流水线集成。CD侧，采用行内发布工具赞悦发布平台进行应用发布，实现全自动化的应用集成、发布。

五、运营情况

目前行内容器云平台生产环境承载业务系统35个，POD共计700个，信创相关集群的生产环境上线信创容器应用系统3个，为金融图盾系统、村镇积分运营系统、信贷移动审批系统；信创容器云环境接入测试应用系统包括中间业务平台、常银生活等共42个应用系统。本年度通过评审的75个信创改造系统无特殊情况下均计划采用容器化的形式推进改造工作。

六、总结展望

我行云原生平台在原生kubernetes基础上提供了企业级平台管理能力，实现应用全生命周期管理，加快应用和基础实施的现代化管理，快速响应业务部门需求，支撑业务系统的快速上线、迭代。平台在建设过程中结合我行数据中心网络重构工作，将node节点网络解耦为管理、业务、存储三组流量，避免了节点之间流量相互干扰的风险。在平台迭代过程中平台解决多集群管理、异构集群纳管、应用编排发布、中间件容器化等业务场景的容器落地，简化应用容器化上云后的管理复杂性。在平台迭代的基础上不忘应用及配套生态的建设，结合行内DevOps及生产发布等展开实践，将容器这项技术逐渐融入到金融科技应用发展的基础中。