Download as pdf or txt
Download as pdf or txt
You are on page 1of 27

云原生的技术探索

与落地实践
目录 CONTENTS

一、云原生概述

1. 云原生:云计算的下一站 03

2. 云原生的前世今生 04

3. 云原生的价值链生态 05

二、主要云原生技术

1. 云原生底层技术 08

2. 编排与管理 08

三、云原生基于开源策略走向全新竞合

1. 开源社区是实践平台化战略的最佳场所 16

2. 开源策略是构建技术生态圈的有效路径 16

四、云原生技术的落地与应用
1. 云原生创新技术方案及产品 18

2. 云原生在各行业的落地应用 20

五、未来展望

1. 云原生技术生态将成为企业数字化转型的创新平台 24

2. 自助化、智能化基础设施重塑用户侧视角 25

3. 云原生的安全前置不可或缺 25
回首过去十年,云计算的高速发展推动数字化转型不断深入,云原生作为云计算的下一站,在重
构 IT 产业的同时,也为更多领域释放了新的技术红利与增长机遇。虽然云原生概念由来已久,
但对于云原生的理念边界、价值理解却众说纷纭。云原生究竟如何界定?如何借助云原生视角透
视云计算、开源?云原生又将如何赋能企业实现业务价值? InfoQ 基于对云原生技术生态的深刻
观察,将通过该报告为您展开一幅从技术演进、到商业策略革新、再到业务价值释放的“云原生”
全景图,梳理技术发展脉络、剖析商业创新模式、观察行业实践的红利释放,看“云原生”浪潮如
何吞噬旧秩序、重塑新世界。

主要观察发现:

1. 云原生本质上是一套指导软件架构设计的思 4. 微服务带来基础架构复杂性激增,促使开发

想,定义了一条能够让应用最大程度利用云能力、 侧和运维侧关注点分离,不断泛化的 Serverless 将

发挥云价值的最佳路径,是基于云计算 PaaS 概念 成为 DevOps 的一种思想导向和组成部分,


“轻运维”、

全新容器化思路、更贴近企业业务侧的价值延伸。 “NoOps”、“自助式运维能力”将成为应用运维的主

2. 云原生价值链贴近业务侧的向上延伸,基于 流方式。

越来越多的非业务逻辑从应用程序剥离下沉到基础 5. 开源策略成为构建云原生技术生态圈的有效

设施,在此进程中,Kubernetes 成为整个云原生技 路径,推进云原生企业走向全新竞合,开源社区成

术生态的底层技术标准与关键价值节点。 为其实践平台化战略的最佳场所。

3.Service Mesh 的核心价值在于实现业务逻辑 6. 伴随云原生应用的不断丰富,基础设施的资

与非业务逻辑的分离,Serverless 将其功能从服务 源服务向精细化管理、更优成本、极致弹性、以及研

间同步通信推广到计算、存储、数据库等诸多场景, 发效能、交付优化的全生命周期转化,将重构整个信

越来越多使用 kubernetes 服务的应用将转化成为 息产业,乃至医疗、制造、交通、教育等传统行业的

Serverless 应用。 基础设施构建形式,加速赋能全产业信息化升级。

02
一、云原生概述

【1】云原生:云计算的下一站
十年互联网浪潮下,熠熠生辉的是 IT 技术的飞 建立在“未来的软件一定生长于云”的核心假设之上。

速发展,从云计算到云原生,已经迎来送往了多个 依托该思想而设计的软件:首先,软件本身“生于云、

时代。云计算带来了从底层的算力分配到上层应用 长于云”;其次,这样的软件能够天然集成“云”环境,

的快速更迭,而基础软件作为更好运用云能力的有 进而释放“云”的最大价值。

效路径,更是不断迸发出崭新的思想洪流,云原生 云原生尚处高速发展变化之中,没有确切的

在这样的思潮下应运而生。 概念界定。可借鉴的说法是:云原生定义了一条

云原生本质上是一套指导软件架构设计的思想, 能够让应用最大程度利用云能力、发挥云价值的

03
最 佳 路 径。 具 体 来 说, 参 考 云 原 生 计 算 基 金 会 (Kubernetes+Docker) 进 行 容 器 化, 基 于 微 服

(CNCF)的定义,云原生包括容器化封装、自动 务架构提高灵活性和可维护性,借助敏捷方法、

化管理、面向微服务、服务网格、声明式 API。符 DevOps 支持持续迭代和运维自动化,利用云平台

合云原生架构的应用程序应该是:采用开源堆栈 设施实现弹性伸缩、动态调度、优化资源利用率。

【2】云原生的前世今生

纵观云原生技术发展历程,PaaS 概念的普及为 器编排,社区开始在 Kubernetes 的基础上构建上层

IT 领域平台型业务模式建立了思想先导,Docker 的 的业务抽象,伴随微服务、Serverless、FaaS 等技

开源拉开了云原生的序幕,也重新定义了 PaaS 的全 术理念的实践,Kubernetes 逐渐成为云原生技术生

新容器化思路。随后,CNCF 的诞生宣告云原生技术 态的操作系统,企业在此基础上搭建业务侧的上层建

演进的重心从容器转移到以 Kubernetes 为核心的容 筑,最大程度利用云价值。

图 云原生的前世今生(资料来源:InfoQ 研究院)

1. 平台化和 PaaS 概念的普及 度、华为、IBM 等众多厂商开启了以开源 PaaS 为

在 2014 年之前,企业上云的普遍做法是租赁 核心构建平台层服务能力的变革,PaaS 概念得以

AWS 或 OpenStack 虚拟机、并通过脚本或者手工 真正普及。

方式部署应用,这一时期的开源 PaaS 项目因提供

了应用托管能力而被广泛接纳。在 Cloud Foundry 2. Docker 容器成为主流,PaaS 被重新定义


等项目度过了艰难的概念普及和用户教育之后,百 Docker 的 出 现 重 新 定 义 了 PaaS,Docker 通

04
过镜像功能解决了应用打包的根本性问题,避免了 当 Kubernetes 通 过 先 进 的 设 计 理 念、 可 扩
用户只能通过不断试错才能匹配不同运行环境差异 展的插件机制以及开放的治理模式在整个社区推
的痛苦过程,伴随着 Docker 原生的容器集群管理 进民主化架构,基于 Kubernetes API 和可扩展
项目 Swarm 的发布,原有的 PaaS 时代宣告结束, 接口先后涌现了 Istio、Operator、Rook 等优质
并被重新定义成一套以 Docker 容器为技术核心, 项目。在成为分布式资源调度和自动化运维的事
以 Docker 镜像为打包标准的、全新的容器化思路。 实 标 准 的 基 础 上,Kubernetes 逐 渐 体 现 出 云 原
这也预示着一个以容器为中心的、全新的云计算市 生时代底层操作系统的特征,向下封装资源、向
场呼之欲出。 上支撑应用,特别是伴随微服务、Serverless 等

技 术 理 念 的 落 地,Kubernetes 支 撑 了 更 多 的 垂

3. Kubernetes 成为云时代的底层操作系统, 直解决方案,这些解决方案在用户侧形成了真正

