容器云的技术发展趋势

CONTENTS 目
录

1 容器云
容器的诞生：Docker 1

容器的调度与管理：编排引擎 1

基于容器技术构建的数字平台：容器云平台 2

2 容器云平台技术解析
交互层 4

接口层 5

PaaS 服务层 - 应用服务 6

PaaS 服务层 - 平台服务 8

基础层 15

运维 21

安全 25

3
容器云平台发展现状 27

垂直行业应用 28

国内主流的容器云平台产品介绍 30

容器云平台的发展策略 39

4 容器云平台的机遇与挑战
云原生技术发展 41

企业级需求 41

从支撑应用到支撑数据 - 数据云平台（Data Cloud） 43

前言 PREFACE
1 容器云
1.1 容器的诞生：Docker

在云计算发展初期，虚拟化技术盛行。虽然传统的虚拟化技术解决了硬件层的资源共享问题。
但是在日常开发中，从本地到服务端存在兼容性问题，通常表现为本地运行良好，投入生产环
境后却问题百出，不利于持续集成和持续交付。

而容器化通过将应用程序代码和其他依赖项（配置文件等）打包成为一个文件，运行这个文件
就会形成一个容器，在这个封闭的环境中容器提供了程序需要的一切，容器也不会捆绑应用环
境所依赖的操作系统，轻量级不言而喻。

2013 年，Docker 诞生之后就风靡全球。它是目前应用最广泛的容器引擎技术之一。Docker 使

用 Linux 内核和其相关功能（例如 Cgroups 和 namespaces）分隔进程，各进程相互独立运
行。独立运行多种进程、多个应用，更加充分地利用基础资源，同时保持各个独立系统的安全
性也正是采用容器的意义。

1.2 容器的调度与管理：编排引擎

Docker 作为一款开源的容器引擎工具，帮助开发者将应用程序打包到容器中，可实现发布到任
何 Linux 机器上。近几年，Docker 逐渐受到行业的认可，但随着 Docker 开始集群部署到生产
环境，容器集群如何部署与管理成了难题，需要一套容器编排引擎/系统，实现容器的自动化部
署、大规模可伸缩及应用容器化管理。

主流的容器编排引擎有 Kubernetes、Mesos 和 Swarm。在进入 2017 年之后，Kubernetes 强

势崛起，主流厂商纷纷投入到围绕 Kubernetes 展开的生态建设中，这其中也包括 Docker 公
司。容器编排之争以 CNCF 阵营的胜利告一段落，Kubernetes 已经成为了事实上的容器编排标
准。

我们通常说的容器云，即 CaaS（Container as a Service，容器即服务），指以开源容器和容器

编排引擎为基础，按照容器为资源分割的基本单位，封装各类应用和运行环境，为开发者和系
统管理者提供用于构建、发布和运行分布式应用的平台。同时平台内置各项基础服务，可帮助
企业快速满足应容器化和应用上云的需求。CaaS 同时提供了传统的 IaaS 和 PaaS 两者的能
力，包括资源访问、操作系统安装与升级、网络配置等 IaaS 功能，以及应用的部署、管理、配
置等 PasS 功能。

1
1.3 基于容器技术构建的数字平台：容器云平台

正是因为“Docker+Kubernetes ”为主体的容器云平台满足了敏捷开发与简易运维的需求，使
得容器技术的出现成为了云计算发展的关键节点。

在企业侧，在降本增效的目标下，加快数字化业务发展成为必然。基于此，越来越多的企业开
始拥抱容器化趋势，根据自身需求选择相应的服务，直接获得了效率提高、降低成本、灵活部
署、高可用等优势，并且已经有部分企业率先开始将核心业务使用容器部署。根据 sysdig 发布
的 2019 年容器使用报告显示，已有 77% 的用户正在使用 Kubernetes 技术。

2015 年 CNCF（Cloud Native Computing Foundation，云原生计算基金会） 成立之后，托管

了 Kubernetes、Prometheus、Envoy、CoreDNS、Containerd、Fluentd 等一系列项目。CNCF
提出了云原生的概念。云原生是面向云应用设计的一种思想理念，充分发挥云效能的最佳实践
路径，帮助企业构建弹性可靠、松耦合、易管理可观测的应用系统，提升交付效率，降低运维
复杂度。代表技术包括不可变基础设施、服务网格、声明式 API 及 Serverless 等。

因此我们今天说的容器云平台，已经不是指 CaaS，而是指以容器技术为核心，结合云原生技
术，以支撑企业数字化为目标构建的数字云平台。它已经成为基础设施的重要一环，随着容器
技术的不断普及，越来越多的架构、框架开始拥抱容器生态，向云原生进行迁移，如 Flink、
Spark、TensorFlow、Serverless 等。未来，容器技术也将会在隔离性、安全性等方面的不断完
善，扩展更多的使用场景。随着新基建浪潮的推进，我国的企业数字化转型步伐将继续加快，
容器、云计算、大数据等新兴技术势必得到更好的融合，更加快速地推广。

2
2 容器云平台技术解析
交互层

接口层
容
器
云 PaaS服务层
平
台

基础层

容器云平台定义

从技术角度看，容器云平台是采用容器、容器编排、服务网格，无服务等技术构建的一种轻量
化 PaaS 平台。容器云平台将传统云计算的 IaaS 层和 PaaS 层融合，为应用提供了开发、编
排、发布、治理和运维等全生命周期管理（Application Lifecycle Management，ALM）的能
力。对于应用运行依赖的数据库、中间件、微服务基础组件、大数据组件、人工智能组件以及
其他第三方组件，容器云平台会负责这些组件的生命周期管理，并且以服务的方式以供应用使
用。

上图具体展示了容器云平台的整体架构，自下而上包括交互（UI）层、接口（API）层、PaaS
服务层、基础层。运维和安全则涵盖了从应用层到容器云引擎层的部分。

·
·
· 企业需要使用业务应用和数据应用满足其业务需求。这些业务应用和数据应用
会利用平台层提供的能力，实现其自身的生命周期管理。同时这些应用运行所依赖的服务也
由平台提供，并负责其生命周期管理。容器云平台可以内置一些常用的业务和数据应用，供
企业直接使用。平台管理提供了对租户，用户，集群和服务目录的管理功能。平台运营提供
了多维度租户资源，应用性能，API 调用等计量、计费和报表功能。DevOps 为应用开发提供
了项目管理，持续集成和持续发布等功能。应用市场为应用提供了上架/下架功能，供用户将
应用共享给第三方以及部署到平台上。应用治理为运行在平台上的应用提供了应用性能管
理、认证授权、API 管理和服务拓扑管理等功能 。协作模块为应用开发/测试/运维等多种角
色用户提供了工单、流程和消息功能。服务目录为运行在平台上的应用提供了微服务、中间
件、大数据、人工智能和数据库等服务生命周期管理功能，应用可以通过平台的 API 创建，
绑定，更新和销毁这些服务。第三方应用也可以将自己注册为平台的服务，供其他应用使
用。

3
· 基础层：以 Kubernetes 为核心，包括服务网格、无服务计算、容器引擎、制品仓库、操作系
统、存储和基础设施，主要实现对计算、网络和存储资源的池化管理，以及以 Pod 为核心的
调度和管理。

容器云平台相比传统 PaaS 平台，容器技术和 Kubernetes 容器编排引擎为应用提供了 DevOps

集成能力、持续发布策略、扩缩容、服务治理等能力，使得开发者更专注于业务逻辑的开发，
充分利用容器云平台的能力，通过自动化缩短业务迭代上线周期、优化资源利用率、提高服务
响应效率，从而可最大程度利用云服务和提升软件交付能力，进一步加速企业的数字化。

接下来将为读者详细介绍容器云平台各层的含义和典型组件。

2.1 交互层

2.1.1 Portal（云门户）

云门户为不同角色的用户提供了统一的主页、用户中心（用户信息管理）、消息中心、各个子
模块和解决方案（为了完成某个场景的工作，而由多个子模块组成）的入口。例如租户运维的
门户包含了当前租户（对应企业组织）下所拥有的资源以及平台运维的入口；例如数据开发者
的门户包含了数据源、数据级、数据工作流、结果集等等入口。

通常情况下，用户可以基于云门户扩展出自己风格的门户，使用个性化的、统一的方式集成企
业相关信息、业务流程和人员等信息，让使用者可以通过一个统一的页面框架和可视化的组件
结构来聚合和呈现。

2.1.2 CLI

为了方便云平台用户，尤其是 SRE 工程师，高效地和云平台进行交互，云平台会提供完整的命

令行供用户使用。命令行是对云平台 Open API 的封装，提供了丰富的平台控制与自动化的管理
能力。

以 Kubernetes 的命令行工具 Kubectl 为例，用户可以使用它对 Kubernetes 集群进行控制。

Kubectl - https://kubernetes.io/zh/docs/reference/kubectl/

4
2.2 接口层

2.2.1 Open API

云平台一般都会遵循 Restful API 的格式，提供基于资源的、通过 HTTP 暴露的 API。API 支持通

过标准的 HTTP 动词（POST、PUT、PATCH、DELETE 和 GET） 检视、创建、更新和删除资源。
API 是与编程语言无关的接口描述，使人和计算机都可以发现和理解服务的功能，且无需访问源
代码、其他文档或检查网络流量。通过 API 正确定义后，使用者可以使用最少的实现逻辑来执
行远程服务并与之交互。

OpenAPI 或者说开放 API，除了 API 本身可以供第三方使用之外，更重要的是指 API 本身被业内

很多服务提供者所遵循，例如 RSS——要么是因为业内形成事实标准，要么是已经被标准化组
织采纳。

OpenAPI 的格式本身可以使用业界通用的 OpenAPI 规范。而云平台的 Open API 则可以参考

Kubernetes 的 Open API。

同时云平台会提供多种语言的 SDK，对云平台的 Open API 进行封装，方便被第三方使用（例如

被云管平台集成）。第三方平台可以通过 SDK 在不同阶段调用云平台提供的服务能力，例如执
行 ETL 任务或者做应用的扩容。

同时，云平台可以按照规范集成第三方的能力，第三方服务可以将自己的能力注册到云平台
上，使之成为云平台能力的一部分，供云平台上的其他应用使用，典型的例子就是通过服务目
录（Service Catalog）将第三方服务的能力集成到云平台上。以地理位置服务举例，它按照
Service Broker 的方式对自身服务的管理进行封装，注册到云平台的 Service Catalog （服务目
录）上，这样云平台上应用就可以基于 Service Catalog 的 API 来申请和使用地理位置服务。

OpenAPI 规范 - https://www.openapis.org/
Kubernetes Open API - https://kubernetes.io/zh/docs/reference/using-api/api-concepts/
Service Catalog - https://kubernetes.io/docs/concepts/extend-kubernetes/service-
catalog/

5
2.3 PaaS 服务层 - 应用服务
业务应用和数据应用用于支撑企业业务的日常运作，企业在此基础之上可以构建自己的业务中
台和数据中台。业务中台是阿里巴巴首先提出的企业 IT 架构的转型之道，它站在企业全局的视
角，从整体战略、业务支撑、连接上下游和业务创新等方面进行统筹规划。而数据中台是对平
台提供的数据库、大数据和 AI 能力的有机整合，完成端到端的数据收集、分析、展现，并以
API 的方式供业务应用使用。

