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

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

1.背景概述...................................................................4

2.现状及分析................................................................4

2.1IT研发转型...........................................................5

2.2IT架构转型...........................................................5

2.3IT运维转型...........................................................5

2.4IT组织转型...........................................................6

3.建设方案.....................................................................6

3.1容器平台建设..........................................................6

3.1.1容器可编排性....................................................6

3.1.1.1多模式应用编排..........................................13

3.1.1.1.1应用容器编排......................................13

3.1.1.1.2应用混合编排......................................15

3.1.1.2负载均衡................................................16

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

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

3.1.1.3存储管理.................................................19

3.1.1.3.1数据持久化........................................19

3.1.1.3.2数据持久化保护与恢复.............................20

3.1.1.4网络方案.................................................21

3.1.1.4.1Calico.................................................................................22

3.1.1.4.2Flannel...............................................................................24

3.1.1.5弹性伸缩.................................................25

3.1.1.5.1弹性伸缩策略简介..................................25

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

3.1.1.6应用管理功能............................................27

3.1.1.6.1应用生命周期管理.................................27

3.1.1.6.2应用资源资源......................................30

3.1.1.6.3应用状态查询......................................32

3.1.1.6.4配置文件..........................................34

3.1.1.6.5镜像工厂..........................................35

3.1.1.6.6部署管理..........................................40

3.1.1.6.7应用商店..........................................42

3.1.1.6.8基于模板部署......................................47

3.1.1.7服务管理.................................................49

3.1.1.7.1服务管理..........................................49

3.1.1.7.2服务发现..........................................50

3.1.1.7.3数据库服务........................................50

3.1.1.7.4存储..............................................53

3.1.2容器平台可扩展性...............................................54

3.1.2.1集群规模扩展能力........................................54

3.1.2.2插件扩展能力.............................................54

3.1.2.3OpenAPI接口扩展能力.....................................55

3.1.3安全合规性对接.................................................55

3.1.3.1统一身份认证.............................................55

3.1.3.2与现有监控体系对接......................................56

3.1.3.3与集中日志系统对接......................................57

3.1.3.4与堡垒机对接............................................59

3.2统一知识库..........................................................60

3.2.1建设目标.......................................................61

3.2.2建设方案.......................................................61

3.2.3知识分类.......................................................64

3.3统一制品发布........................................................64

3.3.1方案架构......................................................65

3.3.2代码版本管理..................................................66

3.3.3自动化测试....................................................67

3.3.4打包构建......................................................67

3.3.5运行环境......................................................68

3.3.6持续部署......................................................68

3.3.7制品交付......................................................68

3.3.8合规性检查....................................................70

3.4统一资源申请平台....................................................73

3.4.1自助资源申请服务...............................................74

3.4.2在线审批流程..................................................74

3.4.3自动化部署.....................................................74

3.4.4自助运维.......................................................75

3.4.5自助监控告警...................................................75

3.4.6租期回收......................................................75

3.5容器统一规范........................................................76

3.5.1容器内应用的健康检测..........................................76

3.5.2应用容器的DNS配置...........................................76

3.5.2.1使用集群内部的DNS服务................................77

3.5.2.2使用集群外部的DNS服务................................77

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

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

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

3.5.3.3应用配置文件的热加载...................................82

3.5.4应用容器的日志配置............................................83

3.5.4.1容器的应用日志输出......................................83

3.5.4.2应用日志规范............................................86

3.5.5集群资源管理规范...............................................87

3.5.5.1应用容器的资源配置......................................87

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

3.5.5.3租户的资源管理规范......................................90

3.5.6投产审核.......................................................91

3.5.6.1配置信息.................................................92

3.5.6.2流程审批.................................................92

3.5.7自动化运维.....................................................92

3.5.7.1运维范围与目标..........................................92

3.5.7.2运维设计原则............................................93

3.5.7.3自动化运维体系建设......................................95

3.5.7.4运维技术栈关键设计......................................98

3.6高可用架构体系......................................................100

3.6.1方案概述......................................................100

3.6.2高可用部署方案...............................................101

3.6.2.1容器的故障恢复.........................................102

3.6.2.2镜像仓库的可用性.......................................102

3.6.2.3容器的可用性............................................102

3.6.2.4集群管理主机的可用性..................................103

3.6.2.5平台组件备份设计......................................104