上层应用不断丰富 的商业价值。

【3】云原生的价值链生态

从技术发展的价值链演进来看,云原生是云计 术标准与关键价值节点,实现功能的不断剥离下沉。

算应用价值的延伸,解决更贴近企业业务、架构、 而展望未来,中国规模化的应用场景将更好促进云

组织层面的关键问题。伴随应用场景的不断深化, 原生技术的创新演进,成为云原生的最好生长土壤

Kubernetes 已经成为整个云原生技术生态的底层技 和试验田。

图 云原生的价值链生态(资料来源:InfoQ 研究院)

05
1. 云原生是云计算价值链的延伸与最大化 越来越多的第三方开源项目以云原生理念开发、

云计算、云原生如同很多基础架构类产品一 部署和运维,最后演变成为一种云服务;另一方面,

样,其价值的产生并非源于自身,而是来自于用 企 业 也 可 以 依 托 Kubernetes 灵 活 的 架 构 能 力 实

户基于广泛场景的大量应用。云计算沿大数据价 现基础设施资源的统一管理、业务架构的统一、

值释放的生命周期不断演化,通过不断吸纳先进 以及构筑统一的 IT 应用管理平台,从而真正实现

技术赋能数据的获取、存储、处理分析和价值联 对企业内各类业务的统一管理。

结等环节,为企业提供了高效、低成本的基础设

施资源。在云计算逐渐由资源中心演变为创新技 3. 中国规模化的技术沙盒成为云原生创新的最好
术熔炉的过程中,云原生更进一步,帮助企业将 土壤
应用和业务“云化”,解耦业务和基础设施,只关 近年来,中国更具规模化的应用场景已经愈

注业务逻辑和价值,将非业务逻辑的复杂性下沉 发成为云原生技术创新、试验的最好土壤。在这个

到基础设施,使基础设施更高效、更高性能、更 拥有着 14 亿人口、动辄电商大促、全产业链升级

稳定可靠,从而更充分释放云的价值。 的试验田里,峰值交易量超 50 万笔、数据总量近

千 PB 的流量成为常态,中国健全的产业体系和庞

2. 基于 Kubernetes 的“云原生架构技术平台”实 大规模成为历练云原生技术的沙盒,用于创建和测

现企业内各类业务的统一管理 试各种可能的解决方案。从中国走出去的开源项目

伴 随 云 原 生 的 宏 大 版 图 徐 徐 展 开, 如 Apache Kylin、CNCF 旗 下 的 Harbor、TiDB/

Kubernetes 成为了企业建设云原生基础架构和部 TiKV, 还 有 在 中 国 得 到 进 一 步 历 练 的 Apache

署新一代应用服务的事实标准。根据容器创业公 Pulsar,甚至包括 Apache Flink 乃至 Kubernetes

司 Sysdig 发布的 2019 年容器使用报告,在容器 本身,都在中国场景的极限压测下得到了进一步的

编排平台的选择上,Kubernetes 占据了 77% 的 升级。

份额。随着亚马逊、微软、谷歌、VMware 等 IT 根据中国信通院《中国云原生用户调查报告

大 厂 自 2015 年 先 后 基 于 Kubernetes 进 行 自 身 2020》 显 示, 我 国 云 原 生 技 术 用 户 60% 以 上 为

业务的云原生改造,目前已有超过 90 个厂商提供 互联网企业,其中千人以上规模的企业占比高达

了 认 证 Kubernetes 的 云 服 务 或 发 行 版, 并 提 供 35.11%,中国应用的广泛场景和庞大规模对云原

了丰富的周边软件、服务的配套支持。一方面, 生技术的拉动已成事实。

06
二、主要云原生技术

云原生的技术体系看似纷乱繁杂,但在不同视 量化、上云提供可能。

角都体现着“牵一发而动全身”的主线。从时间线 从技术需求的角度来看,微服务架构是解决单

来 看, 容器技术的发展催生了云原生思潮,在底 体复杂度问题的首选方式,却带来整个系统的整体

层解决了资源供给问题,随后开源的 Kubernetes 复杂度大幅增加,容器技术和 Kubernetes 分别解

成为容器编排的标准规范,当基于 Kubernetes 可 决了微服务架构下大量应用的部署、以及容器的管

扩展能力的开放应用平台逐渐丰富,使其成为了 理 和 调 度 问 题, 同 时,Kubernetes 也 为 Service

云原生生态最重要的基石。随后 Service Mesh、 Mesh 提供了更好的底层支撑,也带来了底层基础

Serverless 技术的核心思想更偏重在业务侧实现价 设施的 Serverless 云原生化和中间件能力的进一

值——将更多的能力下沉到基础设施,为应用的轻 步下沉。

图 业务需求驱动云原生技术发展(资料来源:InfoQ 研究院)

07
【1】云原生底层技术

容器 Docker 与 虚 拟 机 的 差 异 体 现 在 进 程 隔 离 方

容器是将进程有效的划分一个独立空间,以便 式 的 不 同,Docker 通 过 为 应 用 附 加 额 外 设 置 的

在独立的空间之间平衡资源使用冲突的技术。本质 Namespace 参数实现进程的隔离,并没有一个真正

上,容器是一种特殊的进程,其核心功能是通过约 的”Docker 容器“运行在宿主机中,这样的“障眼法”

束和修改进程的动态表现创造出一个“边界”,此外, 操作让进程仿佛运行在一个与世隔绝的“容器”里面,

其资源限制能力、以及基于镜像功能表现出的“强一 使得容器减少了额外的资源消耗和占用,在敏捷和

致性”,都使得容器技术成为云原生最关键的底层技 高性能方面具有很大优势。

术之一。 此外,容器的核心功能还包括基于 Cgroups 的

Docker 容器因具有和虚拟机相似的隔离效果, 资源限制能力、以及镜像功能。Cgroups 的作用是

而常常被称为”轻量级“虚拟化技术,但这样的说法 限制一个进程组能够使用的资源上限,包括 CPU、

并不严谨。在虚拟机中,Hypervisor 是最主要的部分, 内存、磁盘、网络带宽等资源。镜像功能使得容器

它通过硬件虚拟化功能,模拟出 CPU、内存、I/O 技术表现出“强一致性”,即在任何地点下载的镜像

设备等各类硬件,之后在这些虚拟的硬件上安装了 内容完全一致,完全复现镜像制作者当初的完整环

一个新的操作系统,即 Guest OS,在虚拟的操作系 境,这打通了“开发 - 测试 - 部署”等流程的各个环节,

统中运行的应用进程被相互隔离。 使得容器技术成为软件的主流发布方式。

图:虚拟机(左)与 Docker 容器(右)工作原理(资料来源:网络)

【2】编排与管理

Kubernetes 整个容器技术栈上的关键价值节点。主要的容器编

当容器镜像成为应用分发的工业标准,能够定 排 工 具 包 括 Docker 公 司 的 Compose+Swarm 组

义容器组织和管理规范的“容器编排”技术便成为了 合、Mesosphere 公司的 Mesos+Marathon 组合、