2.3.1 业务应用

典型的业务应用系统包括电商应用、营销应用、物流应用和支付应用等。每个行业，每家公司
需要的业务应用系统不尽相同，它会基于平台层提供的服务能力构建出满足自身需求的业务应
用系统。

一个典型的电商应用架构如下：

网站前台 移动APP 微信 买家中心 会员录入 收银结算 会员积分 班结日结

店铺管理 会员管理 店铺管理 交易管理 零售系统

商品管理 页面管理 产品管理 资金账户 ERP系统

订单管理 统计分析 库存管理 统计分析 …系统

设置 物流管理

异业合作 发票管理 会员卡管理 银行卡支付 微信支付

优惠券管理 积分管理 清算管理 支付宝支付 其他支付

为了更好理解数据应用，首先要回顾一下数据的发展阶段和趋势。

随着数据的价值凸显， 以 Google、Facebook、Amazon 为代表的企业已经完成了从 IT 巨头到

DT 巨头的转变。 这些公司借助其在大数据、 云计算、 人工智能的技术发展优势， 快速实现业
务数据化、 数据资产化和企业经营数据化， 加速商业价值的转化， 在引领技术风向的同时获取
了巨大的商业成功。 数据作为企业 IT 的重要要素之一，通过统一化、资产化、业务化和生态化
进程，助力于挖掘和发挥企业数据的价值，这对企业发展、企业战略转型具有重要意义。

6
 数据统一化 数据资产化 数据业务化 数据生态化

· 数据集中处理 · 数据整合 · 数据化运营 · 数据域业务闭环

· 统一的元数据 · 数据质量管理 · 智能应用 · 运营数据
· 统一的计算平台 · 资产化与计量 · 在线数据服务 · 服务和应用共享

参考资料：星环科技官网

（一）数据统一化
在该阶段中， 企业需构建出灵活的技术平台来支撑足够大的数据量级、 超大的数据维度、 多样
化的数据类型， 开始进行相关的数据统一化工作， 包括构建统一的计算输出平台、 统一的元数
据管理和数据标准， 并逐步将数据整合在该平台中。

（二）数据资产化
实现数据统一化后， 需要以数据分析等方式实现数据整合和最终资产化， 同时通过有效的数据
质量管理保证数据的质量和有效性。 平台中积累的高质量数据越多， 越会吸引更多的开发人
员， 促进企业根据数据的特点完成数据资产化工作， 其中包括数据与业务字典的对接、 数据管
理流程等， 从而将原始数据变为有价值的资产。

（三）数据业务化
完成数据统一化和资产化后， 企业便拥有强大的计算能力和丰富的数据资产， 可以方便地构建
数据业务。 目前比较典型的能够产生巨大价值的数据业务主要分布在数据化运营、 智能应用和
在线数据服务等领域， 它们通过大数据和人工智能技术的有效结合， 从海量数据中快速发掘价
值。

（四）数据生态化
在该阶段， 由于企业创造了统一的数据、 计算和业务平台， 因此更多的开发人员可以在该平台
上做自助的业务开发， 同时大量的业务又会产生新的数据和资产， 吸引新的开发人员构建业
务， 数据、 业务和开发人员形成正向反馈， 构成完整的数据生态。

虽然企业在业务演进的过程中不一定严格按照以上四个阶段来发展， 各个阶段可能存在一定的
重合和反复迭代， 但是随着大数据、 云和人工智能技术的快速发展， 基于这四个阶段的技术演
进无论在技术上还是业务上都将会更加成熟， 更切合企业的数据化转型加快的需求。

2.3.2 数据应用

常见的数据应用包括数据资产、数据标签、智能决策和数据开发。

数据资产是指由个人或企业拥有或者控制的，能够为企业带来未来经济利益的，以物理或电子
的方式记录的数据资源。具体来讲，数据资产是指以个人或企业的照片、文档、图纸、视频、
数字版权等文件为载体的数据，相对于实物资产以数据形式存在的一类资产。数据资产被认为
是数字时代的最重要的资产形式之一。

7
标签是一种用来描述业务实体特征的数据形式。通过标签对业务实体进行刻画，从多角度反映
业务实体的特征。比如对用户进行刻画时，包括性别、年龄、地区、兴趣爱好、产品偏好等角
度。在日常工作中，经常碰到的业务实体包括用户、商品、商户等，相应的标签分别称之为用
户标签、商品标签和商户标签。通过对不同标签的简单操作，便可进行数据筛选和分析。例如
通过性别、年龄和地区等标签筛选出不同特征的客群，再通过其他标签分析该客群，便可得到
该客群的画像。

智能决策融合大数据与人工智能技术，基于动态知识图谱和行业业务模型，具备自适应和自优
化的能力，支持复杂业务问题的自动识别、判断并进行推理，进而做出前瞻和实时决策的智能
化产品系统。

数据开发侧重于提供数据集成、数据开发、数据地图、数据质量和数据服务等全方位的能力，
一站式开发管理的用户体验，帮助企业专注于数据价值的挖掘和探索。

2.4 PaaS 服务层 - 平台服务

平台即服务（Platform as a Service，PaaS ）给用户提供了特定的编程语言、库、服务以及开
发工具来创建、开发应用程序并部署在相关的基础设施上。用户无需管理底层的基础设施，包
括网络、服务器，操作系统或者存储。他们只需要，当然也只限于管理部署平台上的应用程
序。PaaS 平台会提供服务给运行的应用程序，常见的服务有数据库、消息队列、缓存等。

总之，PaaS 提供软件部署平台，抽象掉了硬件和操作系统细节，可以无缝地扩展。开发者只需
要关注自己的应用（业务逻辑），而不需要关注底层。

特定的 PaaS 平台将会提供一组特定的服务，满足某个细分行业的需求。例如移动后台即服务

（Mobile Backend as a Service）是指专为移动和 Web 应用开发者提供的整合云后端的服务。
开发者无需过多研究服务器端程序，只需调用云计算平台提供的 API，使用相应 SDK，就能迅速
完成数据存储、账户管理、消息推送、社交网络整合等功能。MBaaS 作为应用开发的新模型，
进一步实现专业分工，有助于应用的成本下降和市场的进一步繁荣。

云平台通常通过服务目录的方式来管理云平台上的应用程序和展示服务能力。

2.4.1 数据平台服务

2006 年 Hadoop 技术的出现标志着大数据技术时代的开始，经过 10 多年的蓬勃发展，大数据

技术已经真正承托起一大批企业的数据基础架构。

如今，大数据和 AI 生态蓬勃发展，大数据技术应用日益广泛，越来越多企业在应用场景方面有
着非常强的创新意识，需要处理的数据量飞速增长，需要处理的场景也日趋复杂。因此针对不

8
同的场景，需要用不同的数据工具或者数据服务来满足不同的需求。以下是来自 Matt Turck 发
布的大数据和 AI 全景图：

参考资料： https://mattturck.com/data2019/

支撑大数据存储与分析的数据库，大数据和人工智能软件也逐步发展和成熟，除了以 SaaS 软件
的方式直接供最终用户使用之外，同时也以 API 的方式供第三方应用使用。

为了满足企业数据化转型，云平台往往需要集成数据库、大数据和人工智能软件，并以服务的
方式提供给第三方应用。

大数据

大数据的服务通常包括数据存储、数据仓库、搜索引擎、实时计算、批量计算和数据挖掘等。
为了更好满足企业多租户、扩缩容、潮汐计算、高效利用资源等需求，传统大数据软件往往都
会迁移到云平台上，首先需要将这些大数据软件做容器化改造，使之运行在 Kubernetes 平台
上。接着这些大数据软件需要做组件化和服务化封装（以 API 方式暴露管理能力）及改造，然
后在软件本身中支持一定程度的多租户和计算及数据的隔离，在提高安全性的前提下提升资源
使用率。

以星环科技自主研发的企业级大数据平台 Transwarp Data Hub（简称 TDH）为例，它主要提供

了 5 类核心能力：实时流计算引擎( Transwarp Slipstream )，分析型数据库(Transwarp

9
Inceptor 和 Transwarp ArgoDB )，操作型数据库( Transwarp KunDB 和 Transwarp
Hyperbase)，知识库(Transwarp New Search 和 Transwarp StellarDB )，数据挖掘平台
（Transwarp Sophon Discover）。

数据科学

数据科学的热门应用领域包括机器学习及深度学习建模、知识图谱、自然语言处理、视频图像
处理等，其软件可按需部署在私有服务器、云平台或混合云上。

以星环科技自主研发的一站式人工智能平台 Sophon 为例，针对数据分析市场现状，其主体采

用分布式计算模式，赋能企业进行以数据驱动为核心的开发、运营和产业升级。Sophon 覆盖数
据分析中的计算智能（取、算）、感知智能（看、读、认）、认知智能（理解、认知、思考、
推理）三个主要方向。

Sophon 的核心组件包括数据科学平台 Sophon Base 、知识图谱平台 Sophon KG 以及边缘计算

平台 Sophon Edge。三者分别进行结构化（如表格数据）、半结构化（如标注文件）和非结构
化（如图像和文本）三种不同类型的数据的接入、处理和分析，涵盖模型发布及管理的全生命
周期。

通过数据科学平台，业务人员可利用交互式界面进行开发，快速调用内置算法库，而技术专家
则继续使用熟悉的代码式编程界面，充分利用并行架构下的多框架支持，一键上线模型并进行
服务监控；借助知识图谱平台，用户可完成文本清洗、标注、图谱构建等一系列流程，在直观
的界面中进行知识查询、图计算等操作，深挖信息的价值，辅助投研或做舆情监控；边缘计算
平台则加速了多媒体和时序设备的智能化改造进程，它连通了云端和边缘端，方便用户推送模
型至远端设备，并按需获取高价值信息。

同时，针对最新的隐私计算需求，数据科学平台还支持联邦学习任务，在确保隐私的前提下获
得多方联合建模收益，为信息安全下的知识的分析、计算和分享保驾护航。

数据库

常用的数据库包括分析型数据库、交易型数据库、图数据库和 NoSQL 数据库，基于云化的模式

来提供数据库能力，为开发者提供即开即用、稳定可靠、可弹性伸缩的在线数据库服务，一般
也具有多重安全防护措施和完善的性能监控体系，并提供专业的数据库备份、恢复及优化方
案，使用户能专注于应用开发和业务发展。

2.4.2 应用平台服务

中间件是一种独立的系统软件服务程序，分布式应用软件借助这种软件在不同的技术之间共享
资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。常见的中间件包

10
括消息队列，缓存等。随着微服务的兴起，微服务用到的基础组件或者微服务中间件包括网
关，配置中心等。其中支撑应用运行的中间件和微服务基础组件则统称为应用服务。而应用服
务目录则提供了一系列相关服务。