3.6.3总体设计......................................................107

3.6.3.1平台部署................................................107

3.6.3.2部署架构说明............................................108

3.6.3.3负载均衡设计..........................................108

3.6.3.4切换架构................................................109

3.6.4灾备实现......................................................109

3.6.4.1数据备份................................................109

3.6.4.2应用层备份..............................................111

3.6.4.3平台灾备说明..........................................113

3.6.4.4回切场景................................................114

4.方案价值...................................................................114

4.1IT交付新能力...............................................115

4.2IT架构新能力.......................................................116

4.3IT运维新能力.......................................................116

1.背景概述

“十四五”期间的核心任务之一是科技创新，科技创新是引领发展的

第一动力，是推动高质量发展、建设现代化经济体系的战略支撑。传统企业

在今天都面临着新兴业务模式的剧烈冲击,同质化的竞争手段已无法让企

业在愈演愈烈的竞争中脱颖而出，包括银行、证券、保险以及政府金融机构

在内的传统企业，纷纷致力于数字化转型。在数字经济时代，以大数据、人

工智能、数据库为支撑的数字高速路，成为数字世界的基础。且科技创新需

要建立在数字化转型成功的基石和底座之上。

数字经济时代金融行业面临数字化转型挑战，利用容器云原生技术作

为支撑数字经济的数字底座，与公有云云原生采用相同的技术和架构，统

一的生态体系，在保障金融机构数据权益和行业监管的同时，能够快速获取

大数据、人工智能、数据库等新型云服务能力，满足“安全可靠+应用创新”

双重诉求，以快速应对市场变化。可以利用容器云原生上的数据治理能力，

实现数据统一管理，挖掘数据价值；可以利用容器云原生上的人工智能开发

平台和开发框架，持续积累训练数据、算法模型和知识图谱，储备人才，探

索前沿科技；可以利用容器云原生上的应用管理、微服务和DevOps技术，

落地人工智能、金融级的应用，并且能够提升开发生产效率。倡导各金融机

构结合自身实际情况，积极推进混合云的部署和建设，引入业界先进的云服

务，支撑金融机构基于容器云原生灵活创新。

2.现状及分析

银行的业务应用目前以多种形态运行在不同的技术栈上，包括互联网

技术栈和商业技术栈。大多数系统已经完成新一代的升级，但是随着容器的

发展很多银行开始试水分布式架构体系改造。

由于银行交易往往比较重要，有哪些系统最适合云原生容器化改造，应

用在进行改造后如何符合银行现有规范等问题也显露出来。

1.对容器技术没接触或接触少的研发部门会面临新技术的学习成本高，改

造难度大等问题；

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

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

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

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

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

在互联网+金融和自主可控两大趋势的影响下，中国金融IT领域掀起

了一场规模空前的转型大潮。传统的IT流程、基础架构和运维模式已经

无法满足业务发展的需求和竞争形态的转变，传统金融机构都在考虑未来

的IT开发机制、IT架构等如何变革。

2.1IT研发转型

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

互联网思维的根本就是快，只有快速响应用户需求才能在激烈的市场

竞争中占据优势。在互联网+转型的过程中，金融行业信息化建设的关键是

及时响应业务需求、适应多变的商业环境的灵活的IT架构，以满足不同

部门、客户和合作伙伴的各种需求。然而，传统的研发模型已经成为应用交

付和迭代速度的瓶颈，IT研发流程和亟待转型。

2.2IT架构转型

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

在IT基础架构层面，很多金融企业都是烟囱式架构，烟囱式架构带

来的最大问题是能力孤岛，不同的应用系统之间的资源无法实现共享。并且,

在金融走向普惠、拥抱长尾市场的过程中，传统金融IT架构无法支撑巨

量涌入的长尾客户.随着互联网+转型的深入，IT基础架构需要获得更多

的弹性，从而满足互联网业务对弹性伸缩的需求。

因此，IT系统的云化势在必行。大部分金融企业已经意识到从烟囱式向分

布式架构转型的重要性。然而，当前许多架构转型的方案需要经历推倒重来

的阵痛，这让他们对云化IT基础架构裹足不前。他们需要一套能够实现

无痛、渐进式向云计算迁移的方案。

2.3IT运维转型

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

金融IT运维人员的压力之大众所周知，这源于金融行业对业务连续