08
Google 与 RedHat 公司共同主导的 Kubernetes 项 横向扩展功能:实现基于 CPU 利用率或基于平

目、 以 及 基 于 Kubernetes 构 建 的 OpenShift 和 台级的弹性伸缩,如自动增加、删除 nodes 节点。

Rancher 项目。最终,Kubernetes 项 目 凭 借 优 秀

的开放性、可扩展性以及活跃开发者社区,在容器

编排之战中脱颖而出,成为分布式资源调度和自动

化运维的事实标准。

K u be r n e t e s 项 目 的 主 要 设 计 思 想 在 于 ,

从 更 宏 观 的 角 度, 以 统 一 的 方 式 来 定 义 任 务 之

间 的 各 种 关 系, 并 且 为 将 来 支 持 更 多 种 类 的 关

系留有 余 地 。从 功 能 的 角 度 来 看 ,K u b e r n e t e s

更 擅 长 按 照 用 户 的 意 愿 和 整 个 系 统 的 规 则, 自

动 化 地 处 理 好 容 器 之 间 的 各 种 关 系, 即 容 器 的

编 排 , 包 括 部 署、 调 度 和 节 点 集 群 间 扩 展 等 主

要功能。而 Mesos、Swarm 等项目擅长把一个

容器,按照某种规则,放置在最佳节点运行起来,
图:Kubernetes 全局架构(资料来源:极客时间,《深入剖析
即容器的调度。这也是 Kubernetes 项目最终脱 Kubernetes》,张磊)

颖而出的重要原因。

Kubernetes 项 目 由 控 制 节 点 Master 和 计 算

Kubernetes 核心能力: 节点 Node 组成。Master 作为控制管理的节点,

服务发现和负载均衡:通过 Service 资源展现各 由三个紧密协作的独立组件组成:kube-apiserver

种应用服务,结合 DNS 和多种负载均衡机制, 负责 API 服务,kube-scheduler 负责资源调度,

支持容器化应用之间的相互通信。 kube-controller-manager 负责容器编排,另外,

存储编排:通过 plungin 的形式支持多种存储, 集群的持久化数据由 kube-apiserver 处理后保存

如本地、nfs、ceph、公有云块存储等。 在 Etcd 中, 如 Pod、Service 等 对 象 信 息。 计 算

资源调度:设置 pod 调度的所需资源和资源限制, 节点 Node 作为项目的工作负载,kubelet 组件是

支持应用的自动发布和应用回滚,管理应用的相 其最核心的部分,负责 Pod 对应的容器的创建、

关配置。 启停等任务,同时与 Master 节点密切协作,实现

自动修复:监测集群中所有宿主机,自动发现和 集群管理的基本功能。

处理集群内异常,更换需重启的 pod 节点,使 如今,Kubernetes 项目不仅是容器技术的事实

容器集群运行在用户的期望状态。 标准,更成为整个云原生体系发展的基石,重新定

密钥和配置管理:通过 secret 存储敏感信息,通 义了基础设施领域对应用编排与管理的各种可能。

过 configmap 存储应用的配置文件,避免将配置 在整个云原生生态中,Kubernetes 项目起到了承上

文件固定在镜像中,增加容器编排的灵活性。 启下的作用。对上,Kubernetes 暴露出基础设施能

09
力的格式化数据抽象,如 Service、Ingress、Pod、 方式。随着业务发展与需求不断增加,单体应用功

Deployment, 都 是 Kubernetes 本 身 原 生 API 为 能愈发复杂,应用迭代效率由于集中式研发、测试、

用户暴露出来的能力。而对下,Kubernetes 提供 发布、沟通模式而显著下滑。

了基础设施能力接入的标准接口,如 CNI、CSI、 微服务架构本质上是通过承受更高的运维复杂

DevicePlugin、CRD,让云能够作为能力提供商, 度来换取更好的敏捷性,其优势在于小而治之、去

通过标准化的方式把能力接入到 Kubernetes 的体 中心化,但也导致基础架构的需求、成本和复杂性

系中。伴随着微服务、DevOps 等技术理念的发展, 激增。

基于 Kubernetes 可扩展能力的开放应用平台将取 目前为止,微服务并没有统一的标准定义,

代 PaaS 成为主流,而云的价值会回归应用本身, 结合 Martin Fowler 的描述:微服务架构是一种

越来越多的开源项目会以云原生理念去开发、部署 架构模式 / 架构风格,将单独的应用程序开发为

和运维,最后直接演进成为一种云服务。 一套小服务并独立运行在自己的进程中,相互之

间使用 HTTP API 等轻量级机制通信。这些服务

微服务 围绕着具体业务进行构建,通过完全自动化部署

微服务是服务架构演进的产物,在历经单体架 机制来独立部署,并可使用不同的编程语言书写,

构、垂直架构、面向服务的架构(SOA)之后,微 以及不同数据存储技术,并保持最低限度的集中

服务架构(MSA)可视为 SOA 架构的分布式实现 式管理。

图 单体架构、垂直架构、SOA、微服务架构对比(资料来源:InfoQ 研究院)

10
Dubbo 和 Spring Cloud 走向融合,更多的功能将被 Cloud 和 gRPC 生 态,Go 项 目 与 Java&Dubbo 项
下沉到基础设施 目的互通问题得到了有效解决。时至今日,由于
Spring Cloud Spring Cloud Alibaba 的出现,Dubbo 将无缝整合
Spring Cloud 是第一代微服务架构的翘楚,为 Spring Cloud 生态的各种周边产品。
实现微服务架构提供了一站式解决方案,作为一个 无论是 Dubbo 还是 Spring Cloud,都或多或
全家桶式的技术栈,为开发者提供了快速构建分布 少限定于特定的应用场景和开发环境,缺少对通用
式系统的通用模型的工具,包括配置管理、服务发现、 性和多语言性的支持,并只解决了微服务 Dev 层面
熔断器、智能路由、微代理、控制总线、一次性令牌、 的问题,缺少 DevOps 的整体解决方案,这些都为
全局锁、领导选举、分布式会话、集群状态等。 Service Mesh 的兴起创造了条件。

Dubbo 作 为 微 服 务 管 理 和 通 讯 的 完 整 解 决 方 案,

Dubbo 作为由阿里巴巴开源的分布式服务框架, Dubbo 和 Spring Cloud 将 长 期 共 存 并 走 向 融

致力于提供高性能和透明化的 RPC 远程服务调用方 合,但其提供的部分功能将逐渐被基础设施所取

案,以及 SOA 服务治理方案。核心部分包含:远程 代。 如 部 署 在 kubernetes 集 群 上 的 微 服 务, 利

通讯、集群容错、自动发现等。 用 kubernetes 的 服 务 注 册 和 发 现 的 功 能 会 更 加

近年来 Dubbo 生态不断完善,2019 年 5 月, 简 单; 再 如 使 用 Istio 架 构, 流 量 管 理 和 circuit

Dubbo-go 的 正 式 加 入 Dubbo 官 方 生 态, 随 后 实 breaker 等 功 能 将 转 移 到 envoy 代 理, 越 来 越 多

现了 REST 协议以及 gRPC 的支持,打通了 Spring 的功能会从应用程序剥离并下沉到基础设施。