微服务是相对于传统的单体应用而提出来的一种新概念，它与传统的 SOA 有区别也有联系。简

单来说，微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。

微服务架构平台提供了一些基础的微服务基础组件，包括服务注册与发现，配置中心，链路追
踪，分布式事务等。

服务注册与发现

服务地址硬编码的方式有不少问题，因此服务消费者需要一个强大的服务发现机制。服务消费
者使用这种机制获取服务提供者的网络信息。不仅如此，即使服务提供者的信息发生变化，服
务消费者也无需修改配置文件，服务发现组件可提供这种能力。在微服务架构中，服务发现组
件至关重要。

服务提供者、服务消费者、服务发现组件这三者之间的关系大致如下：

1. 各个微服务在启动时，将自己的网络地址等信息注册到服务发现组件中，服务发现组件会存
储这些信息；
2. 服务消费者可从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的
接口；
3. 各个微服务与服务发现组件使用一定机制（例如心跳）通信。服务发现组件如长时间无法与
某微服务实例通信，就会注销该实例；
4. 微服务网络地址发生变更（例如实例增减或者 IP 端口发生变化等）时，会重新注册到服务发
现组件。使用这种方式，服务消费者就无需人工修改提供者的网络地址了。

服务发现组件

注册 发送心跳 注册

服务消费者 调用 服务提供者

参考资料：https://www.cnblogs.com/sunsky303/p/11126400.html

11
配置中心

应用通常需要在不同的环境下运行，例如测试、预发布、生产环境等等，因此需要与之对应的
多套配置文件。解决方法就是将应用程序所有相关的配置信息，包括数据库、网络连接等等保
存在外部。在应用启动时，从外部（例如操作系统环境变量）读取这些配置信息。

以 Spring Cloud Config 为例，Spring Cloud Config 提供了一种在分布式系统中外部化配置服务

器和客户端的支持。配置服务器有一个中心位置，管理所有环境下应用的外部属性。客户端和
服务器映射到相同 Spring Eventment 和 PropertySource 抽象的概念，所以非常适合 Spring 应
用，但也可以在任何语言开发的任何应用中使用。在一个应用从开发、测试到生产的过程中，
你可以分别地管理开发、测试、生产环境的配置，并且在迁移的时候获取相应的配置来运行。
Config Server 存储后端默认使用 git 存储配置信息，因此可以很容易支持标记配置环境的版
本，同时可以用主流工具管理配置内容。

云平台则将配置中心以一种服务的方式提供给应用。

链路追踪

在微服务的架构下，大部分功能模块都是单独部署运行的，彼此通过 API 进行交互，都是无状

态的服务，这种架构下，前后台的业务流会经过很多个微服务的处理和传递，难免会遇到这样
的问题：

· 分散在各个服务器上的日志怎么处理？
· 如果业务流出现了错误和异常，如何定位是哪个点出的问题？
· 如何跟踪业务流的处理顺序和结果？
以前在单应用下的日志监控很简单，在微服务架构下却成为了一个大问题，如果无法跟踪业务
流，无法定位问题，将耗费大量的时间来查找和定位问题。因此云平台需要集成链路追踪系
统，以服务的方式提供给应用。

云平台提供中间件服务能力。云平台会提供中间件托管服务，用户可以通过页面申请相应规格
的服务，例如消息队列、缓存、分布式调度和工作流等。

2.4.3 第三方服务目录

用户开发的应用部署到云平台后，也可以将自身注册到云平台，以一种服务的形式提供给到其
他应用。例如地理位置服务，它提供了查询 API 供第三方应用查询指定地址的经纬度。

12
2.4.4 应用市场

云平台的应用市场类似于手机的应用市场，用户可以选择心仪的应用，下载并安装在手机上。
云平台的应用市场用于管理应用模版，并将应用模版部署到云平台上。应用市场的核心功能包
括应用定义、应用上下架以及应用运营报告。