性和可用性的严苛要求。然而，随着金融信息化的不断发展，金融IT环

境正在变得越来越复杂：应用纷繁复杂、IT架构异构、IT规模日益增大，

这些都导致运维的难度越来越大，运维部门需要全新的思路来应对复杂环

境下IT系统运维的压力。

2.4IT组织转型

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

互联网的业务拓展和产品研发，讲究唯快不破。业务的交付速度、快速

迭代和几乎实时的用户响应，是互联网公司所追求的目标；其研发、运营等

组织结构的设计，内部流程审批等权力的分配，也都充分考虑了这样的业务

特征和目标。金融行业追求安全第一，但在互联网的节奏下，如何平衡唯快

不破与安全第一？如何优化组织结构，在使用技术手段保障安全的同时，在

运营环节提高效率、精简流程？这是很多金融决策者需要思考的问题，也

是对金融企业管理层提出的新挑战。

3.建设方案

3.1容器平台建设

容器技术在金融行业的应用场景非常广泛，从开发测试环境到生产环

境，都可以采用容器技术。以Docker为代表的容器技术，为金融IT和

业务转型带来了近乎颠覆性的思路。

从容器技术的使用场景来看，非常适合使用容器技术的应用主要包括

几个类型：需要经常更新和快速迭代的应用、需要在云中运行的应用，以及

需要从DevOps和微服务中受益的应用等。下面总结了几个适合采用

Docker容器技术的场景，包括CI/CD持续交付、大规模集群管理、混合

云、数据分析应用、微服务化应用、以及云原生应用(CloudNative

Application)等。

3.1.1容器可编排性

容器云平台技术架构，需要符合云原生技术的发展方向，能支持分布

式应用，故而选择合适的容器的管理和编排(Orchestration)工具尤为重

要。初级的编排，是资源的编排，即针对物理机或者虚拟机；但更高层次的

是服务的编排，需要对架构层次在整体上有一个完整的定义。

Docker技术所解决问题的对象是面向“一个应用”。而在真实的云环

境中，工程师需要面对的是将数十类应用构成的“综合系统”，部署为成

百上千个具体实例。这样庞大的工作依靠人工来进行实施显然是难度巨大

且风险和成本均极高的。因此就需要有对应于容器运行时的编排技术来解

决海量容器的生命周期管理工作，Kubernetes就是原生技术生态中已成为

事实行业标准的一种容器编排技术。

Kubernetes这个名字起源于古希腊，译为“舵手”。如果Docker把

自己定位为驮着集装箱在大海上遨游的鲸鱼，那么Kubernetes就是掌舵

大航海时代话语权的舵手，指挥着这条鲸鱼按照舵手设定的路线巡游。

Kubernetes是Google开源的容微集群管理系统，由Google多年大

规模容器管理技术Borg演化而来，并赠给云原生计算基金会（CNCF）,其

主要功能包括：

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

•负载均衡和服务发现；

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

•容器负载自动伸缩；

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

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

apiVersion:

extensions/vlbeTal

kind:Ingress

metadata:

name:test

spec:

rules:

-host:www.example.CM

http:

paths:

-path:Ztastl

backend:

serviceNarte:si

servicePort:80

-path:/test2

backend:

serviceNarte:s2

servicePort:80

声明式语言定义服务状态自动化实现并维持服务状态

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

如上图所示，Kubernetes通过符合YAML标准的声明式语言定义

Kubernetes内所有允许的资源类型，包括如Pod^DeploymentxService

等等。作为基础调度单元，容器组(Pod)通过组织一组紧密关联的容器

(Container),他们共享网络和文件系统的特性，而对外提供某一项应用

服务能力，并接受Kubernetes对于其生命周期和接口能力的管理。

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

•解决了大规模应用运维的规模性问题，自动化支持海量应用的编排及

生命周期管理；

•通过简单的声明式语言(YAML)描述了应用的拓扑结构和生命周期，

解决了Dockerfile无法描述应用自身之外的环境问题，将“从代

码到应用”演进到“从代码到服务”；

•应用负载实时弹性扩容，无需经过冗长的申请资源、安装操作系统、

部署应用、测试、负载上线的繁琐过程，轻松面对流量波峰，完整释

放Docker的生产力；

•流量切分和发布策略配合，实现持续交付，整合精益管理，支持