11
Service Mesh Envoy 和 Istio。Linkerd 和 Envoy 都 直 接 体 现 了

Service Mesh 通常被译为服务网格,在云原生 Service Mesh 的核心理念,在功能上较为相似,即

应用复杂的服务拓扑结构中,Service Mesh 作为基 实现服务发现、请求路由、负载均衡等功能,解决

础设施层,负责在这些拓扑结构中实现请求的可靠 服务之间的通信问题,使得应用对服务通信无感知。

传递。Service Mesh 通过在请求调用的路径中增加 而 Istio 站在了更高的角度,将 Service Mesh 分为

Sidecar,将原本由客户端完成的复杂功能下沉到 了 Data Plane 和 Control Plane, 由 Data Plane

Sidecar 中,实现对客户端的简化和服务间通信控 负责微服务间的所有网络通信,而 Control Plane

制权的转移,当系统中存在大量服务时,服务间的 负 责 管 理 Data Plane Proxy, 且 Istio 天 然 支 持

调用关系表现为网状,这也是服务网格名称的由来。 Kubernetes,这也弥合了应用调度框架与 Service

我们可以从以下几个特征对 Service Mesh 的 Mesh 之间的空隙。

定义给出概括和总结: 微服务落地需要一套完整的基础设施,当容器

成为微服务的最小工作单元,Kubernetes 作为通用

抽象:Service Mesh 将通信功能从应用中剥离 的容器管理平台,能够发挥微服务架构的最大优势,

出来,形成一个单独的通信层,并将其下沉到基 使其成为云计算的新一代操作系统。Kubernetes 不

础设施层。 仅能够支持运行云原生和传统的容器化应用,并且

功能:Service Mesh 负责实现请求的可靠传递, 覆盖 Dev 和 Ops 阶段,与 Service Mesh 的结合可

从功能上来说和传统的类库方式并无不同。 以为用户提供完整端到端的微服务体验。

部署:Service Mesh 在部署上体现为轻量级网

络代理,以 Sidecar 模式和应用程序一对一部署, Serverless


两者之间的通信通过 Localhost 远程调用。 Serverless 将 Service Mesh 的应用场景泛化,

透明:Service Mesh 的功能实现完全独立于应 不仅仅局限于服务间的同步通信,而是推广到有网

用程序,可以独立部署升级、扩展功能、修复缺 络访问、通过客户端 SDK 实现的更多场景,包括计

陷,应用程序无须关注 Service Mesh 的具体实 算、存储、数据库、中间件等各种服务。如在蚂蚁

现细节,即对应用程序是透明的。 金服的 Serverless 实践中,Mesh 模式还延伸到了

Database Mesh(数据库访问 )、Message Mesh

Service Mesh 的核心价值不只体现在其功能和 (消息机制 )、Cache Mesh(缓存)等场景。

特性,更在于实现业务逻辑和非业务逻辑的分离。 目 前,Serverless 通 常 被 看 作 是 FaaS( 函

非业务逻辑将被从客户端 SDK 剥离,以 Proxy 独立 数 即 服 务)、BaaS( 后 端 即 服 务) 的 集 合, 但

进程运行,从而将原来存在于 SDK 中的各种能力下 Serverless 只定义了一种用户体验,而不是某种技

沉到基于容器、Kubernetes 或 VM 的基础设施,实 术,FaaS、BaaS 都 只 是 Serverless 的 一 种 实 现 方

现云上的托管、应用的轻量化,以帮助应用云原生化。 式。随着 Serverless 技术的不断成熟,越来越多使用

主流的 Service Mesh 开源软件包括 Linkerd、 kubernetes 服务的应用将转化成为 Serverless 应用。

12
云原生中间件 据交流,通过提供消息传递和消息排队模型,实现

传统中间件类似于城市中的输水管道,推动并 在分布式环境下扩展进程间的通信,并基于数据通

管理数据从一个应用流向另一个应用,其业务耦合 信进行分布式系统的集成。常见的消息中间件包括

度高、不能为用户带来直接价值。进入云时代,软 ActiveMQ、 RabbitMQ 、RocketMQ 、Kafka 等,

件的异构现象、互联需求显著增加,中间件被赋予 可应用在跨系统的数据传递、高并发的流量削峰、

了新的功能定义,即功能独立、耦合度低、组件模 数据异步处理等场景。

块化,并被下沉到基础设施,成为实现高性能、高 进入云计算时代,云厂商提供更加贴近业务的

可用、高伸缩性和最终一致性的分布式应用开发架 封 装, 多 采 用 自 身 的 Serverless 服 务 来 运 行 事 件

构的关键组成部分。 负载,中间件的能力很容易通过云服务来实现,包

从功能定义来看,中间件是一类连接软件组 括 阿 里 云 Function Compute、Azure Function、

件和应用的计算机软件,它包括一组服务,以便于 AWS Lambda 都集成了事件处理。

运行在一台或多台机器上的多个软件通过网络进行 未来,应用中间件将不再是能力的提供方,

交互,属于可复用软件范畴。云原生中间件包括 而是能力接入的标准界面,这个标准界面将通过

API、应用服务器、TP、RPC、MOM,也可以承担 HTTP、 gRPC 协议进行构建,并通过 Sidecar 解

数据整合、应用整合的作用,任何位于内核和用户 耦整个服务的接入层与应用业务逻辑,这与 Service

应用之间的软件都可以理解为中间件。 Mesh 的思想一致。更进一步的,Sidecar 模型能够

伴随 IoT、云计算技术的快速发展,EDA(事 应用在所有的中间件场景,从而将中间件能力“下沉”

件驱动架构)正在被越来越多的企业采纳,通过事 到 Kubernetes 能力的一部分。

件的抽象、异步化,来提供业务解耦、加快业务迭代,

也正在从支持垂直行业转向通用关键业务应用架构, DevOps
应用在打包应用、开发工具、业务过程管理和监视 伴随云原生开源生态不断完善、以及复杂功能

等领域。 不断下沉到云,基本统一了软件部署和运维的基本

EDA 往往通过消息中间件实现,消息中间件旨 模 式。 在 DevOps 之 前, 从 业 人 员 使 用 瀑 布 模 型

在利用高效可靠的消息传递机制进行平台无关的数 或敏捷开发模型进行软件项目开发。DevOps 作为

图 传统瀑布模型、敏捷开发模型、DevOps 开发模型对比(资料来源:InfoQ 研究院)

13
Development 和 Operations 的组合,被定义为实 行机械化操作。

现软件开发和 IT 团队之间流程自动化的一组实践, 从上述发展理念来看,DevOps 的思想源于基

这些实践建立在团队之间协作文化的基础上,填补 础设施层不够强大、不够标准化,所以业务侧需要

了开发端和运维端之间的信息鸿沟,以便更快、更 一套工具来黏合研发、运维人员和相应的基础设施。

可靠地构建、测试和发布软件,目前已经成为主流 但随着 Kubernetes 和基础设施越来越复杂,云原

的软件开发交付模式。 生生态会做出相应的抽象和分层,每一层的角色只