应用定义以 Kubernetes 的 Helm 为例，它是 Deis (https://deis.com/) 开发的一个用于

kubernetes 的包管理器，每个包称为一个 Chart。对于应用发布者而言，可以通过 Helm 打包
应用，管理应用依赖关系，管理应用版本并发布应用到软件仓库。

对于使用者而言，使用 Helm 后不需要了解 Kubernetes 的 YAML 语法并编写应用部署文件，可

以通过 Helm 下载并在 kubernetes 上安装需要的应用。

2.4.5 应用治理

应用治理或者说服务治理一词最早出现在 SOA 里面，称之为 SOA Governance，指企业为了确

保事情顺利完成而实施的过程，包括最佳实践、架构原则、治理规程、规律以及其他决定性的
因素。服务治理指管理服务的采用和实现的过程。

服务治理中一些典型的问题是：

· 交付价值到利益相关者，这是投入与回报的问题。
· 对标准和规则的遵从（这是和审计相关的）。
· 变更管理：变更一个服务通常会引起不可预见的后果，因为服务的消费者对服务的提供者来
说是不可知的。
· 服务质量的保证：弹性添加新服务需要对这些服务给予额外的关注。

服务治理的一些关键活动包括：

· 计划开发新服务和升级现有服务。
· 管理服务的生命周期：确保升级服务不会影响目前的服务消费者。
· 制定方针来限制服务行为：制定所有服务都要遵从的规则，确保服务的一致性。
· 监控服务的性能：由于服务组合，服务停机和性能低下的后果是严重的。通过监控服务的性
能和可用性，当问题出现的时候能马上采取应对措施。
· 管理由谁来调用服务、怎样调用服务。
· 从实践总结来看，服务治理包含服务管理（管控）和服务监控两大块，同时需要企业级微服
务基础组件以及相关中间件的支撑。

13
2.4.6 DevOps

DevOps 是一种强调开发团队、运维团队以及其他团队之间增强协作与沟通，以达到软件产品快
速成熟以及安全可控的文化。通过自动化软件交付和变更的流程，让构建、测试、发布软件能
够更加地快捷、频繁和可靠。它能用最小化的代价帮助企业应用开发进入高效的协作模式和快
速的迭代进程。

云平台需要提供 DevOps 能力，比如项目管理、持续集成、流水线、持续发布等。其中依托流

水线和 Kubernetes 实现的持续集成、持续部署、持续发布是云平台为应用提供的最核心的
DevOps 能力。

CI（Continuous Integration）持续集成，强调开发人员提交新代码之后，立刻进行构建、（单
元）测试、代码扫描等操作。根据测试结果，开发人员可以确定新代码和原有代码能否正确地
集成在一起。

Continuous Deployment（持续部署） 或者 Continuous delivery（持续交付）两者简称都为

CD，但是略有不同。

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的“类生产环境”
（production-like environments）中。比如完成单元测试后，可以把代码部署到连接数据库的
Staging 环境中更多的测试。注意：这里的测试重点是指测试人员进行的产品级别的测试。在测
试过程中普遍都会引入测试脚本进行自动化回归测试，主要包括接口测试和 UI 测试，当然部分
公司也会引入安全测试和性能（压力）测试。如果测试没有发现问题，则可以将新代码手动或
者自动部署到生产环境中。

持续部署（发布）就是定时地、手动或者自动地将过去一个稳定的发布版本部署到生产环境
里。当然持续部署的目标是自动发布，但是有时候部署比较复杂，必须人工介入。

总结来说，持续集成、持续部署与持续交付，是通过在应用开发阶段引入自动化，实现频繁向
客户交付应用的方法。需要将自动化和监控贯穿于应用的整个生命周期（从集成和测试阶段，
到交付和部署）。依托于容器化的持续集成，改变了以往应用通过 jar、war 包的部署方式，转
而制作为一个镜像，通过 Kubernetes 的功能特性，对纳管的宿主机进行镜像发布、应用启动和
应用验证。

2.4.7 平台管理

在开发者能够在云平台上部署和管理应用之前，云平台首先应该对租户以及租户内可用资源进
行配置和管理。云平台如何对资源进行精细管理，对平台的可用性、可维护性和易用性起着至
关重要的作用，是云平台能够为用户提供丰富的管理能力的基础。

14
具体而言，平台的管理功能包括用户管理、用户认证与授权、租户管理、资源管理、集群管
理、混合云管理等，它是云平台的大脑，用于将资源和服务以自服务的方式提供给租户内的用
户。

2.4.8 平台运营

对租户使用的资源进行计量和计费。除了资源之外，对于有些服务，云平台可以根据调用次
数，数据总量或者每日数据增量等不同维度进行计量和计费。

云平台可以使用数据可视化的方式，用各个维度分析展示各业务部门或项目上的费用报表。

2.5 基础层
容器技术定义了一套从构建到执行的标准化体系，包括：

· 基础架构的标准化：当前所有的 Linux 系统以及 Windows 操作系统已经支持 Docker

Engine，也就意味着可以支持容器化应用。国产操作系统也基本上都可以支持 Docker
Engine。
· 应用交付的标准化：提供了一套应用快速打包为 Docker Image 的方法，开发人员在代码完
成以后就可以将其打包为镜像，这样运维人员也不再需要为应用准备系统，运行环境，组件
和基础软件包。
· 运维管理的标准化：容器时代都运行在一个个的 Docker Container 中，应用运维将关注在这
些标准的容器中而不再是关注底层复杂的系统环境。
· 分发部署标准化：指的是容器化以后，不同版本的应用镜像都存储在镜像仓库中，运维人员
可以将镜像仓库中特定版本的镜像，一键部署到开发环境、测试环境甚至是生产环境中，也
可以实现快速的版本升级或回退。

以容器技术为核心的引擎层是容器云平台的支撑部分，包括容器编排引擎、容器运行时、服务
网格、无服务器计算、镜像仓库，操作系统和基础设施。

2.5.1 容器运行时

Docker 则是应用最广泛的容器引擎技术之一。Docker 使用 Linux 内核和其相关功能（例如

Cgroups 和 namespaces）分隔进程，各进程相互独立运行，同时保持各个独立系统的隔离
性。

继 Docker 之后也出现了多种容器运行时技术，为了更好规范容器技术，Docker，CoreOS 和容
器行业中的其他领导者在 2015 年 6 月的时候启动共同发起并成立了 Open Container Initiative

15
（ OCI ）基金会。OCI 基金会领导社区进行制定了相关规范，主要包括：

· 镜像规范（常被称为“OCI images"）定义了容器镜像的内容。
· 运行时规范（常被称为“CRI”或者容器运行时接口）表述了容器的”配置，运行环境和生
周期“。

在 OCI 项目启动后，Docker 公司将 libcontainer 的实现移动到 runC 并捐赠给了 OCI。此时，容

器社区有了第一个 OCI Runtime 的参考实现。runC 是一个轻量可移植的容器运行时，包括了所
有之前 Docker 所使用的容器相关的与系统特性的代码。随后在 2016 年，Docker 开源并将
Containerd 捐赠给了 CNCF，Containerd 几乎囊括了单机运行一个容器运行时所需要的一切：
执行、分发、监控、网络、构建、日志等。

最初，Kubernetes 仅支持 Docker 作为运行时，为了能够让 Kubernetes 变得更具有可扩展性，

在 1.5 版本增加了 CRI: the Container Runtime Interface，在随后的发展演进中，CRI 被抽出来
做成了独立的项目。CRI 将 Kubernetes 与容器运行时解耦，将原来完全面向 Pod 级别的内部接
口拆分成面向 Sandbox 和 Container 的 gRPC 接口，并将镜像管理和容器管理分离到不同的服
务。

目前支持 OCI 和 CRI 的常用容器引擎有 Docker，Containerd，CRI-O 和 Kata Container。

2.5.2 容器编排引擎

主流的容器编排和管理系统有 Kubernetes、Mesos 和 Swarm。进入 2017 年之后，随着

Kubernetes 逐渐建立起庞大的生态体系，容器编排之争落下帷幕，Kubernetes 成为了事实上的
容器编排标准。

Kubernetes 源自于 Google 内部的 Borg 系统，最初由 Google 和 Red Hat 开源。云原生基金会
（Cloud Native Computing Foundation，CNCF）成立之后，Kubernetes 被捐献给了基金会，
同时 CNCF 围绕 Kubernetes 构建生态，促使越来越多的第三方加入到 CNCF 中，丰富了
Kubernetes 大家庭。

容器本质是进程，那 Kubernetes 作为具有普遍意义的容器编排工具，就是云操作系统。

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进
声明式配置和自动化。

Kubernetes 的核心能力包括：

· 服务发现和负载均衡
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，
Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

16
· 存储编排
Kubernetes 允许自动挂载您选择的存储系统，例如本地存储、公共云提供商等。
· 自动部署和回滚
可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为
所需状态。例如，可以自动化创建新容器，删除现有容器并将它们的所有资源用于新容器。
· 自动二进制打包
Kubernetes 允许指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，
Kubernetes 可以做出更好的决策来管理容器的资源。
· 自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，
并且在准备好服务之前不将其通告给客户端。
· 密钥与配置管理
Kubernetes 允许存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。可在不重建容器
镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

2.5.3 容器网络

容器网络是容器运行时的一个关键考量技术，包括容器网络安全、如何更好地连接不同集群，
如何连接异构容器云平台等一系列问题。

容器网络的基本目标是满足云原生服务的网络端点和服务间的互通性、安全性和负载均衡要
求。Kubernetes 已经成为容器编排的事实标准，容器网络也需与 Kubernetes 的调度机制相匹
配。

Container Network Interface（CNI）是 Kubernetes 现行的网络接口标准，CNI 接口只实现创

建、删除容器时的调用方法，其他所有的网络能力都交由网络厂商实现增值服务，这在一定程
度上加速了网络方案的繁荣。

容器网络技术也在持续演进，从 Docker 本身的动态端口映射网络模型，到 CNCF 的 CNI 容器网

络接口到 Service Mesh + CNI 层次化 SDN。

容器网络的发展与演进如下图：

17
 参考资料：https://mp.weixin.qq.com/s/Q6D2jtHNPUNCuvTdCXtziA

1、端口映射从全局管理容器，复杂度高，企业生产部署中很少使用。分为 Bridge 模式、Host

模式、Container 模式和 None 模式。

2、容器网络接 CNI（Container Network Interface）是 Google 和 CoreOS 主导制定的容器网络

标准，它是在 RKT 网络提议的基础上发展起来的，综合考虑了灵活性、扩展性、IP 分配、多网
卡等因素。CNI 旨在为容器平台提供网络的标准化。不同的容器平台（比如目前的
Kubernetes、Mesos 和 RKT）能够通过相同的接口调用不同的网络组件。这个协议连接了两个
组件：容器管理系统和网络插件，具体的事情都是插件来实现的，包括：创建容器网络空间
（network namespace）、把网络接口（interface）放到对应的网络空间、给网络接口分配 IP
等。

3、服务网格（Service Mesh）是指用于微服务应用的可配置基础架构层。它使每个 service 实

例之间的通信更加流畅、可靠和迅速。服务网格提供了诸如服务发现、负载均衡、加密、身份
鉴定、授权、支持熔断器模式（Circuit Breaker Pattern）以及其他一系列功能。但是 Service
Mesh 并不会替代 CNI，他们工作在不同的 SDN（Software Defined Network，软件定义网络）
层次，CNI 更多工作在 L2-4 层，Mesh 在 5-7 层 Application SDN。Mesh 不能独立于 CNI 部
署，而是将服务网格和 CNI 结合提供层次化微服务应用所需要的网络服务。

从最初的端口映射，到容器网络接口（CNI），再到服务网络和 CNI 相结合，容器网络技术不断

发展，企业可以根据不同的应用场景，选择不同的容器网络方案。

容器存储是云原生应用场景下的存储解决方案，存储形态可为块、对象、文件、键值存储等。
容器存储可以以“声明”的形式被云原生应用申请使用，支持容器编排层对接存储控制面，完
成对存储资源的生命周期管理。

18
在容器内部存储时不提供持久化数据存储解决方案，存储在容器内部的任何内容，在容器被销
毁以后，数据将自动消失，这就需要考虑采用外部存储挂载到容器上，在容器迁移、消亡、重
启等活动中保证数据的安全。

随着数据库、消息队列等中间件逐步在容器环境中得到应用，容器持久化存储的需求也逐步增
多。同时，容器云平台存储不仅仅是数据的持久化存储，也包括容器云平台自身需要的存储、
镜像存储、中间件部署需要的存储。存储资源作为容器云平台的另一个核心基础设施，需要为
不同的容器服务提供可靠的存储服务。

容器存储接口（Container Storage Interface，CSI ）是一项跨行业标准倡议，旨在降低云原生

存储开发工作的门槛，从而进一步确保兼容性水平。Kubernetes v1.9 开始引入了 CSI，它允许
第三方存储供应商在无需接触核心 Kubernetes 代码库的前提下开发自己的解决方案。

Kubernetes 目前支持了广泛的存储插件，典型的可分为三部分。

· 首先是文件存储，例如 CephFS、GlusterFS、NFS 等。CephFS, GlusterFS 尽管有庞大的社区

的支持，但成熟度上还需要进一步验证。同时在大型集群的环境下它们还无法达到企业级稳
定性、可靠性的要求，在高可靠、高性能场景也有着架构上的不足。而 NFS 在性能上存在不
足。
· 其次是块存储，例如 Ceph RBD、SAN 存储等。对于这类存储，本身并不支持多读写的需
求，而对复杂的容器业务系统又是强需求。
· 最后是对象存储，例如 COS、S3 等。对象存储不需要挂载可直接使用，其他两种存储方式需
要挂载后使用。

参考资料：https://zhuanlan.zhihu.com/p/98827611

19
2.5.5 镜像仓库

通过把业务及其依赖的环境打包进容器镜像，解决了开发环境和生产环境的差异问题，提升了
业务交付的效率。如何高效地管理和分发容器镜像，是企业级镜像仓库需要解决的问题。

目前 Kubernetes 生态中主流的镜像仓库组件是 Harbor。Harbor 是 VMware 开源的一个企业级

镜像仓库，包括了权限管理(RBAC)、LDAP、审计、安全漏洞扫描、镜像验真、管理界面、自我
注册、HA 镜像复制和中文支持等功能。

2.5.6 Service Mesh

服务网格（Service Mesh）是一个致力于解决服务间通信的基础设施层，用于提供管理、观
测、支持工作负载实例之间安全通信。服务网格通常以轻量级网络代理的形式实现，这些代理
与应用程序代码部署在一起，但是对应用程序透明。服务网格通常由控制平面和数据平面两部
分组成。数据平面运行在边车（Sidecar） 中，Sidecar 作为一个独立的容器和业务系统运行在
同一个 Pod 里面，或者作为一个独立的进程和应用程序进程运行在同一个虚拟机上，其主要充
当业务系统的网络流量的代理。传统 RPC 中的服务发现、限流、熔断、链路追踪等能力都会下
沉到 Sidecar 中。Sidecar 为应用程序提供了一个透明的网络基础设施，让业务在低侵入或者零
侵入的情况获得更健壮的网络通信能力。

具体来看，基础设施层是 Service Mesh 的定位，用于解决微服务基础设施标准化、配置化、服

务化和产品化问题；服务间通信是 Service Mesh 技术面对的问题域，对微服务屏蔽通信的复杂
度；请求的可靠传递是 Service Mesh 的目标；轻量级网络代理是 Service Mesh 的部署方式；对
应用程序透明，对业务无侵入是 Service Mesh 的特色。

目前 Kubernetes 生态中主流的 Service Mesh 组件是 Istio。Istio 是 Google、IBM 和 Lyft 联合推

出的开源微服务 Service Mesh 框架，以 Envoy 为基础，将 Envoy 作为默认的数据平面，提供强
大的控制平面能力。

Envoy 内部可以分为数据平面、控制平面和管理平面 3 个部分，控制平面用于对流量路由和转

发相关的策略与配置进行管理；控制平面通过标准 API 获取最新的流量配置信息；数据平面的
流量转发就是基于控制平面下发的配置规则进行。

2.5.7 Serverless

基础设施架构总是伴随软件架构演进。单体架构时代应用比较简单，应用的整体部署、业务的
迭代更新，物理服务器的资源利用效率足以支撑业务的部署。随着业务的复杂程度飙升，功能
模块复杂且庞大，单体架构严重阻塞了开发部署的效率，业务功能解耦，单独模块可并行开发
部署的微服务架构逐渐流行开来，业务的精细化管理不可避免地推动着基础资源利用率的提

20
升。虚拟化技术打通了物理资源的隔阂，减轻了用户管理基础架构的负担。容器/PaaS 平台则
进一步抽象，提供了应用的依赖服务、运行环境和底层所需的计算资源。这使得应用的开发、
部署和运维的整体效率再度提升。

Serverless（无服务器）是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种
服务，以 API 接口的方式供给用户按需调用。无服务器架构技术则将计算抽象得更加彻底，将
应用架构堆栈中的各类资源的管理全部委托给平台，免去基础设施的运维，使用户能够聚焦高
价值的业务领域。

Serverless 架构由两部分构成，分别是 FaaS （Funcation as s Service） 和 BaaS（Backend as

a Service）。所谓的无服务器计算，并不是不需要服务器等资源的支持，而是开发者不再需要
过多顾虑关于服务器底层资源的问题，可更专注于业务逻辑的开发。

目前 Kubernetes 生态中主流的 Serverless 组件是 Knative。knative 是谷歌开源的 Serverless

架构方案，旨在提供一套简单易用的 Serverless 方案，把 Serverless 标准化。目前参与的公司
主要是 Google、Pivotal、IBM、Red Hat，2018 年 7 月 24 日才刚刚对外发布，当前还处于快
速发展的阶段。

Knative 是建立在 Kubernetes 和 Istio 平台之上的，使用 kubernetes 提供的容器管理能力

（deployment、replicaset、和 pods 等），以及Istio提供的网络管理功能（ingress、LB、
dynamic route 等）。

Knative 把整个系统分成了三个部分：

· Build：构建系统，把用户定义的函数和应用 build 成容器镜像

· Serving：服务系统，用来配置应用的路由、升级策略、自动扩缩容等功能
· Eventing：事件系统，用来自动完成事件的绑定和触发

2.5.8 操作系统和基础设施

借开源 Linux 东风，国产操作系统从项目科研体制转向公司化运作，近些年涌现出来一大批逐

步成熟的国产操作系统，包括红旗 Red Flag、深度 Deepin、中标麒麟 Neokylin、银河麒麟
Kylin、统信 UOS 等。这些操作系统目前也逐步支持 Docker 和 Kubernetes 生态。

容器云平台是新的云原生基础设施，它依赖于底层的基础设施，可以部署在裸金属（物理
机）、虚拟化（单机虚拟化）、私有云（使用 IaaS 系统，例如 OpenStack，提供的虚拟化资
源）、公有云（使用公有云提供虚拟化资源）上。

21
2.6 运维
容器云平台的运维对象涵盖了应用层、平台层和引擎层，提供的能力主要包括巡检、排错、容
量预估、日志、监控、告警、自动化等。

2.6.1 日志

在容器化时代，容器应用的日志管理和传统应用存在很大的区别，为了顺应容器化应用，以
Docker 和 Kubernetes 为例，均能提供较为完善的日志解决方案。

在 Docker 中日志分为两大类：Docker 引擎日志和容器日志。其中，Docker 引擎日志就是

Docker 运行时的日志，即 dockerd 守护进程的日志，在支持 Systemd 的系统中可以通过
journal -u docker 查看日志。Docker 管理所有容器传到 stdout 和 stderr 的日志，通过 docker
logs 命令查看容器日志都是读取容器传到 stdout 和 stderr 的日志。

在 Kubernetes 中日志也主要有两大类：应用 Pod 日志和 Kuberntes 集群组件日志。其中，

应用 Pod 的日志管理是基于 Docker 引擎的，Kubernetes 并不管理日志的轮转策略，日志的存
储都是基于Docker的日志管理策略。Kuberntes集群组件日志分为两类：运行在容器中的
Kubernetes scheduler 和 kube-proxy；未运行在容器中的 kubelet 和容器 runtime。

Kubernetes 本身并未提供集群日志收集方案，K8s 官方文档给了三种日志收集的建议方案：

· 使用运行在每个节点上的节点级的日志代理；
· 在应用程序的 pod 中包含专门记录日志 sidecar 容器；
· 应用程序直接将日志传输到日志平台。

目前在 Kubernetes 集群内部收集日志有以下几种方案

1.常见的ELK（Elasticsearch、Logstash、Kibana）+ Filebeat。引入了各类 Lib
Beats（Package Beat、Top Beat、File Beat 等）运行在 App 应用的 Pod 中收集日志，转发给
Logstash。此方案将手机端的 Logstash 替换为 beats，更灵活，消耗资源更少，扩展性更强。
同时可配置 Logstash 和 Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。

2.Kubernetes官方推荐的 EFK（ELasticsearch、Fluentd、Kibana）方案，此方案通过
DaemonSet 的方式在集群内部每个节点上运行一个 Fluent Pod 统一收集上层应用层的日志并
反馈到 Elasticsearch。

2.6.2 监控与告警方案

Docker 是目前使用最广泛的容器之一，但它并不总是像物理硬件一样可见，因此对容器、运行
系统和应用的状态的监控就显得很重要。主要对应用层，平台层和引擎层各组件/系统进行性能

22
 监控，包括的应用监控，平台监控，Kubernetes 监控，网络监控，主机监控和存储监控等。

应用层和平台层的组件，本质上都是以 Pod 的形式运行在 Kubernetes 之上，因此虽然逻辑上

它们是独立的，但其背后使用的监控方案是一致的。

而对于 Pod，Kubernetes 组件，Kubernetes 网络和存储以及主机，目前 Kubernetes 生态可以

使用 Prometheus，Grafana 及相关组件完成整个的监控与告警。

Prometheus 是一款面向云原生应用程序的开源监控工具，它是第一个从 CNCF 毕业的监控工

具。常见的 Prometheus 监控方案的架构图如下所示：

Service discovery Prometheus

Short-lived jobs alerting pagerduty
kubernetes file_sd

push metrics Alertmanager Email

at exit
discover
targets notify
etc
Pushgateway
Prometheus server
push
alerts

pull HTTP
Retrieval TSDB server
metrics

PromQL

Prometheus
Web UI

Grafana
Data
Jobs/exporters
visualization
and export
Prometheus
targets API clients

参考资料：https://prometheus.io/assets/architecture.png

Prometheus 组件如下所示：

· Prometheus Server：负责监控数据采集和时序数据存储，并提供数据查询功能。
· 客户端 SDK：对接 Prometheus 的开发工具包。
· Push Gateway：推送数据的网关组件。
· 第三方 Exporter：各种外部指标收集系统，其数据可以被 Prometheus 所采集。
· AlertManager：告警管理器。
其他辅助支持工具。

Prometheus 的核心组件 Prometheus Server 的主要功能包括：

· 从 Kubernetes Master 获取需要监控的资源或服务信息；

· 从各种 Exporter 抓取（Pull）指标数据，然后将指标数据保存在时序数据库（TSDB）中；

23
· 向其他系统提供 HTTP API 进行查询；
· 提供基于 PromQL 语言的数据查询；
· 可以将告警数据推送（Push）给 AlertManager 等等。

Grafana 是一个开箱即用的可视化工具，具有功能齐全的度量仪表盘和图形编辑器，有灵活丰
富的图形化选项，可以混合多种风格，支持多个数据源特点。它可以配合 Prometheus 将监控
数据可视化。下图是 Kubernetes 集群监控的一个典型 Dashbaord。

参考资料： https://www.infoq.cn/article/NXQ2ClQCthhm6XwXkuzx

云平台巡检是通过巡检软硬件的运行情况，确保云平台运行稳定。巡检通常可以通过调用容器
云平台的各组件的 API，以及监控/日志系统的数据进行整合和汇总。

巡检的内容通常包括：
1）Kubernetes 节点的运行状态，包括内存，网络，磁盘等；
2）Kubernetes 关键组件的运行状态，包括 API Server，ETCD，DNS 等；
3）Pod 的运行状态，CPU/内存等使用情况，重启次数等；
4）业务的运行状态，包括 API 响应时间/错误率/吞吐量等。

灾备（又称灾难恢复，disaster recovery）指的是，发生灾难时恢复业务的能力。灾备通常包含
容灾和备份，容灾一般会在相隔距离比较远的两个机房搭建两套相同功能的 IT 系统，实现两地
之间数据的同步和功能的切换，当一处机房因为操作不当或是气候等原因造成服务器停止工作
时，整个应用系统可以切换到另一台服务器，使得该系统可以正常工作，以保证数据的完成性
以及系统的正常运转，避免业务上的损失。同样数据的备份，也可增强数据的安全，将重要的

24
数据以天/周为单位进行备份，实现数据的备份和保存。

灾备的目的就是，保存系统的核心部分。一个有效的 Kubernetes 容灾解决方案才能确保

Kubernetes 上运行的含有大量数据的应用程序在容灾恢复的时候，满足服务水平协议（SLA）
或相关法律要求，因此需要具备：

1）容器粒度的控制
2）能够备份数据和配置
3）Kubernetes 命名空间感知
4）针对多云和混合云架构的优化
5）保持应用的一致性

容器云 PaaS 平台根据所承载业务的重要性、故障处理的时间限制、对用户的影响范围等因素划

分所承载业务的容灾等级，可以针对不同的容灾等级采用不同的容灾策略。在某个数据中心的
应用主机高负载运行产生告警，或在业务高峰期一个数据中心的容量不足时，容器云 PaaS 平台
会自动进行应用容量的自动扩展，根据扩展策略（如 CPU/内存使用率、交易延时、业务量阈值
等指标），自动启动容灾数据中心的容器服务来支撑业务。当某个数据中心发生故障时，容器
云 PaaS 平台会采用流程驱动的方式，实现快速容灾切换。

2.7 安全

云上安全问题本质上都是由线下传统安全问题衍生而来的，但由于容器云平台底层使用了容器
技术，它又引入了新的安全风险。

除了传统的应用依赖包安全，应用安全，主机安全，网络安全之外，重点需要考虑一下与容器
相关的镜像安全和容器安全。

镜像是创建容器的基础，容器是镜像的运行时，镜像安全直接影响着容器的安全。

对于从公有仓库获取的镜像，其安全问题一方面镜像中开源软件存在的安全风险，另一方面是
镜像内的挖矿程序、后门程序、病毒、木马等恶意程序。这种情况，一般可运行镜像，在里面
安装杀毒软件深度扫描，来确定镜像的安全性，并且确认请求指向官方源。

对于私有仓库中的镜像，通常是用户自己制作上传生成的，需要考虑到软件代码本身的脆弱性
与配置的风险。对于代码本身的问题，需要在开发过程中尽可能遵循 SDL（安全开发生命周
期），在镜像的制作过程中，则要尽可能地只运行必要的服务，只暴露必要的端口。

25
因此常用的安全建议如下：

· 使用可信基础镜像
· 精简镜像，减少受攻击可能性
· 及时更新漏洞库并周期性执行镜像扫描
· 使用镜像前，提前进行镜像扫描
· 使用带有认证功能的镜像仓库，保证客户端身份有效性

容器提供了将应用程序的代码、配置、依赖项打包到单个对象的标准方法，其本质是隔离一个
运行环境，每个封装好的容器彼此相互隔离。但各个容器之间需要互相共享内核，分别通过
Linux 内核本身提供的 Namespace 与 Cgroups 两项关键技术实现。

容器一共有 7 个攻击面：Linux Kernel、Namespace/Cgroups/Aufs、Seccomp-bpf、Libs、

Language VM、User Code、Container(Docker) engine。

因此需要针对这七个攻击面制定相应的安全措施。例如 Docker 等容器引擎需要访问系统资源，

有 root 权限才方便为了整个系统的安全，对于整个系统而言，必须严格控制访问权限，不能随
意 root 权限，需要明确划分出一块区域与其他容器和资源隔离，同时配以容器和资源实时监
控，确保容器运行安全。

与用户权限相关的安全建议：

· 禁止容器使用 root 用户
· 控制特权模式使用
· 控制系统调用使用
· 限制系统资源使用

26
3 容器云平台产品与应用
3.1 容器云平台发展现状
容器技术之所以流行，是因为它便于开发者调试、开发、部署、运维、迁移、扩容，而伴随着
企业数字化转型的加快，企业需要具有资源统一管理能力、系统弹性伸缩能力、运维成本低的
平台并结合 DevOps 和智能运维，实现开发、测试到系统运维、软件交付的全生命周期一体化
管理平台，因此容器云平台得到蓬勃发展。

根据 IDC 2019 年末发布的《软件定义计算软件市场半年跟踪报告》（2019 年上半年）显示，

预计中国容器基础架构软件市场 2019 年的整体规模为 7340 万美元，其所带来的容器相关市场
（搭建容器/ PaaS 平台使用的软件和服务）的收入将会达到 4-5 亿美元，未来五年容器基础架
构软件市场将以 56.1%的复合增长率呈爆发式增长。

数据云的代表之一 Snowflake，2020 年 9 月16日上市首日便冲破发行价，估值超 700 亿美元，

如今已经成为美国硅谷乃至全球最红的数据独角兽。数据云在现有容器云市场的基础上，打开
了更大的市场空间：

· 数据仓库市场：根据 IDC 数据，预计 2024 年全球数据仓库市场规模将达到 297 亿美元，

2019 - 2024 年复合增速为 12%；其中云数据仓库市场规模将达到 181 亿美元，2019 - 2024
年复合增速为 25.3%。

· OLTP 数据库市场：据 IDC 预计，2024 年全球 OLTP 市场规模将达到 482 亿美元，2019 -

2024 年复合增速为 8.2%；其中云产品市场规模将达到 253 亿美元，2019 - 2024 年复合增速
为 25.5%。

· 数据集成软件市场：据 IDC 预计，2024 年全球数据集成市场规模将达到 79 亿美元，2019 -

2024 年复合增速为 2.4%；其中云端解决方案的市场规模将达到 25 亿美元，2019 - 2024 年
复合增速为 18.9%。
· BI 和分析工具市场：据 IDC 统计，2019 年全球 BI 和分析工具市场规模 270 亿美元，预计
2024 年将达到 400 亿美元，2019 - 2024 年复合增速为 8%。
参考资料：Worldwide Big Data and Analytics Spending Guide，
https://www.idc.com/getdoc.jsp?containerId=IDC_P33195

云计算容器技术使用阶段
2017年 30.1% 36.3% 24.5% 9.1%

2016年 23.3% 31.5% 35.2% 10%

已经投入生产环境 正在测试环境 正在评估 尚未使用容器技术

参考资料：云原生技术实践白皮书 （2019 年）（征求意见稿 ）

27
根据中国信息通信研究院发布的《云原生技术实践白皮书 （2019 年）》（征求意见稿）显示，
2016 年 23.3%的被访企业已经开始将云计算容器技术投入生产环境，2017 年 30.1%的被访企
业已经开始将云计算容器技术投入生产环境。近日，中国信息通信研究院发布的云计算发展调
查报告（2020年）显示，2019年43.9%的被访企业表示已经使用容器技术部署业务应用，
28.9%的企业已经使用微服务架构进行应用系统开发，另外有 46.8%的企业计划使用微服务架
构。

随着众多巨头云服务商以强大的综合云服务能力推动着云原生技术的发展变革，细分生态领域
的企业级产品服务也不断涌现，提供更加聚焦的精细化服务。

3.2 垂直行业应用

目前容器技术在互联网领域已经被广泛应用，而随着传统行业数字转型的加快，更是打开了容
器技术以及容器云平台的发展空间。

据 2019 年 IDC 中国针对非互联网企业进行的《中国容器市场现状和发展趋势调研》显示，在金

融、制造、政府、电力、能源、教育、医疗等行业中，容器技术发展势头迅猛，并已经有部分
企业开始拥抱容器技术，主动摆脱传统的思维模式。

金融：银行

在金融领域银行是容器云平台典型的应用场景。由于互联网技术的飞速发展，新兴的金融类服
务模式对银行业务带来了冲击。银行需要对业务模式进行创新，同时催生了对于传统 IT 流程、
基础架构和运维模式的升级，容器技术的成熟为传统金融企业的转型提供了新思路。

主要应用场景：

· 业务场景
银行正在从传统柜台办理业务向新应用转型。容器云平台一方面可以标准化应用的部署和交
付，加快应用的部署能力，提升持续交付的能力。另一方面更好地与 CI/CD 技术进行融合，
可快速响应市场需求。

· 内部场景
银行系统分支机构众多、组织架构繁杂，内部管理成为难点。容器云平台帮助银行内部将高
重复、低附加价值的流程全部自动化和数字化，不仅提高了内部工作效率，还建立了明确的
权限管控体系。

· 安全与合规
依托开放的容器云平台提供的服务能力，更高效地管理 IT 基础设施，满足系统的合规性要
求。

28
如今在新一轮科技革命和产业变革的大背景下，工业 4.0 备受追捧，制造业的数字化转型进程
正在加快。越来越多的工具通过容器封装、分发和运行，容器技术搭建的工业互联网 PaaS 平台
成为传统制造需要拥抱和应用互联网技术的新方向 。落地应用形式包括工业互联网、车联网
等。

主要应用场景：

· 软件系统更迭
工业 4.0 使得制造业对于 IT 环境的资源规模、运维管理水平和应用交付速度都有着迫切需
求。容器云平台提供的 DevOps 能力，可加快系统迭代速度，更好地调整应用程序以适应
不断变化的业务需求。云原生技术的实践，还可实现系统平台的应用轻量化。

· 混合云架构
众多制造业开始选择混合云架构，这给软件更新带来了前所未有的挑战。容器云平台可实现
公有云上部署开发和测试环境，在物理机和虚拟机这样的私有化平台上部署生产环境，实现
快速的跨云部署。

· 数据监控分析
制造企业对于产品质量把控有较高要求，需要通过数据分析和管理，作出业务决定。容器云
平台结合 IoT 和大数据技术，保证数据收集的准确性，并运用可视化技术实现数据的快速分
析。

能源

如今在新一轮科技革命和产业变革的大背景下，工业 4.0 备受追捧，制造业的数字化转型进程

正在加快。越来越多的工具通过容器封装、分发和运行，容器技术搭建的工业互联网 PaaS 平台
成为传统制造需要拥抱和应用互联网技术的新方向 。落地应用形式包括工业互联网、车联网
等。

主要应用场景：

· 简化运维
能源安全是国民经济命脉，传统的手动运维配置容易出错，无法保证系统高效上线的要求。
容器云平台简化运维，支持基础资源和应用的统一管理，并支持系统可视化全局监控。

· 弹性调配
传统基础平台提供的应用运行能力是静态的，无法及时提供或回收资源，造成了不必要的资
源浪费。容器云平台解决了资源调配问题，可自动弹性伸缩。应用运行时，系统将根据运行
情况实时进行弹性扩展、释放资源，有效提高资源的使用效率。
· 快速部署
实现开发、测试、发布应用一体化，将传统的开发运维模式转变为敏捷开发模式。节约运维
的成本、提高运维的效率、保障运维的安全。

29
3.3 国内外主流的容器云平台产品介绍

容器技术的火爆，促使世界范围内众多厂商开始推出相关的容器云平台产品，开始出现越来越
多的最佳实践，容器云的商业化市场初见规模。目前，就中国市场而言互联网公司、传统 IaaS
提供商、IT/PaaS 提供商、通信企业 / 设备商以及专业 CaaS 服务提供商等都面向公众提供容器
技术相关的服务。

公有云一般提供标准化的、基于原生 Kubernetes 提供以容器为核心的、可扩展的高性能容器管

理服务。同时在容器服务的基础上，基于云原生技术，提供 DevOps 、服务治理等服务。

私有云一般在 CaaS 的基础上，构建平台层和应用层能力，同时针对不同行业场景，构建差异

化能力。

3.3.1 公有云容器服务

1.Amazon Web Services（AWS）

AWS 提供了 ECS、AWS Fargate、EKS 等容器服务产品，为客户提供容器虚机、无服务器容器

和 Kubernetes 集群三类应用托管环境。

参考资料：Amazon Web Services（AWS）官网

2.Microsoft ——Azure

Azure 除了 AKS 等容器产品之外，还提供了向普通容器开发者的容器实例服务，例如为

Windows 开发者提供 Windows 容器，为 Web 开发者提供容器化 Web Server 服务。Windows
容器的支持可以认为是 Azure 的一大特点。

参考资料：Microsoft Azure官网

30
3.Google Cloud

如今在新一轮科技革命和产业变革的大背景下，工业 4.0 备受追捧，制造业的数字化转型进程

正在加快。越来越多的工具通过容器封装、分发和运行，容器技术搭建的工业互联网 PaaS 平台
成为传统制造需要拥抱和应用互联网技术的新方向 。落地应用形式包括工业互联网、车联网
等。

主要应用场景：

参考资料：Google Cloud 官网

4.阿里云

阿里云2016年5月正式推出容器服务，其容器产品家族涵盖公共云、边缘计算和专有云等场景。

参考资料：Cloud Native + OpenSource Virtual Summit China 2020 - 《云原生- 数字经济技术创新基石》

31
 Gitlab Jenkins 云效 Dubbo SpringCloud Istio .net Java 企业 AI 区块链 IoT

日志、监控
服务集成
多集群管理 安全合规 混合云/多云 弹性 智能运维

专有/托管 Kubernetes Serverless Kubernetes 镜像服务

计算 网络 储存 HELM
ECS，EBM，FPU，FPGA VPC，ENI，SLB，DNS EBS，NAS，CPFS，OSS

公共云 边缘云 专有云

参考资料：Google Cloud官网

总结：
AWS、Azure、Google、阿里云、腾讯云等公有云巨头，基于自身丰富的云资源和云应用产品
可提供类别丰富且完善的容器服务。

3.3.2 私有云容器平台

1.青云 QingCloud

KubeSphere 是一款基于 Kubernetes 构建的开源企业级容器平台，QKE 在 QingCloud 公有云

上交付 KubeSphere 容器平台全能力。

32
 参考资料：青云QingCloud官网

2.灵雀云

Alauda Container Platform（简称“ACP”） 是灵雀云推出的容器云平台。

参考资料：灵雀云Alauda官网

随着微服务和容器的流行，改变了应用架构和部署的方式，大型单体应用被分解为多个单个功
能单元，并通过容器承载并以服务的方式交付给用户。虽然容器化架构使得企业的应用开发敏
捷性 、交付能力有所提升，但随着应用逐渐扩大，导致框架过于复杂，同样会给应用开发者造
成困扰。服务网格（Service Mesh）的出现，提供一种简单的方式来连接起这些微服务。容器
到 Kubernetes 再到 Service Mesh 是一条比较完整和稳妥的路线，用户可以逐步掌握新的技
术，不断扩大使用场景。

33
3.3.3 云原生存储：焱融云、衫岩数据

1.焱融云

YRCloudFile 是一款有元数据服务的分布式文件存储产品，支持元数据服务和数据服务的线性水
平扩展。元数据服务节点数可以支持多达 256 个，数据服务节点可以支持多达 1024 个，客户
端节点可以支持上万个。能够支持海量文件存储，文件数据可以支持千亿级别，容量可扩展到
EB 级别。支持 RDMA 协议，能够提供亚毫秒级别的延迟。支持文件切片和数据冗余，能够提供
良好的带宽。支持冷热数据分层，在保证高性能的同时，能够节约成本。支持容器存储，能够
完美兼容 CSI/FlexVolume 接口。

· 标准 CSI 插件无缝对接 Kubernetes

用户只需在 Kubernetes 集群 Master 节点及计算节点上，以容器形式运行 YRCloudFile 提供
的 CSI 插件，即可对 YRCloudFile 的存储能力进行调度和访问。YRCloudFile 为 Pod 提供
RWO、ROX、RWX 等多种读写模式，满足各种应用的访问控制需要。

· 企业级功能支持
作为企业级容器存储解决方案，YRCloudFile 为容器应用提供丰富的功能。可提供 PV
Quota、QoS、PVC 扩容、PV 热点分析等特有功能。

· 两数据中心双活
YRCloudFile 集群可跨数据中心，不同的副本落在不同数据中心，各副本间保持数据一致，任
意数据中心发生故障后，其它数据副本仍然可提供数据读写访问。
运行在某一数据中心上的容器业务，优先访问本数据中心的副本
有效降低跨数据中心部署场景下的访问延时

· 多个 Kubernetes 容器平台互认证
YRCloudFile 已完成和 Rancher、OpenShift、灵雀云、谐云、DaoCloud、才云、博云等多个
容器平台的兼容性互认证，能无缝对接各大容器平台。

2.衫岩数据

容器云存储解决方案充分发挥了杉岩统一存储平台的云适配、开放等优势，支持各种复杂的应
用负载，可灵活支撑符合 Kubernetes Software Conformance Certification 认证的所有容器云
平台。可通过 CSI 接口支持适用于容器的可动态创建的持久化存储，另外支持不同类型应用的
存储访问需求，包括容器镜像仓库如 Harbor 等，池化的存储平台为大规模云环境提供了可靠的
存储基础架构支撑，帮助用户从各种纷繁复杂的基础架构运维工作中解放出来，聚焦运行于业
务本身的快速开发测试及发布。

34
 互联网应用 传统应用 大数据应用
业务层
理财 促销 移动应用 客户中心 服务中心 产品中心 分析 风控 营销

MySQL MongoDB PostgeSQL

PaaS层 Harbor
Redis Elastic Jenkins

容器编排层 Kubernetes OpenShift Rancher

ISCSI CSI Driver RBD CSI Driver NFS CSI Driver

SandStone分布式统一存储

参考资料：杉岩数据官网

· 弹性伸缩，资源供给回收更及时
存储资源随应用需求自动扩展或收缩
集群按需自助式扩容或缩容
数据迁移或重构效率高

· 云原生，无缝对接云平台
支持容器平台 CSI 接口认证，兼容各种容器编排系统
标准块、文件、对象接口，满足各种云应用的存储需求

· 敏捷交付，简化运维
向导式部署，提升用户体验
统一视图管理，管理自动化

· 企业级存储功能，完善的数据保护机制
多副本/纠删码、快照保护等保证数据长期可靠保存
智能缓存、多资源池隔离等满足不同业务的分层存储需求
性能优先级调整，存储卷 QoS，卷迁移等，业务先上线再优化配置

云原生的存储系统作为应用的基础拥有以下六要素：

· 容量 Size

· 性能 IOPS, 吞吐，时延
· 可访问性，共享／独享

· IO 可观测性
· QoS

· 多租户隔离

35
通过分析可以发现，首先云原生存储均注重于无缝对接云平台，在 Kubernetes 集群中为了便于
系统的扩展，可支持对接 CSI（容器存储接口），突出存储服务容器编排系统及容器平台的兼容
性。同时，通过统一的接口，达到应用无感知地访问多种存储类型，实现平滑迁移与减低成本
的目的。

其次是多样的企业级功能，满足用户 CSI 动态感知、应用级的 QoS、多资源池隔离，PV Hot

Spot、PV insight 等方面的需求。最后，各平台对于数据安全/备份都有不同等级的支持，保证
数据的长期的安全可靠。

目前来看，云原生存储方案在 IO 性能、吞吐、时延等方面仍然有待提高，较难应对高性能服务
场景。

3.3.4 数据云平台：星环科技

星环科技结合公司大数据平台 TDH、云操作系统 TCOS、人工智能平台 Sophon 分别在大数据、

容器云平台和人工智能领域技术上的经验优势，推出新一代智能大数据云平台产品 Transwarp
Data Cloud（以下简称 TDC）， 该平台利用了大数据 + 云 + 人工智能的融合， 实现数据 + 应用
的生态系统。

参考资料：星环科技官网

36
TDC 打通了分析 PaaS、 数据 PaaS、 应用 PaaS 三类 PaaS 平台， 底层共享 IaaS 平台资源，
可帮助企业解决协作数据分析、 数据管理混乱、 规范应用开发流程、 存量应用治理、 资源冲
突与效率管理的困难与问题。

参考资料：星环科技官网

TDC 基于容器云技术，构建在云原生操作系统 TCOS 之上，一方面保证资源灵活扩展和调度，

提供了完善的容器服务；另一方面基于容器，提供全套的数据服务和应用服务。通过让用户能
够快速部署、管理大数据产品服务，例如高性能数据仓库、数据集市等，实现资源的有效整
合。通过在线应用市场，支持第三方应用的上架、共享、部署，让用户快速适应对新应用、新
服务、新场景的需求。通过数据资产、模型管理功能，真正打通“计算-数据-模型”的关联环
节，实现有机整合和全局管理。

产品特点：
（一）分析 PaaS
TDC 分析 PaaS 平台满足数据分析服务内外开放的需求， 允许大量数据工程师、 数据科学家在
一个平台上并发工作， 促进相互协作。TDC 提供多种分析平台， 打通数据集， 分析人员无需在
不同工具和平台上重新定义策略， 将有效减少团队因在不同平台上分析导致重新配置和调参的
时间浪费， 并对模型提供系统化高效管理。

（二）数据 PaaS
TDC 数据 PaaS 平台可解决数据分散、 隔离问题， 避免交换障碍， 使各类数据资产共享集中

37
存储， 实现数据服务开放、 数据相互交换， 并搭载数据资产目录以提供综合数据治理。

同时，TDC 数据平台包含丰富的数据开发套件，提供了完善的数据开发环境， 并支持跨租户共

享套件，可以简化数据开发的过程，提高数据开发的资源使用率，解决开发数据开发的痛点和
效率问题。

（三）应用 PaaS
TDC 应用 PaaS 提供了丰富完整的中间件和应用开发平台， 解决应用开发、 部署、 运维、治理
的效率问题， 可应对企业面临的各类应用开发和管理障碍。

对于应用开发，TDC 提供主流的应用开发必备工具、 应用微服务化框架、DevOps 工具链， 可

有效规范应用开发过程， 提高效率并控制质量。 同时，TDC 提供服务部署和服务治理能力， 具
备资源弹性扩展、 资源隔离、 容错等特性。

企业数据应用中心构建全流程

原单位业务系统 微服务平台
规划调研 平台上线

应用中心设计阶段 开发运维阶段

单体应用梳理 微服务运营

微服务拆分 部署阶段

微服务设计 微服务开发

参考资料：星环科技官网

（四）IaaS 平台
星环云操作系统 TCOS 基于容器技术管理计算、存储、网络等各类物理资源，为上层的分析
PaaS、数据 PaaS 和应用 PaaS 提供了统一的资源管理、应用生命周期管理、全面的监控与告
警、多维度的计量计费等功能， 从而有效地提高了资源管理和应用运维效率。

TCOS 可基于异构的 x86、ARM 架构 CPU，以及 Linux、Windows、UOS 和银河麒麟等异构操作

系统节点。另外，TDC 云管平台通过纳管 IaaS 主流平台，可为上层 PaaS 及用户提供虚拟机、
虚拟网络和对象存储等服务。

38
3.4 容器云平台的发展策略

云计算作为新一代的信息服务基础设施，形态在不断演进。但无论云如何发展，云的价值都将
回归于应用本身。随着 户需求的不断更迭，凸显了传统技术栈的能 不 。同时，基于云原
理念的容器平台不断发展，已经逐渐成熟。现结合业界主流容器服务提供商的现状分析，容
器云平台具备以下 个发展趋势：

· 混合云
根据《Flexera 2020 年云状态报告》显示，企业正在拥抱多云。其中 93％的企业采用了多云
策略；87％的企业拥有混合云策略；许多组织在给定的公共或私有云中隔离应用程序，其中
41％的应用程序在云之间集成数据等等；33％的企业使用多云管理工具。如今混合云已成为
企业的主流选择。

用户可将核心业务、数据保留在本地，互联网业务等迁移到云中，即可保证用户的数据安
全，又可拥有强大的灵活性，同时保证最佳的成本控制。而混合云则成为实现这一目标的最
佳方法，同时云原生时代，底层基础设施实现了标准化和虚拟化，使得应用与运行环境分
离，促使基于容器化的混合云正在成为业界趋势。

· 场景化、定制化行业应用
2020 年“新基建”成为各领域的焦点，新基建的稳步实施，促使企业的数字化转型加快，如
何快速、有效地将业务流程数字化，构建高效数字化 IT 系统已经成为企业数字化转型首要解
决的问题。并且，通过此次疫情，企业更加清晰地意识到数字化对于企业业务的发展起到至
关重要的作用，从而保证业务的连续性。可见领先的技术支撑固然重要，深入行业与应用场
景同样关键。

目前，容器云平台可解决企业业务应用从开发、测试到部署、运维的全生命周期的需求，并
为企业提供 IT 基础设施和基础技术服务。为了更好地服务客户数字化转型，容器云平台可以

针对某些特定行业提供行业解决方案。对于一些有定制化需求的客户，首先可根据行业建立
基本需求，同步获取客户需求，根据用户场景进行定制。

根据 IDC 预测，到 2024 年，51%的全球 IT 预算将来源于数字化创新/数字化转型，中国这一占

比将超过 70%。这将对每个企业产生巨大的影响。而 “数字化优先” 将成为数字经济进程中的
重点。相信容器云平台必将成为企业转型变革的核心。

39
4 容器云平台的机遇与挑战
4.1 云原生技术发展
云原生最初由 CNCF 提出之后，经过这几年发展，不断落地实践和丰富，已经完成了概念普及阶
段，进入了快速发展期。云原生技术以其高效、轻量、与应用紧密结合、快速响应的特点帮助
企业构建更加适用于云上的应用服务。

云原生产业联盟发布的《云原生发展白皮书 - 2020》提到，过去几年中，云原生关键技术正在
被广泛采纳，如 43.9% 的用户已在生产环境中采纳容器技术，超过七成的用户已经或计划使用
微服务架构进行业务开发部署等，这使得用户对云原生技术的认知和使用进入新的阶段，技术
生态也在快速的更迭，特征明显。

云原生技术生态日趋完善，细分项目不断涌现。相较于早年的云原生技术生态主要集中在容器、
微服务、DevOps 等技术领域，现如今的技术生态已扩展至底层技术、编排及管理技术、安全技
术、监测分析技术以及场景化应用等众多分支，初步形成了支撑应用云原生化构建的全生命周期
技术链。同时细分领域的技术也趋于多元化发展，如在容器技术领域，从 Docker 这种通用场景
的容器技术逐渐演进出安全容器、边缘容器、Serverless 容器、裸金属容器等多种技术形态。

4.2 企业级需求
企业上云的初期阶段是把现有 IT 系统搬迁到云上，更多在虚拟化层面的改造工作，随着云计算
生态的蓬勃发展，原有的应用架构陈旧，在扩展性、适配性、弹性伸缩、资源调度、开发运维
等方面与云计算架构的优势不匹配，无法真正发挥云的价值。云原生技术通过标准化资源，轻
量化弹性调度等特征，应用场景较为广泛，随着技术和生态不断成熟和完善，有效缓解企业上
云顾虑，真正发挥云的价值。

数据联邦
在大型现代企业中，组织中的各部门使用不同数据库管理系统来存储和搜索其重要数据，这几
乎是不可避免的。竞争、不断发展的技术、合并、收购、地域分布以及扩展中不可避免的分散
等因素都会造成这种多样性。但只有将这些系统中的信息组合起来，企业才会认识到这些系统
所包含数据的整体价值。

联邦学习
联邦学习（Federated Learning）是一种新兴的人工智能基础技术，在 2016 年由谷歌最先提

40
出，原本用于解决安卓手机终端用户在本地更新模型的问题，其设计目标是在保障大数据交换
时的信息安全、保护终端数据和个人数据隐私、保证合法合规的前提下，在多参与方或多计算
结点之间开展高效率的机器学习。联邦学习可使用的机器学习算法包括神经网络、随机森林等
重要算法。其有望成为下一代人工智能协同算法和协作网络的基础。

4.2.2 混合云和多云

混合云
云计算发展过程中，出于数据安全考虑，企业往往愿意使用私有云。但是私有云建设周期长，
成本高，无法满足互联网业务的特点，因此希望使用公有云，以获取可伸缩的计算资源。在这
种情况下混合云被越来越多地采用，它将公有云和私有云进行混合和匹配，以获得最佳的效
果。混合云是将本地基础设施（通常是私有云）与公有云结合在一起的云计算环境。混合云包
括内部系统（或私有云）和第三方公有云服务的混合，两个平台之间使用统一的云管系统。

多云
多云是一种云方式，由多个云供应商提供的多个云服务组成，包括公有云服务提供商（如 AWS
和 Microsoft Azure）和私有云服务提供商（如 VMware 和 Oracle）。多云是混合云的一种形
式，用于表示在多个不同的公有云环境中运行。本质上，多云是指订阅多个公有云服务，而混
合云是指同一组服务的多个部署模式（公有、私有或遗留）。多云部署通常是避免供应商与单
个云服务提供商锁定的策略的一部分。

4.2.3 灾备

结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的 “两地三中心”的灾备
模式也随之出现，这一方案兼具高可用性和灾难备份的能力。

同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备
基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系
统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持
业务连续运行。

异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心
出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。

4.2.4 云边协同

随着 5G 通信技术的发展，越来越多的实时性强的业务开始兴起，如自动驾驶、AR/VR、智能家
居、工业自动化等，传统的云计算加端业务的集中式处理模型很难满足大量数据传输和实时处
理的需求。因此，云边端的处理模型应运而生，即边缘计算。

41
边缘计算的兴起，使得如何为边缘侧赋能成为业界关注的热点。边缘的具体形态分为边缘云和
边缘终端。边缘云是云计算向网络边缘侧进行拓展而产生的新形态，是未来产业关注重点，是
连接云和边缘终端的重要桥梁。边缘终端位于边缘云与数据源头路径之间，靠近用户或数据源
头的任意具备一定硬件配置的设备，包括边缘网关、边缘服务器、智能盒子等终端设备。围绕
边缘云与边缘终端，在 CDN、视频渲染、游戏、工业制造、自动驾驶、农业、智慧园区、交通
管理、安防监控等应用场景。

边缘云和中心云（数据中心）的协同，是云计算从单一数据中心部署向不同物理位置多数据中
心部署、从中心化架构向分布式架构扩展的新模式。

4.2.5 安全

云上的安全态势也成为企业数字化转型最大挑战之一。根据中国信通院调查报告显示，42.4%
的企业在选择公有云服务商时会考虑服务安全性，43% 的企业在私有云安全上的投入占 IT 总投
入的 10% 以上，企业如何构建安全云平台成为上云的关键要素。

但与数字化升级的进度相比，企业安全体系建设发展相对缓慢。企业在上云过程中，安全建设
相对滞后，通常在云平台建设完成之后才启动安全能力建设，仅仅作为补充措施，以传统安全
防护模式为主。传统的安全防护方案存在硬件设备昂贵、安全资源利用率低、部署困难、云上
数据难以获取、数据流通差、安全产品联动性差等弊端。

在企业上云的全程融入安全能力，或直接选择安全实力更强的云平台，有助于解决传统安全建
设理念存在的弊端。云原生安全理念并不是只解决云原生技术带来的安全问题，而是一个全新
的安全理念，旨在将安全与云计算深度融合，将安全能力内置于云平台中，实现云化部署、数
据联通、产品联动，可以充分利用安全资源，降低安全解决方案使用成本，帮助云计算客户更
安全地上云。

4.3 从支撑传统应用到支撑数字化应用 - 数据云平台（Data

Cloud）
对于企业或组织而言，由于内部对于数据资源的应用不再仅仅局限于 IT 部门，越来越多的内部
项目组与分支机构加入大数据平台的使用中，加之数据处理技术的不断发展，如何解决基础平
台的资源隔离问题、管理分配问题、编排调度问题；如何将企业业务应用需要的基础服务能力
做更好地抽象，降低应用所需的基础服务的环境搭建、开发、测试部署周期，提升 IT 支撑效
能；如何更好地管理众多的基于大数据与人工智能开发的应用等成为企业亟需解决的问题。

2020 年 9 月 16 日，云原生数据库厂商 Snowflake 在纽交所上市，总市值超 700 亿美元，成为

有史以来规模最大的软件 IPO。Snowflake 的高歌猛进成为了数据云平台发展趋势的最佳佐证。
云原生数据库的核心是存储与计算分离，同时还具备高性能、高可扩展、一致性、符合标准、

42
容错、易于管理和多云支持等特性。这样的理念与容器云支撑数据云的技术方式不谋而合，都
通过数据云来统一支持企业的数据科学、数据工程、数据湖、数据仓库等在内的数字化需求。
不同之处在于，前者面向公有云，而容器云能在私有云场景下提供更多支持。

容器云平台的形成伴随着 Docker、Kubernetes 等容器技术的发展，与微服务等技术概念的形

成，大数据与人工智能基础平台开始基于容器云构建底层资源管理与调度平台。容器云就像一
个分布式的操作系统，将集群中的各类硬件资源进行封装、管理以及调度，将封装的资源作为
容器承载大数据的相关组件进程，再将这些容器进行编排，组成一个个的大数据和人工智能的
基础服务，如分布式文件系统 HDFS、NoSQL 数据库 Hbase、分布式分析型数据库 Inceptor、
分布式流处理平台 Slipstream、分布式机器学习组件 Sophon 等。

由这些基础服务编排构建公共能力服务层，提供如数据仓库、数据集市、图数据库、全文搜索
数据库、流处理服务、NoSQL 数据库、机器学习平台服务、定制图像识别服务等，为企业打造
全新的数据处理核心系统。基于这一核心系统服务于各类企业的不同部门。通过资源隔离技
术，通过对每个租户的资源分配和权限管理，满足业务分析人员的个性化分析需求，专注于业
务逻辑的开发和数据的分析挖掘。

星环科技（上海）有限公司已开始使用容器化大数据云平台的理念进行了成功的商业化运行。
2020 年 6 月 5 日，云计算开源产业联盟在 OSCAR 开源先锋日云原生专场活动中公布了“云原
生应用十大优秀案例”的评选结果，其中由星环科技（上海）有限公司提供服务的中国联通容
器化大数据能力开放平台，经委员会组织权威专家评审通过并收录入编。

申通通用云原生计算平台 上海申雪供应链管理有限公司 阿里云计算有限公司

中国联通容器化大数据能力开放平台 中国联合网络通信有限公公司 星环科技（上海）有限公司

光大科技有限公司
中国光大银行容器云 PaaS 平台 光大银行
北京灵雀云科技有限公司

基于云原生的转运作业融合系统 德邦快递 杭州网易质云科技有限公司

中国移动10086客服系统云原生化实践 中移在线服务有限公司 杭州谐云科技有限公司

研发一体化平台 广东电力信息科技有限公司 苏州博纳讯动软件有限公司

营销魔方 中国民生银行股份有限公司信用卡中心 苏州博纳讯动软件有限公司

金融级云原生保险中台 国泰财产保险有限公司 浙江蚂蚁小微金融服务集团股份有限公司

SeeTaas自主可控人工智能生产平台基 中科视拓（北京） 科技有限公司 北京金山云网络技术有限公司

于金山云容器引擎的最佳实践
场景化数据服务中台 中国民生银行 阿里云计算有限公司

云原生应用十大优秀案例名单

未来，企业或组织在数字化转型当中各类新的诉求，给企业或组织从底层 IT 基础设施到数据服
务化和应用化提出了更高要求。对此，大数据 + 容器云 + 人工智能的融合，实现了多云平台、
多数据中心的数据打通和统一管理，帮助企业或组织达到平台化、生态化的数字化转型目标。

43
结语
相比疲态尽显的传统虚拟机技术，容器技术轻量、高效，解决了应用交付和运维的诸多痛点，
正在推动传统应用转型为云原生应用，从而也促使容器云平台进入到一个爆发式发展的阶段。

容器集群管理工具 Kubernetes，通过了大规模生产环境和关键业务持续运行的考验，技术逐渐
成熟，已经成为了构建容器云平台事实上的标准，国内外各大云服务厂商也相继推出了基于
Kubernentes 的容器云产品。

基于容器技术，将人工智能、大数据与云计算融合，是新时代的需求与自然趋势，统一的容器
云平台支撑企业不同的工作负载，高效连接应用和数据，让用户更专注于业务创新或将成为容
器云平台发展的最大挑战。

44
参考文献
《中国公有云发展调查报告（2020 年）》中国信息通信研究院

《中国私有云发展调查报告（2020 年）》中国信息通信研究院

《中国混合云发展调查报告（2020 年）》中国信息通信研究院

《云原生技术实践白皮书 （2019 年）》（征求意见稿 ）中国信息通信研究院

《容器云产品发展现状分析》 杨新章 林园致 何震苇 著

《Kubernetes 权威指南—企业级容器云实战》闫健勇 著、电子工业出版社出版

《基于 Kubernetes 的容器云平台实战》陆平 著、机械工业出版社

《企业级容器云架构开发指南》HPE ku8s team 著、机械工业出版社

《大数据、人工智能与云计算的融合应用》选自《信息技术与标准化》2018.3 星环科技 朱珺辰 著

《The Snowflake Elastic Data Warehouse》 SIGMOD '16

《Market Guide for Container Management》Gartner 2019

《Hype Cycle for Platform as a Service》Gartner 2020

《Cloud Data Platforms For Dummies》David Baum John Wiley & Sons

《Cloud Native Security Whitepaper》CNCF

《CNCF Storage Landscape Whitepaper》CNCF

展望前沿趋势、了解最佳实践
请关注InfoQ Pro