DevOps实践落地；

•开放API,实现对各种第三方网络、存储解决方案的支持能力，满足

企业用户的生产需求；

•抽象底层环境，标准化镜像、标准化编排，大规模应用亦可随时迁移，

不用担心被厂商绑定。

除功能支持外，对于企业生产级支撑平台的选型考虑，编排引擎作为调

度核心能力的实现技术，应考虑其未来长期可持续扩展的能力是否能够满

足企业业务增长需求。Kubernetes单一集群内最大可支持5000个节点部

署，支持包含150000个容器组或300000个容器。再加上多集群扩展的能

力，从生产规模支持上完全可满足企业未来长期的业务增长需求。

Kubernetes自身提供的是对由一组容器定义的对象Pod提供了运维

能力、弹性能力、调度能力、及服务访问能力等几个方面的功能，其对容器

运行时、存储、网络等等所有会差异化的外围服务均在以接口驱动的形式来

提供支持，即ContainerRuntimeInterface(CRT)、ContainerStorage

Interface(CSI)、ContainerNetworkInterface(CNI)。如下图所示：

ContainerRuntimeInterface

图-Kubernetes的Interface设计模式

对于极特殊情况，当原生内部定义的资源对象如存储类型等无法满足

企业需求时，也可以通过CustomResourceDefinition(CRD)来实现新的

资源定义扩展API,使得Kubernetes的开放性可以进一步被无限放大。

如下图所示CRD原理：

client-go

1)Ust&Watch

ReflectorKubernetes

API

2)AddObject

Kubernetesserver-side

DeltaRfo

queue

3)PopObject

4)AddObject

Informer

ResEvertHandlers

referenceThreadsafestore

6)

CustomController)

Informer^Indexer

Resource

referencereferenc

Event

Handlers9)GetObjectforKey

8)GetKeyProcessHandle

ItemObject

7)Enqueue-

O*dWorkqueue

Key

Custom

图-CRD原理

通过以上设计，使得Kubernetes面对不同的容器运行时、网络、存储

实现甚至是特殊的资源形态要求时，均可通过扩展驱动实现有效兼容，而不

用更改其核心功能实现，换言之Kubernetes的兼容性设计很大程度上取

决于它的设计边界即是操作这些资源驱动程序，而不是操作某个资源实体

本身，是一个高度通用的抽象。基于这样的架构设计，使得Kubernetes具

备了与生俱来的可兼容性，原理上可以认为，只要下游部署实现不修改上游

原有的代码，即使各类部署均具备了对Kubernetes的一致兼容性。

Kubernetes已经成为事实上的容器管理的标准，世界上大多数公司都

使用它作为容器管理和编排，其有以下儿大优势：

•开源的力量

在不断扩大的容器应用领域，Kubernetes已发展成为事实上的行业标

准。因此，您可以选择多种服务提供商来帮助您在组织的IT基础架构中

实施它。如果出现任何问题，Kubernetes开发者的开放社区可以指望做正

确的事情。更重要的是，Kubernetes并不是一个开源了就不再活跃的项目，

而是一个全年四次大版本更新的项目。

•成本效益

容器的复杂性和占用空间都很轻，而且设置它们比设置VM要简单得

多。这使得Kubernetes成为管理容器化应用程序的非常灵活的平台。

Kubernetes配置可减少错误的CPU周期和GB的RAM,从而缩短响应时

间，最终提高系统性能。并且由于Kubernetes的负载平衡引擎，它可以在

需要时启动，停止和优先处理给定的容器-所有这些都可以保持性能一致。

•可移植性

由于其多功能性，Kubernetes可以在您的组织内本地设置和运行在大

量底层操作系统上。此外，如果您决定在整个生命周期的部署过程中迁移到

备用操作系统，您可以随身携带现有工作负载，而无需重新设计应用程序

或废品并重新构建基础架构。Kubernetes避免了供应商锁定，您的设置将

继续标准化并随着时间的推移而简化。

•可扩展性

Kubernetes从头开始设计为模块化容器管理工具(CM),您可以自

由选择混合和匹配组件，实现真正的交钥匙和定制实施。使用Kubernetes,

您可以决定要运行的操作系统，应用运行时(Libs/Bins),文件系统，

处理器架构甚至云平台。应用程序开发人员还可以直接调用Kubernetes