总体来看,DevOps 包含了开发、测试和运维 和属于自己的数据抽象去交互,即开发侧和运维侧

三部分。具体看来,它由多个阶段组成:持续开发、 的关注点分离。不断泛化的 Serverless 也将成为

持续集成、持续测试、持续反馈、持续监测、持续部署、 DevOps 的一种思想导向和组成部分。在能力侧,


“轻

持续运维,统称为 DevOps 生命周期。 运维”、“NoOps”、“自助式运维能力”会成为应用

DevOps 功能的分与合在信息流转层面得到了 运维的主流方式。在应用侧,应用描述会广泛地进

充分体现,在开发交付测试、测试回馈、交付发布 行用户侧的抽象,事件驱动和 Serverless 理念被

等阶段,各类信息的提供方、接收方使用优质的工 拆分和泛化,可以被应用于 FaaS 之外的多样化的

具系统,进而实现顺畅精准的传输信息和高效的执 场景中。

图:DevOps 信息流转模型(资料来源:InfoQ,《DevOps 的分与合》)

14
三、云原生基于开源策略
走向全新竞合

大体看来,开源的概念可分为开源行为、开源策略、

开源商业模式三个层次:

开源行为:指将软件的源代码公开,允许社区成员对其

进行修正、改进和创新,并将其成果与社区内的所有成

员共享。

开源策略:依托开源行为团结广泛的开发者和合作伙伴,

实现新的资源组织模式和业务的快速增长,以此来辅助

商业目标的达成。

开源商业模式:依托开源策略构建更大范围的商业闭环,

以底层的开源技术为基础,并通过构建商业层解决方案

实现盈利。

总体来说,云原生技术的开源概念是在开源策略基础

上的适当延伸,即基于开源行为,参与其中的各类主体发

挥不同作用,发展出开发者与各方合作伙伴的全新竞合关

系,借助产业链的视角,云原生呈现出形态各异的产品形

态和商业运作模式。

15
图 云原生的开源策略模型(资料来源:InfoQ 研究院)

云原生的开源策略是一套以开源行为为基础的商业运作模式,开源行为以产品开发为起点,延伸至运维、

市场化、商业化等各阶段,构建了以开源社区为中心的开源共同体,并通过云厂商、应用管理平台、发行商、

创业公司等多类角色,形成了自研集成、开源包装、应用分发、项目实施等多种产品形态和商业运作模式。

【1】开源社区是实践平台化战略的最佳场所

在生态视角下,云原生可被视为云计算领域的 效应推动社区不断壮大。

开源运动,在云原生生态的构建过程中,开源社区 开源社区不仅规模不断壮大,其承担功能也有了

不仅自身成为资源集聚的平台,也在整个生态中成 很大程度的扩展。具体来说,开源社区从局限于开发

为实践云原生平台化战略的基础。 者与使用者、合作伙伴的思想碰撞、技术建设,演进

就开源社区自身来说,开发者始终在寻找更便 到服务开源项目的长期发展,承担了开源项目的孵化、

捷的开发工具、管理工具和 API 产品,丰富的开源 商业运作等职能。如 CNCF 既承担了 Kubernetes、

产品无疑成为其提高效率的利器,而开源项目也利 Prometheus 等开源项目的维护、运营工作,自身也

用与广大开发者群体的亲密关系不断优化项目、实 通过推广开源文化、吸纳社区会员、完善治理机制、

现更友好的设计和封装,二者形成相互促进的飞轮 参与商业运作等方式帮助项目孵化和运转。

【2】开源策略是构建技术生态圈的有效路径

在企业或项目维度,平台化战略是基于开源项 区中产生巨大影响力的企业更有资格来引领云原生

目实现商业价值的最优选项。一方面,在云原生社 技术的发展方向,顶级厂商以自身开源项目为基础,

16
构建上层更丰富、更贴近业务和开发者的开源生态, +云原生应用编排管理的公司,这类公司采用项目制,

并以此为基础收割上层生态的商业价值。另一方面, 为用户提供业务、数据的上云服务,帮助用户在容器

越来越多的创业公司不再局限于包装、售卖开源技 环境中实现云原生的开发和运维,二者专注于商业链

术,而是基于开源技术构建自己的技术体系或开源 条中的不同环节。但伴随云的价值逐渐由基础设施资

生态,并不断对外推广。 源转移到应用本身、以及应用中间件能力的不断下沉,

大型云厂商、创业公司基于平台化思想,呈现出 更切近应用的创业企业会被逐渐标准化、并集成到云

全新的竞合关系。公有云厂商普遍选择投资 Docker 厂商的服务能力,二者将建立更紧密的合作关系。

案例分析:Docker、Kubernetes 技术平台化 反观 Kubernetes 则实施了更全面、更彻底的

战略解读 开源策略,围绕 Kubernetes 逐渐建立了繁荣的技

从产品功能的角度来看,Docker 和 Kubernetes 术生态。在通过组建 OCI 切割 Docker 话语权的尝

项目都取得了巨大的成功,前者彻底解决了 PaaS 用 试失败后,Google 联合 Linux 基金会建立了一个由

户一致性的问题,后者定义了容器组织和管理规范的 开源基础设施领域厂商主导的、按照独立基金会方

“容器编排”技术。但切换到构建技术生态的维度, 式运营的平台级社区— CNCF,来对抗以 Docker

二者呈现出截然相反的结果,Docker 最终走向封闭, 公司为核心的容器商业生态。在社区的运营上,

Kubernetes 则衍生了丰富的上层技术生态,依托开 Google 还联合 RedHat 来保障工程能力和项目的影

源策略实现了技术的平台化战略。 响力。在随后的对垒中,Kubernetes 更进一步,在

Docker 项目从布局之初就全面发力,从技术、 整个社区推进“民主化”架构,即:从 API 到容器运

社区、商业、市场全方位争取开发者群体,且迅速 行时的每一层,Kubernetes 项目都为开发者暴露出

走向“容器编排”这个“上层建筑”,先后发布 Docker 可扩展的插件机制,鼓励用户通过代码的方式介入

Compose、Swarm、Machine 三件套,将 PaaS 重 Kubernetes 项目的每一个阶段,Istio、Operator、

新定义为一套以 Docker 容器为核心的,以 Docker Rook 等热度极高的项目都在这样的繁荣社区中产

镜像为打包标准的、全新的”容器化“思路。可见从 生。至此,围绕 Kubernetes 形成的繁荣生态促使

初期的开源策略、技术布局,Docker 即依托开源 其成为了整个云原生体系发展的基石。

策略设想了一条可行的平台化战略路径。但随后, 相较 Docker 与 Kubernetes 的开源与平台化策

Docker 公司面对整个云计算产业的竞争和围剿, 略,Docker 通过开源推向市场,但在商业化策略中

选择将开源项目与商业产品紧密绑定,打造了一个 逐渐走向封闭。Kubernetes 更好地借助了开源社区

极端封闭的技术生态。而后,伴随 Docker 宣布放 的影响力,在合力之下获得了独有的技术“先进性”与

