云原生的技术探索与落地实践.pdf

云原生的技术探索 与落地实践 一、云原生概述 二、主要云原生技术 三、云原生基于开源策略走向全新竞合 四、云原生技术的落地与应用 五、未来展望 1. 云原生：云计算的下一站 2. 云原生的前世今生 3. 云原生的价值链生态 03 04 05 08 08 16 16 18 20 24 25 25 1. 云原生底层技术 2. 编排与管理 1. 开源社区是实践平台化战略的最佳场所 2. 开源策略是构建技术生态圈的有效路径 1. 云原生创新技术方案及产品 2. 云原生在各行业的落地应用 1. 云原生技术生态将成为企业数字化转型的创新平台 2. 自助化、智能化基础设施重塑用户侧视角 3. 云原生的安全前置不可或缺 目录 CONTENTS 02 回首过去十年，云计算的高速发展推动数字化转型不断深入，云原生作为云计算的下一站，在重 构IT产业的同时，也为更多领域释放了新的技术红利与增长机遇。虽然云原生概念由来已久， 但对于云原生的理念边界、价值理解却众说纷纭。云原生究竟如何界定？如何借助云原生视角透 视云计算、开源？云原生又将如何赋能企业实现业务价值？InfoQ基于对云原生技术生态的深刻 观察，将通过该报告为您展开一幅从技术演进、到商业策略革新、再到业务价值释放的“云原生” 全景图，梳理技术发展脉络、剖析商业创新模式、观察行业实践的红利释放，看“云原生”浪潮如 何吞噬旧秩序、重塑新世界。 主要观察发现： 1.云原生本质上是一套指导软件架构设计的思 想，定义了一条能够让应用最大程度利用云能力、 发挥云价值的最佳路径，是基于云计算PaaS概念 全新容器化思路、更贴近企业业务侧的价值延伸。 2.云原生价值链贴近业务侧的向上延伸，基于 越来越多的非业务逻辑从应用程序剥离下沉到基础 设施，在此进程中，Kubernetes成为整个云原生技 术生态的底层技术标准与关键价值节点。 3.Service Mesh的核心价值在于实现业务逻辑 与非业务逻辑的分离，Serverless将其功能从服务 间同步通信推广到计算、存储、数据库等诸多场景， 越来越多使用kubernetes服务的应用将转化成为 Serverless应用。 4.微服务带来基础架构复杂性激增，促使开发 侧和运维侧关注点分离，不断泛化的Serverless将 成为DevOps的一种思想导向和组成部分，“轻运维”、 “NoOps”、“自助式运维能力”将成为应用运维的主 流方式。 5.开源策略成为构建云原生技术生态圈的有效 路径，推进云原生企业走向全新竞合，开源社区成 为其实践平台化战略的最佳场所。 6.伴随云原生应用的不断丰富，基础设施的资 源服务向精细化管理、更优成本、极致弹性、以及研 发效能、交付优化的全生命周期转化，将重构整个信 息产业，乃至医疗、制造、交通、教育等传统行业的 基础设施构建形式，加速赋能全产业信息化升级。 03 一、云原生概述 十年互联网浪潮下，熠熠生辉的是IT技术的飞 速发展，从云计算到云原生，已经迎来送往了多个 时代。云计算带来了从底层的算力分配到上层应用 的快速更迭，而基础软件作为更好运用云能力的有 效路径，更是不断迸发出崭新的思想洪流，云原生 在这样的思潮下应运而生。 云原生本质上是一套指导软件架构设计的思想， 建立在“未来的软件一定生长于云”的核心假设之上。 依托该思想而设计的软件：首先，软件本身“生于云、 长于云”；其次，这样的软件能够天然集成“云”环境， 进而释放“云”的最大价值。 云原生尚处高速发展变化之中，没有确切的 概念界定。可借鉴的说法是：云原生定义了一条 能够让应用最大程度利用云能力、发挥云价值的 【1】 云原生：云计算的下一站 04 纵观云原生技术发展历程，PaaS概念的普及为 IT领域平台型业务模式建立了思想先导，Docker的 开源拉开了云原生的序幕，也重新定义了PaaS的全 新容器化思路。随后，CNCF的诞生宣告云原生技术 演进的重心从容器转移到以Kubernetes为核心的容 器编排，社区开始在Kubernetes的基础上构建上层 的业务抽象，伴随微服务、Serverless、FaaS等技 术理念的实践，Kubernetes逐渐成为云原生技术生 态的操作系统，企业在此基础上搭建业务侧的上层建 筑，最大程度利用云价值。 图 云原生的前世今生（资料来源：InfoQ研究院） 【2】 云原生的前世今生 1. 平台化和 PaaS 概念的普及 在2014年之前，企业上云的普遍做法是租赁 AWS或OpenStack虚拟机、并通过脚本或者手工 方式部署应用，这一时期的开源PaaS项目因提供 了应用托管能力而被广泛接纳。在Cloud Foundry 等项目度过了艰难的概念普及和用户教育之后，百 度、华为、IBM等众多厂商开启了以开源PaaS为 核心构建平台层服务能力的变革，PaaS概念得以 真正普及。 2. Docker 容器成为主流，PaaS 被重新定义 Docker的出现重新定义了PaaS，Docker通 最佳路径。具体来说，参考云原生计算基金会 （CNCF）的定义，云原生包括容器化封装、自动 化管理、面向微服务、服务网格、声明式API。符 合云原生架构的应用程序应该是：采用开源堆栈 （Kubernetes+Docker）进行容器化，基于微服 务架构提高灵活性和可维护性，借助敏捷方法、 DevOps支持持续迭代和运维自动化，利用云平台 设施实现弹性伸缩、动态调度、优化资源利用率。 05 从技术发展的价值链演进来看，云原生是云计 算应用价值的延伸，解决更贴近企业业务、架构、 组织层面的关键问题。伴随应用场景的不断深化， Kubernetes已经成为整个云原生技术生态的底层技 术标准与关键价值节点，实现功能的不断剥离下沉。 而展望未来，中国规模化的应用场景将更好促进云 原生技术的创新演进，成为云原生的最好生长土壤 和试验田。 过镜像功能解决了应用打包的根本性问题，避免了 用户只能通过不断试错才能匹配不同运行环境差异 的痛苦过程，伴随着Docker原生的容器集群管理 项目Swarm的发布，原有的PaaS时代宣告结束， 并被重新定义成一套以Docker容器为技术核心， 以 Docker镜像为打包标准的、全新的容器化思路。 这也预示着一个以容器为中心的、全新的云计算市 场呼之欲出。 3. Kubernetes 成为云时代的底层操作系统， 上层应用不断丰富 当Kubernetes通过先进的设计理念、可扩 展的插件机制以及开放的治理模式在整个社区推 进民主化架构，基于Kubernetes API和可扩展 接口先后涌现了Istio、Operator、Rook等优质 项目。在成为分布式资源调度和自动化运维的事 实标准的基础上，Kubernetes逐渐体现出云原 生时代底层操作系统的特征，向下封装资源、向 上支撑应用，特别是伴随微服务、Serverless等 技术理念的落地，Kubernetes支撑了更多的垂 直解决方案，这些解决方案在用户侧形成了真正 的商业价值。 图 云原生的价值链生态（资料来源：InfoQ研究院） 【3】 云原生的价值链生态 1. 云原生是云计算价值链的延伸与最大化 云计算、云原生如同很多基础架构类产品一 样，其价值的产生并非源于自身，而是来自于用 户基于广泛场景的大量应用。云计算沿大数据价 值释放的生命周期不断演化，通过不断吸纳先进 技术赋能数据的获取、存储、处理分析和价值联 结等环节，为企业提供了高效、低成本的基础设 施资源。在云计算逐渐由资源中心演变为创新技 术熔炉的过程中，云原生更进一步，帮助企业将 应用和业务“云化”，解耦业务和基础设施，只关 注业务逻辑和价值，将非业务逻辑的复杂性下沉 到基础设施，使基础设施更高效、更高性能、更 稳定可靠，从而更充分释放云的价值。 2. 基于 Kubernetes 的“云原生架构技术平台”实 现企业内各类业务的统一管理 伴随云原生的宏大版图徐徐展开， Kubernetes成为了企业建设云原生基础架构和部 署新一代应用服务的事实标准。根据容器创业公 司Sysdig发布的2019年容器使用报告，在容器 编排平台的选择上，Kubernetes占据了77%的 份额。随着亚马逊、微软、谷歌、VMware等IT 大厂自2015年先后基于Kubernetes进行自身 业务的云原生改造，目前已有超过90个厂商提供 了认证Kubernetes的云服务或发行版，并提供 了丰富的周边软件、服务的配套支持。一方面， 越来越多的第三方开源项目以云原生理念开发、 部署和运维，最后演变成为一种云服务；另一方面， 企业也可以依托Kubernetes灵活的架构能力实 现基础设施资源的统一管理、业务架构的统一、 以及构筑统一的IT应用管理平台，从而真正实现 对企业内各类业务的统一管理。 3. 中国规模化的技术沙盒成为云原生创新的最好 土壤 近年来，中国更具规模化的应用场景已经愈 发成为云原生技术创新、试验的最好土壤。在这个 拥有着14亿人口、动辄电商大促、全产业链升级 的试验田里，峰值交易量超50万笔、数据总量近 千PB的流量成为常态，中国健全的产业体系和庞 大规模成为历练云原生技术的沙盒，用于创建和测 试各种可能的解决方案。从中国走出去的开源项目 如Apache Kylin、CNCF旗下的Harbor、TiDB/ TiKV，还有在中国得到进一步历练的Apache Pulsar，甚至包括Apache Flink乃至Kubernetes 本身，都在中国场景的极限压测下得到了进一步的 升级。 根据中国信通院中国云原生用户调查报告 2020显示，我国云原生技术用户60%以上为 互联网企业，其中千人以上规模的企业占比高达 35.11%，中国应用的广泛场景和庞大规模对云原 生技术的拉动已成事实。 06 07 二、主要云原生技术 云原生的技术体系看似纷乱繁杂，但在不同视 角都体现着“牵一发而动全身”的主线。从时间线 来看，容器技术的发展催生了云原生思潮，在底 层解决了资源供给问题，随后开源的Kubernetes 成为容器编排的标准规范，当基于Kubernetes可 扩展能力的开放应用平台逐渐丰富，使其成为了 云原生生态最重要的基石。随后Service Mesh、 Serverless技术的核心思想更偏重在业务侧实现价 值将更多的能力下沉到基础设施，为应用的轻 量化、上云提供可能。 从技术需求的角度来看，微服务架构是解决单 体复杂度问题的首选方式，却带来整个系统的整体 复杂度大幅增加，容器技术和Kubernetes分别解 决了微服务架构下大量应用的部署、以及容器的管 理和调度问题，同时，Kubernetes也为Service Mesh提供了更好的底层支撑，也带来了底层基础 设施的Serverless云原生化和中间件能力的进一 步下沉。 图 业务需求驱动云原生技术发展（资料来源：InfoQ研究院） 08 图：虚拟机（左）与Docker容器（右）工作原理（资料来源：网络） 容器 容器是将进程有效的划分一个独立空间，以便 在独立的空间之间平衡资源使用冲突的技术。本质 上，容器是一种特殊的进程，其核心功能是通过约 束和修改进程的动态表现创造出一个“边界”，此外， 其资源限制能力、以及基于镜像功能表现出的“强一 致性”，都使得容器技术成为云原生最关键的底层技 术之一。 Docker容器因具有和虚拟机相似的隔离效果， 而常常被称为”轻量级“虚拟化技术，但这样的说法 并不严谨。在虚拟机中，Hypervisor是最主要的部分， 它通过硬件虚拟化功能，模拟出CPU、内存、I/O 设备等各类硬件，之后在这些虚拟的硬件上安装了 一个新的操作系统，即Guest OS，在虚拟的操作系 统中运行的应用进程被相互隔离。 Docker与虚拟机的差异体现在进程隔离方 式的不同，Docker通过为应用附加额外设置的 Namespace参数实现进程的隔离，并没有一个真正 的”Docker容器“运行在宿主机中，这样的“障眼法” 操作让进程仿佛运行在一个与世隔绝的“容器”里面， 使得容器减少了额外的资源消耗和占用，在敏捷和 高性能方面具有很大优势。 此外，容器的核心功能还包括基于Cgroups的 资源限制能力、以及镜像功能。Cgroups的作用是 限制一个进程组能够使用的资源上限，包括CPU、 内存、磁盘、网络带宽等资源。镜像功能使得容器 技术表现出“强一致性”，即在任何地点下载的镜像 内容完全一致，完全复现镜像制作者当初的完整环 境，这打通了“开发-测试-部署”等流程的各个环节， 使得容器技术成为软件的主流发布方式。 Kubernetes 当容器镜像成为应用分发的工业标准，能够定 义容器组织和管理规范的“容器编排”技术便成为了 整个容器技术栈上的关键价值节点。主要的容器编 排工具包括Docker公司的Compose+Swarm组 合、Mesosphere公司的Mesos+Marathon组合、 【1】 云原生底层技术 【2】 编排与管理 09 Google与RedHat公司共同主导的Kubernetes项 目、以及基于 Kubernetes 构建的 OpenShift 和 Rancher项目。最终，Kubernetes项目凭借优秀 的开放性、可扩展性以及活跃开发者社区，在容器 编排之战中脱颖而出，成为分布式资源调度和自动 化运维的事实标准。 Kubernetes 项目的主要设计思想在于， 从更宏观的角度，以统一的方式来定义任务之 间的各种关系，并且为将来支持更多种类的关 系留有余地。 从功能的角度来看，Kubernetes 更擅长按照用户的意愿和整个系统的规则，自 动化地处理好容器之间的各种关系，即容器的 编排，包括部署、调度和节点集群间扩展等主 要功能。而Mesos、Swarm等项目擅长把一个 容器，按照某种规则，放置在最佳节点运行起来， 即容器的调度。这也是Kubernetes项目最终脱 颖而出的重要原因。 Kubernetes 核心能力： 服务发现和负载均衡：通过Service资源展现各 种应用服务，结合DNS和多种负载均衡机制， 支持容器化应用之间的相互通信。 存储编排 ：通过plungin的形式支持多种存储， 如本地、nfs、ceph、公有云块存储等。 资源调度： 设置pod调度的所需资源和资源限制， 支持应用的自动发布和应用回滚，管理应用的相 关配置。 自动修复：监测集群中所有宿主机，自动发现和 处理集群内异常，更换需重启的pod节点，使 容器集群运行在用户的期望状态。 密钥和配置管理：通过secret存储敏感信息，通 过configmap存储应用的配置文件，避免将配置 文件固定在镜像中，增加容器编排的灵活性。 横向扩展功能： 实现基于CPU利用率或基于平 台级的弹性伸缩，如自动增加、删除nodes节点。 Kubernetes项目由控制节点Master和计算 节点Node组成。Master作为控制管理的节点， 由三个紧密协作的独立组件组成：kube-apiserver 负责API服务，kube-scheduler负责资源调度， kube-controller-manager负责容器编排，另外， 集群的持久化数据由kube-apiserver处理后保存 在Etcd中，如Pod、Service等对象信息。计算 节点Node作为项目的工作负载，kubelet组件是 其最核心的部分，负责Pod对应的容器的创建、 启停等任务，同时与Master节点密切协作，实现 集群管理的基本功能。 如今，Kubernetes项目不仅是容器技术的事实 标准，更成为整个云原生体系发展的基石，重新定 义了基础设施领域对应用编排与管理的各种可能。 在整个云原生生态中，Kubernetes项目起到了承上 启下的作用。对上，Kubernetes暴露出基础设施能 图：Kubernetes全局架构（资料来源：极客时间，深入剖析 Kubernetes，张磊） 10 图 单体架构、垂直架构、SOA、微服务架构对比（资料来源：InfoQ研究院） 力的格式化数据抽象，如Service、Ingress、Pod、 Deployment，都是 Kubernetes 本身原生 API 为 用户暴露出来的能力。而对下，Kubernetes提供 了基础设施能力接入的标准接口，如CNI、CSI、 DevicePlugin、CRD，让云能够作为能力提供商， 通过标准化的方式把能力接入到Kubernetes的体 系中。伴随着微服务、DevOps等技术理念的发展， 基于Kubernetes可扩展能力的开放应用平台将取 代PaaS成为主流，而云的价值会回归应用本身， 越来越多的开源项目会以云原生理念去开发、部署 和运维，最后直接演进成为一种云服务。 微服务 微服务是服务架构演进的产物，在历经单体架 构、垂直架构、面向服务的架构（SOA）之后，微 服务架构（MSA）可视为SOA架构的分布式实现 方式。随着业务发展与需求不断增加，单体应用功 能愈发复杂，应用迭代效率由于集中式研发、测试、 发布、沟通模式而显著下滑。 微服务架构本质上是通过承受更高的运维复杂 度来换取更好的敏捷性，其优势在于小而治之、去 中心化，但也导致基础架构的需求、成本和复杂性 激增。 目前为止，微服务并没有统一的标准定义， 结合Martin Fowler的描述：微服务架构是一种 架构模式/架构风格，将单独的应用程序开发为 一套小服务并独立运行在自己的进程中，相互之 间使用HTTP API等轻量级机制通信。这些服务 围绕着具体业务进行构建，通过完全自动化部署 机制来独立部署，并可使用不同的编程语言书写， 以及不同数据存储技术，并保持最低限度的集中 式管理。 11 Dubbo 和 Spring Cloud 走向融合，更多的功能将被 下沉到基础设施 Spring Cloud Spring Cloud是第一代微服务架构的翘楚，为 实现微服务架构提供了一站式解决方案，作为一个 全家桶式的技术栈，为开发者提供了快速构建分布 式系统的通用模型的工具，包括配置管理、服务发现、 熔断器、智能路由、微代理、控制总线、一次性令牌、 全局锁、领导选举、分布式会话、集群状态等。 Dubbo Dubbo作为由阿里巴巴开源的分布式服务框架， 致力于提供高性能和透明化的RPC远程服务调用方 案，以及SOA服务治理方案。核心部分包含：远程 通讯、集群容错、自动发现等。 近年来Dubbo生态不断完善，2019年5月， Dubbo-go的正式加入Dubbo官方生态，随后实 现了REST协议以及gRPC的支持，打通了Spring Cloud和gRPC生态，Go项目与Java&Dubbo项 目的互通问题得到了有效解决。时至今日，由于 Spring Cloud Alibaba的出现，Dubbo将无缝整合 Spring Cloud生态的各种周边产品。 无论是Dubbo还是Spring Cloud，都或多或 少限定于特定的应用场景和开发环境，缺少对通用 性和多语言性的支持，并只解决了微服务Dev层面 的问题，缺少DevOps的整体解决方案，这些都为 Service Mesh的兴起创造了条件。 作为微服务管理和通讯的完整解决方案， Dubbo和Spring Cloud将长期共存并走向融 合，但其提供的部分功能将逐渐被基础设施所取 代。如部署在kubernetes集群上的微服务，利 用kubernetes的服务注册和发现的功能会更加 简单；再如使用Istio架构，流量管理和circuit breaker等功能将转移到envoy代理，越来越多 的功能会从应用程序剥离并下沉到基础设施。 12 Service Mesh Service Mesh 通常被译为服务网格，在云原生 应用复杂的服务拓扑结构中，Service Mesh 作为基 础设施层，负责在这些拓扑结构中实现请求的可靠 传递。Service Mesh通过在请求调用的路径中增加 Sidecar，将原本由客户端完成的复杂功能下沉到 Sidecar中，实现对客户端的简化和服务间通信控 制权的转移，当系统中存在大量服务时，服务间的 调用关系表现为网状，这也是服务网格名称的由来。 我们可以从以下几个特征对 Service Mesh的 定义给出概括和总结： 抽象： Service Mesh将通信功能从应用中剥离 出来，形成一个单独的通信层，并将其下沉到基 础设施层。 功能： Service Mesh负责实现请求的可靠传递， 从功能上来说和传统的类库方式并无不同。 部署： Service Mesh在部署上体现为轻量级网 络代理，以Sidecar模式和应用程序一对一部署， 两者之间的通信通过Localhost远程调用。 透明： Service Mesh的功能实现完全独立于应 用程序，可以独立部署升级、扩展功能、修复缺 陷，应用程序无须关注Service Mesh的具体实 现细节，即对应用程序是透明的。 Service Mesh 的核心价值不只体现在其功能和 特性，更在于实现业务逻辑和非业务逻辑的分离。 非业务逻辑将被从客户端SDK剥离，以Proxy独立 进程运行，从而将原来存在于SDK中的各种能力下 沉到基于容器、Kubernetes或VM的基础设施，实 现云上的托管、应用的轻量化，以帮助应用云原生化。 主流的Service Mesh开源软件包括Linkerd、 Envoy 和 Istio。Linkerd 和 Envoy 都直接体现了 Service Mesh的核心理念，在功能上较为相似，即 实现服务发现、请求路由、负载均衡等功能，解决 服务之间的通信问题，使得应用对服务通信无感知。 而Istio站在了更高的角度，将Service Mesh分为 了 Data Plane 和 Control Plane， 由 Data Plane 负责微服务间的所有网络通信，而Control Plane 负责管理 Data Plane Proxy，且 Istio 天然支持 Kubernetes，这也弥合了应用调度框架与Service Mesh之间的空隙。 微服务落地需要一套完整的基础设施，当容器 成为微服务的最小工作单元，Kubernetes作为通用 的容器管理平台，能够发挥微服务架构的最大优势， 使其成为云计算的新一代操作系统。Kubernetes不 仅能够支持运行云原生和传统的容器化应用，并且 覆盖Dev和Ops阶段，与Service Mesh的结合可 以为用户提供完整端到端的微服务体验。 Serverless Serverless将Service Mesh的应用场景泛化， 不仅仅局限于服务间的同步通信，而是推广到有网 络访问、通过客户端 SDK 实现的更多场景，包括计 算、存储、数据库、中间件等各种服务。如在蚂蚁 金服的Serverless实践中，Mesh模式还延伸到了 Database Mesh（数据库访问 ）、Message Mesh （消息机制 ）、Cache Mesh（缓存）等场景。 目 前，Serverless 通 常 被 看 作 是 FaaS（ 函 数即服务）、BaaS（后端即服务）的集合，但 Serverless只定义了一种用户体验，而不是某种技 术，FaaS、BaaS都只是Serverless的一种实现方 式。随着Serverless技术的不断成熟，越来越多使用 kubernetes服务的应用将转化成为Serverless应用。 13 云原生中间件 传统中间件类似于城市中的输水管道，推动并 管理数据从一个应用流向另一个应用，其业务耦合 度高、不能为用户带来直接价值。进入云时代，软 件的异构现象、互联需求显著增加，中间件被赋予 了新的功能定义，即功能独立、耦合度低、组件模 块化，并被下沉到基础设施，成为实现高性能、高 可用、高伸缩性和最终一致性的分布式应用开发架 构的关键组成部分。 从功能定义来看，中间件是一类连接软件组 件和应用的计算机软件，它包括一组服务，以便于 运行在一台或多台机器上的多个软件通过网络进行 交互，属于可复用软件范畴。云原生中间件包括 API、应用服务器、TP、RPC、MOM，也可以承担 数据整合、应用整合的作用，任何位于内核和用户 应用之间的软件都可以理解为中间件。 伴随IoT、云计算技术的快速发展，EDA（事 件驱动架构）正在被越来越多的企业采纳，通过事 件的抽象、异步化，来提供业务解耦、加快业务迭代， 也正在从支持垂直行业转向通用关键业务应用架构， 应用在打包应用、开发工具、业务过程管理和监视 等领域。 EDA往往通过消息中间件实现，消息中间件旨 在利用高效可靠的消息传递机制进行平台无关的数 据交流，通过提供消息传递和消息排队模型，实现 在分布式环境下扩展进程间的通信，并基于数据通 信进行分布式系统的集成。常见的消息中间件包括 ActiveMQ、 RabbitMQ 、RocketMQ 、Kafka等， 可应用在跨系统的数据传递、高并发的流量削峰、 数据异步处理等场景。 进入云计算时代，云厂商提供更加贴近业务的 封装，多采用自身的Serverless服务来运行事件 负载，中间件的能力很容易通过云服务来实现，包 括阿里云Function Compute、Azure Function、 AWS Lambda都集成了事件处理。 未来，应用中间件将不再是能力的提供方， 而是能力接入的标准界面，这个标准界面将通过 HTTP、 gRPC协议进行构建，并通过Sidecar解 耦整个服务的接入层与应用业务逻辑，这与Service Mesh的思想一致。更进一步的，Sidecar模型能够 应用在所有的中间件场景，从而将中间件能力“下沉” 到Kubernetes能力的一部分。 DevOps 伴随云原生开源生态不断完善、以及复杂功能 不断下沉到云，基本统一了软件部署和运维的基本 模式。在DevOps之前，从业人员使用瀑布模型 或敏捷开发模型进行软件项目开发。 DevOps 作为 图 传统瀑布模型、敏捷开发模型、DevOps开发模型对比（资料来源：InfoQ研究院） 14 Development 和 Operations 的组合，被定义为实 现软件开发和 IT 团队之间流程自动化的一组实践， 这些实践建立在团队之间协作文化的基础上，填补 了开发端和运维端之间的信息鸿沟，以便更快、更 可靠地构建、测试和发布软件，目前已经成为主流 的软件开发交付模式。 总体来看，DevOps包含了开发、测试和运维 三部分。具体看来，它由多个阶段组成：持续开发、 持续集成、持续测试、持续反馈、持续监测、持续部署、 持续运维，统称为DevOps生命周期。 DevOps功能的分与合在信息流转层面得到了 充分体现，在开发交付测试、测试回馈、交付发布 等阶段，各类信息的提供方、接收方使用优质的工 具系统，进而实现顺畅精准的传输信息和高效的执 行机械化操作。 从上述发展理念来看，DevOps的思想源于基 础设施层不够强大、不够标准化，所以业务侧需要 一套工具来黏合研发、运维人员和相应的基础设施。 但随着Kubernetes和基础设施越来越复杂，云原 生生态会做出相应的抽象和分层，每一层的角色只 和属于自己的数据抽象去交互，即开发侧和运维侧 的关注点分离。不断泛化的Serverless也将成为 DevOps的一种思想导向和组成部分。在能力侧，“轻 运维”、“NoOps”、“自助式运维能力”会成为应用 运维的主流方式。在应用侧，应用描述会广泛地进 行用户侧的抽象，事件驱动和Serverless理念被 拆分和泛化，可以被应用于FaaS之外的多样化的 场景中。 图：DevOps信息流转模型（资料来源：InfoQ，DevOps的分与合） 三、云原生基于开源策略 走向全新竞合 大体看来，开源的概念可分为开源行为、开源策略、 开源商业模式三个层次： 开源行为：指将软件的源代码公开，允许社区成员对其 进行修正、改进和创新，并将其成果与社区内的所有成 员共享。 开源策略： 依托开源行为团结广泛的开发者和合作伙伴， 实现新的资源组织模式和业务的快速增长，以此来辅助 商业目标的达成。 开源商业模式： 依托开源策略构建更大范围的商业闭环， 以底层的开源技术为基础，并通过构建商业层解决方案 实现盈利。 总体来说，云原生技术的开源概念是在开源策略基础 上的适当延伸，即基于开源行为，参与其中的各类主体发 挥不同作用，发展出开发者与各方合作伙伴的全新竞合关 系，借助产业链的视角，云原生呈现出形态各异的产品形 态和商业运作模式。 15 16 图 云原生的开源策略模型（资料来源：InfoQ研究院） 云原生的开源策略是一套以开源行为为基础的商业运作模式，开源行为以产品开发为起点，延伸至运维、 市场化、商业化等各阶段，构建了以开源社区为中心的开源共同体，并通过云厂商、应用管理平台、发行商、 创业公司等多类角色，形成了自研集成、开源包装、应用分发、项目实施等多种产品形态和商业运作模式。 在生态视角下，云原生可被视为云计算领域的 开源运动，在云原生生态的构建过程中，开源社区 不仅自身成为资源集聚的平台，也在整个生态中成 为实践云原生平台化战略的基础。 就开源社区自身来说，开发者始终在寻找更便 捷的开发工具、管理工具和API产品，丰富的开源 产品无疑成为其提高效率的利器，而开源项目也利 用与广大开发者群体的亲密关系不断优化项目、实 现更友好的设计和封装，二者形成相互促进的飞轮 效应推动社区不断壮大。 开源社区不仅规模不断壮大，其承担功能也有了 很大程度的扩展。具体来说，开源社区从局限于开发 者与使用者、合作伙伴的思想碰撞、技术建设，演进 到服务开源项目的长期发展，承担了开源项目的孵化、 商业运作等职能。如CNCF既承担了Kubernetes、 Prometheus等开源项目的维护、运营工作，自身也 通过推广开源文化、吸纳社区会员、完善治理机制、 参与商业运作等方式帮助项目孵化和运转。 【1】 开源社区是实践平台化战略的最佳场所 【2】 开源策略是构建技术生态圈的有效路径 在企业或项目维度，平台化战略是基于开源项 目实现商业价值的最优选项。一方面，在云原生社 区中产生巨大影响力的企业更有资格来引领云原生 技术的发展方向，顶级厂商以自身开源项目为基础， 案例分析： Docker、Kubernetes 技术平台化 战略解读 从产品功能的角度来看，Docker 和 Kubernetes 项目都取得了巨大的成功，前者彻底解决了 PaaS 用 户一致性的问题，后者定义了容器组织和管理规范的 “容器编排”技术。但切换到构建技术生态的维度， 二者呈现出截然相反的结果，Docker最终走向封闭， Kubernetes则衍生了丰富的上层技术生态，依托开 源策略实现了技术的平台化战略。 Docker项目从布局之初就全面发力，从技术、 社区、商业、市场全方位争取开发者群体，且迅速 走向“容器编排”这个“上层建筑”，先后发布Docker Compose、Swarm、Machine三件套，将PaaS重 新定义为一套以Docker容器为核心的，以Docker 镜像为打包标准的、全新的”容器化“思路。可见从 初期的开源策略、技术布局，Docker即依托开源 策略设想了一条可行的平台化战略路径。但随后， Docker公司面对整个云计算产业的竞争和围剿， 选择将开源项目与商业产品紧密绑定，打造了一个 极端封闭的技术生态。而后，伴随Docker宣布放 弃Swarm、以及被Mirantis公司收购企业级业务等 事件的发生，其基于开源的平台化战略彻底失败， Docker项目最终回到原点 一款单机版软件打包 运行工具，并错过了整个云原生浪潮。 反观Kubernetes则实施了更全面、更彻底的 开源策略，围绕Kubernetes逐渐建立了繁荣的技 术生态。在通过组建OCI切割Docker话语权的尝 试失败后，Google联合Linux基金会建立了一个由 开源基础设施领域厂商主导的、按照独立基金会方 式运营的平台级社区 CNCF，来对抗以Docker 公司为核心的容器商业生态。在社区的运营上， Google还联合RedHat来保障工程能力和项目的影 响力。在随后的对垒中，Kubernetes更进一步，在 整个社区推进“民主化”架构，即：从API到容器运 行时的每一层，Kubernetes项目都为开发者暴露出 可扩展的插件机制，鼓励用户通过代码的方式介入 Kubernetes项目的每一个阶段，Istio、Operator、 Rook等热度极高的项目都在这样的繁荣社区中产 生。至此，围绕Kubernetes形成的繁荣生态促使 其成为了整个云原生体系发展的基石。 相较Docker与Kubernetes的开源与平台化策 略，Docker通过开源推向市场，但在商业化策略中 逐渐走向封闭。Kubernetes更好地借助了开源社区 的影响力，在合力之下获得了独有的技术“先进性”与 “完备性”，这些特质是一个基础设施领域开源项目赖 以生存的核心价值，而后在更加开放的开源策略中推 进商业运作，以Kubernetes为底层基础衍生了繁荣 的上层生态，最终成就了如今的地位。 构建上层更丰富、更贴近业务和开发者的开源生态， 并以此为基础收割上层生态的商业价值。另一方面， 越来越多的创业公司不再局限于包装、售卖开源技 术，而是基于开源技术构建自己的技术体系或开源 生态，并不断对外推广。 大型云厂商、创业公司基于平台化思想，呈现出 全新的竞合关系。公有云厂商普遍选择投资Docker 云原生应用编排管理的公司，这类公司采用项目制， 为用户提供业务、数据的上云服务，帮助用户在容器 环境中实现云原生的开发和运维，二者专注于商业链 条中的不同环节。但伴随云的价值逐渐由基础设施资 源转移到应用本身、以及应用中间件能力的不断下沉， 更切近应用的创业企业会被逐渐标准化、并集成到云 厂商的服务能力，二者将建立更紧密的合作关系。 17 18 四、云原生技术的落地与应用 伴随云原生技术底座和标准的逐渐成熟，国内 云厂商和众多创业企业开始针对具有普适性的应用 场景，构建产品化、标准化解决方案，帮助企业快 速实现资源获取、架构转型、业务赋能。 1. 华为云云原生高性能计算技术方案 华为云作为最早投身云原生的厂商和CNCF在 中国的唯一初创成员，自2016年以来陆续发布一 系列云原生产品与解决方案，持续引领云原生技术 发展方向。其中，华为云云原生高性能计算解决方 案最具代表性的商业化落地方案，方案面向AI、大 数据、科学计算、渲染等高性能计算场景，提供极 速海量资源发放、智能任务调度等功能，实现了领 先的Serverless架构、K8s原生作业能力的算法优 化、插件化算法集成框架、调度算法优化、异构设 备管理等特点。同时，在商业化落地过程中，方案 中内置了Spark、Tensorflow、Flink等几乎所有主 流计算框架，开通解决方案即可直接使用，极大简 化了企业应用门槛。 某视频平台视频转码业务在应用华为云云原生 高性能解决方案的过程中，实现了极速的弹性能力、 海量算力场景下高效的调度能力、跨客户IDC与华 为云的混合调度能力，极大提升了业务的上线效率 和资源利用率，部署时长由原来的2天下降到30 分钟，CPU整体利用率由54%提升到65%，资源 扩容速度由5分钟提升到秒级扩容。此外，该方案 在互联网、生物制药、医疗、汽车行业，以及多个 省级超算中心、科研机构均得到深度使用。 【1】 云原生创新技术方案及产品 2. ZStack 多云管理平台 ZStack多云管理平台是云轴科技自主研发的云 计算资源管理平台。平台针对企业IT基础架构在业 务需求驱动下的异构、多地域、混合云等特征，实 现统一管理多种公有云、私有云等异构云基础设施， 并提供智能运维、精准化运营、自助服务等功能， 并以标准服务目录的方式将基础设施、中间件、应 用等服务提供给用户。在技术创新方面，平台采用 微前端架构，实现框架代码与业务代码分离，可单 独部署/发布插件，且支持第三方厂商进行插件式 开发新功能。在企业应用过程中，ZStack多云管理 平台能够提高企业多云IT资源运维效率、优化企业 IT运营成本，从