API(应用程序编程接口)，并加强应用程序的集成，以提高性能和可管理

性。

•自愈

软件将不时遭受奇怪的故障，导致功能瘫痪和系统失败。然而，这些陷

阱将使您成为可靠性困境的牺牲品。但不要害怕：Kubernetes能够定期监

控您的完整基础设施(容器，节点，Pod,网络，硬件，操作系统)。如果

软件错误导致系统的某些部分崩溃，Kubernetes将立即重启应用程序。如

果错误是由于硬件故障引起的，Kubernetes将检测到它并将应用程序分

布在多个pod中。在这两种情况下，应用程序停机时间都减少到最低限度。

•云服务

因为Kubernetes很受欢迎，用户不需要自己处理内部实现，也不需

要在硬件上花钱。事实上，用户可以通过注册托管的Kubernetes解决方

案来外包流程：PaaS（平台即服务）或laaS（基础架构即服务）。用户的

角色是专注于通过用户的应用提供最佳体验，将负载平衡和云服务留给

Kuberneteso

综上所述，容器管理和编排技术建议选择Kubernetes,根据开源社区

版本迭代计划，融合业内实践，推荐版本为Kubernetes1.16及以上稳定

版本。

容器平台提供应用可视化编排部署的相关管理功能，包括拓扑可视化、

组件可视化、配置可视化等核心功能。在此基础之上，容器平台还提供了F5、

数据库、DNS、软件负载均衡等常见平台组件及服务的封装功能，实现组件

的配置管理、可视化编排支持等功能。容器平台支持的编排功能如下：

・应用模板管理与认证：应用模板管理功能支持应用模板新建、删除、

修改等操作。同时容器平台提供丰富的应用模板管理能力，比如批量

上传应用模板、添加/修改模板变量、展示和修改应用模板描述信息、

展示模板与相关应用的关联情况、提供从模板部署应用的向导、支持

模板分类和搜索。模板功能还支持验证公有/私有模板，并且支持模

板权限配置，设定访问权限。

•应用编排管理：容器平台的应用编排管理功能较为丰富。不仅支持与

数据库、F5等周边系统混编，还支持更为完善的应用编排管理能

力,比如支持KubernetesYAML编排标准、支持图形化展示编排、

同时编排基础设施资源、支持编排时指定日志策略/调度策略、支

持图形化修改和维护编排。

•应用配置管理：容器平台可以为应用编排设置应用程序日志、应用端

口等配置信息。

•容器信息查询：容器平台支持用户以应用系统为维度，查看应用中容

器名称、软件版本、配置信息、所属应用、所属宿主机、运行状态等

信息。同时容器平台根据企业级用户的需求，展示更多可用信息，包

括镜像层级信息、镜像改动记录、容器内进程信息、容器网络信息、

容器存储信息、应用/容器操作审计日志信息、应用可视化拓扑以及

编排信息等。

.容器操作功能：在编排功能下，容器平台提供了常用的应用容器操作

功能，包括启动、停止、创建、删除等。并且容器平台为了方便企业

级用户的操作，额外提供了更为丰富的容微操作功能，包括从容器内

下载文件、向容器上传文件、支持打开容器内部Shell控制台、

支持从容器一键制作新镜像、重启容器、暂停以及恢复容器、在不中

断容器内业务服务的情况下修改容器资源配额。

•负载均衡展示：容器平台提供内置负载均衡，并能够展示应用整体负

载情况，同时容器平台可对接F5等外部负载均衡系统或设备，并且

支持提供应用级别的负载均衡，应对微服务架构。

•服务到容器的自动负载分发：容器平台负载均衡默认采用Linux内

核中的LVS技术，相对于其他软件负载性能较高，并且负载均衡可

以配置SSL证书，当服务的容器扩展后，负载均衡可以自动发现后

端服务变化并自动适配，负载均衡可提供多种负载策略，可以通过环

境变量进行配置，具备会话保持的功能。

•版本管理/灰度发布：针对企业级发布应用的场景，容器平台支持应用

版本升级时对各集群进行灰度升级，保证业务的不间断运行，同时容

器平台还支持更高级的灰度发布选项，比如设定并行发布实例数、设

置发布失败后的错误处理机制、配置发布时旧版本实例优雅下线策

略。

3.LI.1多模式应用编排

3.1.1.1.1应用容器编排