弃 Swarm、以及被 Mirantis 公司收购企业级业务等 “完备性”,这些特质是一个基础设施领域开源项目赖

事件的发生,其基于开源的平台化战略彻底失败, 以生存的核心价值,而后在更加开放的开源策略中推

Docker 项目最终回到原点—一款单机版软件打包 进商业运作,以 Kubernetes 为底层基础衍生了繁荣


运行工具,并错过了整个云原生浪潮。 的上层生态,最终成就了如今的地位。

17
四、云原生技术的落地与应用

【1】云原生创新技术方案及产品

伴随云原生技术底座和标准的逐渐成熟,国内 化、插件化算法集成框架、调度算法优化、异构设

云厂商和众多创业企业开始针对具有普适性的应用 备管理等特点。同时,在商业化落地过程中,方案

场景,构建产品化、标准化解决方案,帮助企业快 中内置了 Spark、Tensorflow、Flink 等几乎所有主

速实现资源获取、架构转型、业务赋能。 流计算框架,开通解决方案即可直接使用,极大简

化了企业应用门槛。

1. 华为云云原生高性能计算技术方案 某视频平台视频转码业务在应用华为云云原生

华为云作为最早投身云原生的厂商和 CNCF 在 高性能解决方案的过程中,实现了极速的弹性能力、

中国的唯一初创成员,自 2016 年以来陆续发布一 海量算力场景下高效的调度能力、跨客户 IDC 与华

系列云原生产品与解决方案,持续引领云原生技术 为云的混合调度能力,极大提升了业务的上线效率

发展方向。其中,华为云云原生高性能计算解决方 和资源利用率,部署时长由原来的 2 天下降到 30

案最具代表性的商业化落地方案,方案面向 AI、大 分钟,CPU 整体利用率由 54% 提升到 65%,资源

数据、科学计算、渲染等高性能计算场景,提供极 扩容速度由 5 分钟提升到秒级扩容。此外,该方案

速海量资源发放、智能任务调度等功能,实现了领 在互联网、生物制药、医疗、汽车行业,以及多个

先的 Serverless 架构、K8s 原生作业能力的算法优 省级超算中心、科研机构均得到深度使用。

18
2. ZStack 多云管理平台 Maven、Helm、npm、PyPI 包等 9 种常见制品库类型,
ZStack 多云管理平台是云轴科技自主研发的云 基于腾讯云 CDN 可提供全球网络极速分发的能力。
计算资源管理平台。平台针对企业 IT 基础架构在业 另外,CODING 制品库也可以跟源代码协同进行版
务需求驱动下的异构、多地域、混合云等特征,实 本化控制,与本地各构建工具和云上的持续集成、
现统一管理多种公有云、私有云等异构云基础设施, 持续部署无缝结合,一站式实现 DevOps,满足企
并提供智能运维、精准化运营、自助服务等功能, 业标准化管理在处理软件开发过程中产生的所有包
并以标准服务目录的方式将基础设施、中间件、应 类型的需求。
用等服务提供给用户。在技术创新方面,平台采用

微前端架构,实现框架代码与业务代码分离,可单 4. Authing 统一身份认证和用户信息管理平台


独部署 / 发布插件,且支持第三方厂商进行插件式 Authing 是一款为企业应用程序提供身份验证、
开发新功能。在企业应用过程中,ZStack 多云管理 授权和用户管理的 IDaaS 产品,也是国内唯一一家
平台能够提高企业多云 IT 资源运维效率、优化企业 采用云原生技术的身份服务提供商。Authing 采用
IT 运营成本,从而提升企业 IT 管理效率,助力企业 Kubernetes 容器化技术,同时支持公共云、混合云
数字化转型。 和私有云部署,支持分钟级别弹性扩容,最大可支

持亿级别用户认证访问场景。在身份认证服务上,

3. 腾讯云 CODING DevOps Authing 支持国际上主流的认证授权协议(OAuth

在企业落地 DevOps 实践中,集中统一管理持 2.0、OIDC、SAML、LDAP 等),结合零信任安全

续集成的各类构建产物并部署到生产环境是极为关 体系,满足企业内部员工身份管理、外部客户身份

键的一步,CODING DevOps 作为腾讯云旗下的一 管理、老应用兼容、新应用开发等全部场景的需求。

站式研发协作管理平台,提供从需求到设计、开发、 在开发者服务方面,Authing 提供几乎全编程语言

构建、测试、发布、部署的全流程协同及研发工具 的 SDK 支持,提供 iOS 和 Andriod 移动端快速接入,

支撑。其中,CODING 制品库功能用以管理源代码 并提供一整套微信接入方案,全面赋能国内开发者。

编译后的构建产物,提供统一、标准化的制品管理 在商业化路径方面,Authing 支持为客户提供私有

系统,解决构建产物来源多样、资源管理分散、缺 化部署,按年进行收费,并开发 PaaS 平台,为开

乏权限控制等问题,确保企业构建物的集中管理和 发者提供身份认证 RPA 和登录组件(Guard),根

高 效 分 发。 目 前,CODING 制 品 库 支 持 Docker、 据客户的需求进行个性化配置。

19
【2】云原生在各行业的落地应用

企业的数字化转型在不同视角呈现多种路径选 实践自研“阿基米德”调度系统,该系统由大规模容
择,伴随互联网企业对云原生的积极探索和实践, 器集群调度、数据库与存储技术平台、组件化微服
零售、金融、能源、交通等行业也开始将业务的云 务平台、商品图片技术平台、异地多活与智能运维、
化作为实施企业数字化转型的重要路径,积极地将 边缘计算平台构成,是支撑京东万亿 GMV 的重要基
业务上云、深度应用云原生技术与云原生架构。 础设施。目前,京东运营着全球最大规模的 Docker

集群、Kubernetes 集群,以及最复杂的 Vitess 集

1. 零售 群之一,基本实现了“All in Containers”,是全球容

我国零售业面对 14 亿人口、超 50 万笔峰值交 器化最彻底的互联网企业之一。除支撑自身业务外,

易量、近千 PB 数据总量的海量数据和市场,在电商 京东把内部多年积累的云原生开发和运维能力标准

平台、直播平台、小程序、社区团购等新模式的带动 化为 Kubernetes 集群、微服务平台、DevOps、函

下,包括前端网站、订单、结算、支付、搜索、推荐、 数服务、云安全、API 网关等上百种标准云服务,

仓储、配送、客服、售后等业务环节都面临前所未有 方便客户利用京东的云服务快速、安全、高可靠地

的挑战。电商平台迫切需要一个灵活的、有弹性的、 交付产品。

可规模化扩展的平台,这也决定了各大电商较早的关 完美日记作为上线两年即成为天猫彩妆销冠的

注、实践云原生技术。目前,云原生技术不仅在各大 新锐品牌,深知一套现代化 IT 系统对于快速适应需

电商内部开展了成功实践,更将较为完善的解决方案、 求和挖掘数据价值的重要性。自 2019 年双 11 后,

产品体系对外开放,赋能更多商家。 完美日记即开始进行针对性测试并开始容器化改

京东在 2017 年初便基于 Docker 和 Kubernetes 造,逐步应用阿里云提供的以神龙裸金属 + 容器服

20
务 ACK 为基础的云原生微服务体系架构。从实施效 快速创新与精细化管理,以此探索 IT 架构与交付模

果来看,ACK 容器服务能够快速拉起测试环境,并 式转型的落地实践。中原银行新一代信贷业务平台

利用 PTS 即时高并发流量压测确认系统水位,结合 包括零售信贷系统、对公信贷系统、小企业信贷系

ARMS 监控,诊断压测过程中的性能瓶颈,最后通 统 3 大核心业务系统。在架构设计和应用开发方面,

过 AHAS 对突发流量和意外场景进行实时限流降级, 平台基于微服务架构与领域驱动设计(DDD)方法,

这保证了每一次大促活动的系统稳定性和可用性, 搭建技术平台层、原子服务层、业务聚合层、管理

同时利用 ACK 容器快速弹性扩缩容,节约服务器成 门户层四层架构,并基于主流开源框架统一了开发

本 50% 以上。 语言与技术标准,打造成为企业级统一应用开发平

衣邦人作为率先将 C2M 模式引入服装定制领 台。在平台微服务化方面,实现了微服务全生命周

域的互联网平台,在如何打造高效的服装定制供应 期的技术解决方案,并统一了微服务的应用架构、

链、服务链、传播链等方面面临诸多难题。为破局 通讯标准、参数配置、服务部署、后台管理、监控

经营痛点,衣邦人联合智领云,通过云原生技术实 告警、调用链跟踪、日志收集等功能并将其规范和

践数据中台,实现企业的数据驱动和数字化运营。 约定集成到 SDK 中。在研发效能方面,建设一站式

BDOS 是智领云自主研发的云原生技术平台,作为 研发协同平台“原效 DevOps 平台”,平台流水线模

底层系统架构,向上承载了大数据基础能力层、数 块顺利通过工信部信通院 DevOps 成熟度工具首批

据管理运营层和数据应用层的所有服务,同时提供 “优秀级”评估,达到业界领先水平。通过探索建立

了重要的企业化运维功能。在 BDOS 应用于衣邦人 金融行业企业级云原生技术体系,中原银行有效节

的实践过程中,在实现衣邦人渠道、业务等数据全 约了服务器资源和人力成本,实现了研发人员完成

部关联的基础上,完善数据分析处理链路,实现数 一站式、全流程自动化研发和运维工作,形成了业

据分析、自动决策等功能,并基于沉淀数据形成商 务故障自愈能力和全方位监控告警能力,也增强了

品推荐的模型标准,彻底打破数据黑匣状态。 应用系统和数据的可靠性。

人保集团积极探索新一代架构标准,结合产品

2. 金融 采购及合作开发模式与腾讯云建立战略合作,全面

伴随互联网金融、数字金融等新模式快速崛起, 建设行业领先的新一代技术架构体系,并实践人保

金融服务与电子商务、社交网络以及衣食住行等生 财险核心中台业务。业务涵盖主数据、用户、工具

活场景紧密结合,用户与金融平台的连接更加紧密。 平台、财务等 9 个通用服务中心,销售、理赔等 4

传统金融机构业务创新响应周期长、资源利用率低、 个专属中心,以及人保 APP、非车分散性业务中台

系统运维难度高等问题伴随数据规模化成为其经营 核心、车险业务中台核心、合作外联统一对接平台

压力持续增大的主要原因,通过技术手段提升运营 等核心系统项目。新一代技术架构体系的实施基于

效率、实现新的业务增长点,成为金融机构的普遍 腾讯微服务平台(TSF),采用异地多活架构部署

诉求。 和分布式微服务框架,通过更强的中间件支持缩短

中原银行为适应部落化敏捷组织转型需要,启 业务响应时间、适配多样业务,架构各层可以伴随

动建设新一代信贷业务平台,支持全行信贷产品的 业务规模增长进行横向扩展、自动扩缩容、支持突

21
发高频业务(5000TPS),并提供应用全生命周期 3. 交通物流
管理、数据化运营、立体化监控和服务治理等功能。 过去十年间,伴随我国路网设施的大幅完善和

基于该项目的顺利实施,人保集团核心业务运营效 数字化升级的不断推进,交通、运输、物流等行业

率显著提升,其中新车车险定价服务响应效率提升 规模与业务体量呈现出指数级的增长。千万级的日

35%,车险线上智能出单平台出单效率提升 40%, 订单处理量、TB 级的日数据处理量对交通、物流企

合作外联平台在少量虚拟机的测试环境即可达到 业的 IT 架构、运营能力产生了巨大冲击。

9157TPS、交易响应时间在 117ms 内。 北京网路智联科技有限公司作为国内高速公路

民生银行积极践行基于云原生架构的数据中台, 收费管理和收费技术服务领域的领导者,为支撑高

支撑零售、网金、供应链、监管等 10 余个业务领 速公路门架业务的不断调整更新、满足每日海量的


域的数据诉求。结合金融数据服务特点,民生银行 信息采集处理需求,与华为云合作开展基于云原生

联手阿里云从云化工具、异构组件、云化管理三个 的技术升级。项目采用 KubeEdge 作为边云协同基

层面展开全面探索。工具层面打造一站式的数据服 础设施,实现了全国 29 个省、自治区近 10 万的超

务云化 DevOps 工作台,管理层面对云化微服务集 大规模边缘节点与应用管理,满足每日 3 亿条以上

实施“领域分区 + 技术分级 + 场景分层”多维管理, 信息采集、50 余万个应用的生命周期管理。作为典

组件层面构建符合大型金融场景的异构存储组件分 型的边缘计算场景,该项目的实践为日后车路协同、

级应用方案。从实践成果看来,已涵盖 100 余项专 自动驾驶等创新业务的发展提供了良好的平台支撑。

业化金融场景、数百项数据服务,日均调用次数超 申通物流快递业务作为非常典型的云边一体架

1000 万,是一次将中台化数据理念与云原生技术架 构,需要将大量的业务逻辑下沉到边缘,实现在同

构结合应用的成功实践。 一个平台完成云上业务及边缘侧的业务开发。基于

22
此,申通摒弃了原有的基于 Vmware+Oracle 数据 解决方案的落地实践中,针对传统业务架构部署智

库进行搭建核心业务系统架构,随着搬迁上阿里云, 能燃气表系统无法解耦、缺乏弹性等制约,青云

其架构全面转型为基于 Kubernetes 的云原生架构 QingCloud 协助津燃华润搭建安全合规的私有云环

体系,引入云原生数据库并完成应用基于容器的微 境,通过 KubeSphere 容器平台将传统业务转型迁移,

服务改造。该平台解决了原有应用升级缓慢、架构 构建测试环境和生产环境,实现 DevOps,满足新业

臃肿、不能快速迭代等问题,在成本、稳定性、效率、 务的快速上线的需求,并通过 AppCenter 提供开发

赋能业务等方面取得了显著成效。目前,申通物流 和测试环境所需要的组件。在青云 QingCloud 物联

核心业务已在云上完成流量承接,使用 1300+ 个计 网平台及 KubeSphere 容器平台的共同支撑下,津燃