云原生技术平台管理系统提供了应用可视化编排部署的相关管理功能,

包括拓扑可视化、组件可视化、配置可视化等核心功能。在此基础之上，云

原生技术平台管理系统还提供了F5、数据库、DNS、软件负载均衡等常见平

台组件及服务的封装功能，实现组件的配置管理、可视化编排支持等功能。

云原生技术平台管理系统支持的编排功能有：

・应用模板管理与认证：应用模板管理功能支持应用模板新建、删除、

修改等操作。同时云原生技术平台管理系统提供了更为丰富的应用模

板管理能力，比如批量上传应用模板、添加/修改模板变量、展示

和修改应用模板描述信息、展示模板与相关应用的关联情况、提

供从模板部署应用的向导、支持模板分类和搜索。模板功能还支持

验证公有/私有模板，并且支持模板权限配置，设定访问权限。

•应用编排管理：云原生技术平台管理系统的应用编排管理功能较为丰

富。不仅支持与数据库、F5等周边系统混编，还支持更为完善的应

用编排管理能力，比如支持KubernetesYAML编排标准、支持图形

化展示编排、同时编排基础设施资源、支持编排时指定日志策略/调

度策略、支持图形化修改和维护编排。

•应用配置管理：云原生技术平台管理系统可以为应用编排设置应用程

序日志、应用端口等配置信息。

•容器信息查询：云原生技术平台管理系统支持用户以应用系统为维度,

查看应用中容器名称、软件版本、配置信息、所属应用、所属宿主机、

运行状态等信息。同时云原生技术平台管理系统根据企业级用户的需

求，展示更多可用信息，包括镜像层级信息、镜像改动记录、容器内

进程信息、容器网络信息、容器存储信息、应用/容器操作审计日

志信息、应用可视化拓扑以及编排信息等。

•容器操作功能：在编排功能下，云原生技术平台管理系统提供了常用

的应用容器操作功能，包括启动、停止、创建、删除等。并且云原生

技术平台管理系统为了方便企业级用户的操作，额外提供了更为丰富

的容器操作功能，包括从容器内下载文件、向容器上传文件、支持打

开容器内部Shell控制台、支持从容器一键制作新镜像、重启容器、

暂停以及恢复容器、在不中断容器内业务服务的情况下修改容器资源

配额。

•负载均衡展示：云原生技术平台管理系统提供内置负载均衡，并能够

展示应用整体负载情况，同时云原生技术平台管理系统可对接F5

等外部负载均衡系统或设备，并且支持提供应用级别的负载均衡，应

对微服务架构。

•服务到容器的自动负载分发：云原生技术平台管理系统负载均衡默认

采用Linux内核中的LVS技术，相对于其他软件负载性能较高，

并且负载均衡可以配置SSL证书，当服务的容器扩展后，负载均衡

可以自动发现后端服务变化并自动适配，负载均衡可提供多种负载

策略，可以通过环境变量进行配置，具备会话保持的功能。

•版本管理/灰度发布：针对企业级发布应用的场景，云原生技术平台

管理系统支持应用版本升级时对各集群进行灰度升级，保证业务的不

间断运行，同事云原生技术平台管理系统还支持更高级的灰度发布选

项，比如设定并行发布实例数、设置发布失败后的错误处理机制、配

置发布时旧版本实例优雅下线策略。

3.1.1.1.2应用混合编排

现有的应用开发流程中，为了提高研发效率，相关部门会预先配置好一

部分数据库服务用于研发测试。根据研发业务的不同，数据库服务包

括：Oracle服务，MSSQL服务以及DB2服务。

随着业务量的增长，相应的研发生产线也呈多样化发展，向研发测试提

供数据库服务部门的压力也越来越大。现有的情况下，研发测试面临着申请

数据库服务流程周期长，服务部门向不同研发生产线交付相应的数据库服

务的压力也越来越大。

云原生技术平台管理系统的数据库混合编排借鉴了公有云的数据库编

排服务，经过了大规模使用的验证。云原生技术平台管理系统的数据库混

合编排主要有以下几点特征：

•服务注册：当服务部门配置好相关数据库服务后，可通过WEB页面

向服务注册模块注册该数据库服务，供研发测试部门使用。可通过选

择不同的数据库服务类型来注册数据库服务，包括：Oracle数据库服