算节点实时处理业务,每日处理千万级别订单量、 华润实现了用气量及抄表率精细化管理,能够及时发

亿级别物流轨迹。 现表具数据异常,科学分析行业用气,确保用气更安

全、更便捷,尤其针对工业用户用气的不规律性和其

4. 能源 他突发情况,提供人工修正和计划管理功能。

如今,各行业能耗领域内的节能潜力愈发受到

关注,尤其电力、水利、燃气等基础能源行业积极 5. 制造
尝试运用一系列技术和管理手段帮助降低能耗,用 伴随我国制造业转型升级的不断推进,传统的

以缓解日益增加的竞争压力和成本压力。 行业信息化体系结构面临内外部高效协同、功能快

在国网浙江紧水滩电厂与火山引擎的合作案例 速迭代、组织管理升级等诸多挑战,打造基于云原

中,针对电厂业务系统无法进行联动管理的痛点, 生基座的工业互联平台、保障产品生产周期的连续

火山引擎通过引入容器 +Kubernetes 技术,结合微 性和创新的敏捷性成为众多制造业企业的核心诉求。

服务框架,将逐步把水电厂的电力生产、设备运营 广汽本田汽车作为国内先进的整车生产商和服务

管理等业务系统进行微服务化改造后迁移至该平台, 商,采用华为云 CCE 敏捷版作为云原生基础设施部

构建了一个弹性灵活的 IT 基础设施环境。并基于该 署在企业 IDC,实现灵活底层资源兼容性、灵活监控

平台实现了在应用层对 AI 人工智能开发环境的快速 运维系统,以及采用 ServiceMesh 技术作为应用治

部署,帮助电厂快速便捷的介入人工智能业务领域。 理方案。从实施效果来看,广汽本田的业务自动化程

在部署容器平台 Compass 和人工智能平台 Clever 度得到显著提升,流水线一次性成功率高达 90% 以

之后,电厂在业务管理、三维虚拟仿真、生产指标 上、代码三库一致性提升至 80% 以上、实现灰度发

分析监控、人工智能应用等方面均实现了相关应用 布的业务占业务总量的 50%、代码变更后自动化发

的微服务化和高效统一管理,为国网浙江紧水滩电 布率提升到了 73%,极大的提升了产品研发效率。

厂信息化建设迈上了新的台阶。 此外,应用的监控提升至 85%、故障自动化发现率

在 津 燃 华 润 应 用 青 云 QingCloud 工 业 互 联 网 提升至 70% 以上、节省了 40% 以上的运维成本。

23
五、未来展望

【1】云原生技术生态将成为企业数字化转型的创新平台

在云计算市场的发展过程中,互联网企业带动以 将重构整个信息产业,乃至医疗、制造、交通、教育

SaaS 为主要形式的云服务迅速发展,并推动云计算 等传统行业的基础设施构建形式。云原生时代的服务

平台的应用开发环境日益成熟。云计算价值链从基础 形式将从 ISV 的软件生命周期,发展到硬件厂商、云

云演化到应用的共生,再发展到日益丰富的平台即服 厂商、ISV、企业客户之间的新一轮的软硬件的供需

务,三个层次的服务形式互为补充,云计算的覆盖场 体系,再进一步演变形成云计算技术、社区、ISV、

景也将愈发广泛。特别是伴随云原生应用的不断丰富, 开发者之间的技术互动体系。在这一进程中,云原生

基础设施的资源服务向精细化管理、更优成本、极致 技术生态将成为企业的新一代底层基础设施、创新平

弹性、以及研发效能、交付优化的全生命周期转化, 台,加速赋能全产业信息化升级。

24
【2】自助化、智能化基础设施重塑用户侧视角

伴随云的价值逐渐走向应用层,基础设施的能力 实现基础设施自助化的前提下,其智能化也成为重要

呈现声明式 API 化、自助化特征,云将以标准化的接 演进方向,通过监控数据、历史数据驱动的智能化基

入层来提供相应的能力和服务。这种变化将重塑用户 础设施会在未来成为可能。结合更加智能的调度与混

侧视角,即云的使用将从面向基础设施转变为面向应 部,资源层将走向极致弹性 + 无限资源池的方向,从

用,以应用为中心的基础设施将成为其基本形态。在 而提供极致的资源利用效能,实现成本的极低化。

【3】云原生的安全前置不可或缺

当云原生将容器技术作为下一代云计算的基础 开始就把安全策略、对安全的考量、安全配置作为

设施时,Docker 等容器的安全问题逐渐暴露,企业 应用的一部分,而不是在应用交付之后、甚至上线

在利用 DevOps 主体进行软件构建时也面临安全流 之后再进行事后的安全审计和管理。在这种将安全

程的障碍。当企业面临的安全威胁越来越复杂,安 前置的思想指导下,专注于 DevSecOps 的厂商将

全将从一开始就变成应用交付的一部分,以安全左 逐渐崛起,动态应用程序安全测试、交互式应用程

移、内嵌、自动化为标志的 DevSecOps 理念及产 序安全测试等 DevSecOps 工具链将诞生新的市场

品也将迅速落地应用。DevSecOps 即从 day zero 机遇。

参考资料:

1. 极 客 时 间,《 深 入 剖 析 Kubernetes》, 张 磊,https://time.geekbang.org/?utm_campaign=guanwang&utm_


source=baidu-ad&utm_medium=ppzq-pc&utm_content=title&utm_term=baidu-ad-ppzq-title

2. InfoQ,《DevOps 的分与合》,王振威,https://www.infoq.cn/article/3jDMGKAMYx2eAcJUzOMJ

3.《深入浅出理解微服务架构》,林一衡

4. InfoQ,《 云 原 生 五 大 趋 势 预 测,K8s 安 卓 化 位 列 其 一 》, 李 响、 张 磊,https://www.infoq.cn/article/


FiOjaG3AwC1TdWJMINal

5. InfoQ,《解读云原生基础设施》,易立,https://www.infoq.cn/article/l72zou2yhR7kMJmidEY4

6. InfoQ,《Kubernetes 是怎样席卷世界的》,小智,https://www.infoq.cn/article/tEUs3rHTGD74Kd3fYXGR

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

出品人:刘晖(Wechat:15022736778)
InfoQ 研究院高级分析师,专注 AI、云、大数据等前沿科技领域

鸣谢:感谢 InfoQ 编辑团队和参访企业的大力支持

InfoQ 研究院:
新科技趋势洞察者,技术创新咨询领军人

InfoQ 研究院依托 InfoQ 传媒多年技术领域的持续深耕、结合复合型研究团队的深


度专业积累及对最新技术趋势的深入洞察,打造出独家技术创新研究咨询方法论。
研究院以科技创新、技术发展为原点辐散相关产业、经济领域,为领军企业、中小
企业、政府部门等多类客户提供全流程、体系化、个性化技术创新咨询服务,支持
制定重大商业决策,助力把握新时代下的新机遇,全力解决新时代下商业及政府机
构技术创新突破及转型难题,致力于成为新科技领域创新咨询方面的领军人。

You might also like