务、MSSQL数据库服务、DB2数据库服务等。

•服务管理：可通过WEB页面对已注册的数据库服务进行管理，管理

操作包括：增加新数据库服务，删除已有数据库服务，更新已有数据

库服务配置，删除数据库服务。

•服务绑定：可通过应用的页面将数据库服务绑定到应用容器内，服务

绑定将数据库的信息设置到应用容器的环境变量内，供应用容器取用。

•服务发现：该方案依托客户端服务发现的场景，“数据库服务发现应

用”提供了一系列RESTAPI供客户端调用，并可将数据库配置信息

以结构化数据的形式返回供客户端使用。

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

图-混合编排架构图

云原生技术平台管理系统数据库混合编排服务将云原生技术平台管理

系统与数据库资源池深度集成。“数据库服务编排应用”以插件的形式部

署在云原生技术平台管理系统平台上。该应用将提供对接云原生技术平台

管理系统用户权限控制模块的功能。通过对API进行授权访问，可控制特

定用户访问特定的数据库服务资源。“数据库服务发现应用”将对接云原

生技术平台管理系统的用户权限控制，避免二次配置用户权限。

3.1.1.2负载均衡

云原生技术平台管理系统支持两种负载均衡方案：7层负载均衡和4

层负载均衡，需要在不同的应用场景下选用不同的负载均衡方案。云原生技

术平台管理系统负载均衡方案整体架构图如下所示：

访问审核/DDOS清洗

图-负载均衡

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

云原生技术平台管理系统的4层负载均衡TPVS解决方案主要用于

弹性伸缩的场景，通过端口转发将请求转发至多个容器内，应用场景如下图

所示：

0LB:PORT

O部署应用，并配置多实例

开发

针对该场景，云原生技术平台管理系统内置了一套TPVS负载均衡的

解决方案。

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

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

访问应用IP：8O8O

访问应用IP：8080

808080808080©

集群启用

RoutingMesh

O।Ingress网络/

导出端口至8080

开发

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

•Docker内置机制

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

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

•自动适配后端应用变化

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

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

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

云原生技术平台管理系统内置的IPVS能力之上提供了一套7层负

载均衡组件如Nginx、HAProxy和Traefik等，该组件通过自动获得集

群中服务的域名配置（目前通过服务label实现），自动更新负载均衡转发

策略。

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

O为应用配置域名

LB状毒。访问应用域名

开发一—一—J

_________________________L

「一q

80808080

0前■条伸1:

部署黑蛆上，并创建|Manager][LB]

•1映LB的80端口被导出

LB专用'&n血网络sl

至DCE80端口

・DNS能把域名解析至DCE

的某几台1P

注：

•如臬DCE的80端口被占用

APP3

了，应用的访问URL就需要

v,

①用一一一一一一―^r^2T2?~22用URL：PORT

I笳入Is城K

开发

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

•友好的图形界面管理能力

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

•高性能请求转发

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

•自动适配后端应用变化

•优雅的中断HTTP连接

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

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

•提供简单的性能监控报表

•HTTP2支持

•Websocket支持

•HTTPS/SSL支持

3.1.1.3存储管理

3.1.1.3.1数据持久化

容器运行期间产生的数据是不会在写镜像里面的，重新用此镜像启动

新的容器就会初始化镜像，会加一个全新的读写入层来保存数据。如果想做

到数据持久化，就必须寻求其他解决方案来保存数据。

云原生技术平台管理系统通过存储卷（volume）用于持久化存储

Docker容器的数据，存储卷分为本地卷和远程卷和快照，其中本地卷是对

本机磁盘的映射，远程卷和和快照需要在集成中心集成第三方存储服务（比

如ScalelO）才可以使用：

•本地存储卷：本地卷没有容量或读写性能的限制（上限由磁盘的规格

和性能决定）。本地卷亦不可创建快照。一般地，在创建应用时，可

以通ComposeYAML指定。

・远程存储卷二远程卷的创建以及使用过程同本地卷类似。云原生技术

平台管理系统远程存储卷包括NFS存储卷和其他远程存储卷。NFS

远程卷的创建需要增加设备、读写权限、设备目录的信息。其他远程

存储卷主要包括支持ScalelO等存储软件的REXRAY驱动存储卷，

以及VMDK存储卷。

3.1.1.3.