云原生发展史

了解一个概念，最好的方法，就是先全面的了解一下这个概念的发展。

收集和整理了「云原生 Cloud Native」相关发展历程的资料，如下。

云原生可分解为「云」(Cloud) 和「原生」(Native) 两个词。这里还隐藏了一个词 –「计算」(Computing），因为云原生本质上是一种与云计算 (Cloud Computing)相同的计算方式，因此通常我们在说云原生的时候，实际上是暗指云原生计算 (Cloud Native Computing)。

既然说到了云原生计算本质上是一种云计算，要了解云原生的发展史，我们需要先回顾云计算的发展历史，以及与之密切相关的分布式计算的复杂性问题。详细的云计算发展史见《云计算发展史》。

我自己总结了一下，从云计算到云原生，发展阶段大致在经历4个阶段：史前阶段(萌发火种)、启蒙阶段(概念探讨)、技术发展阶段(1.0时代)、产业落地阶段(2.0时代)。

纵观软件架构的演化历史可以发现，任何新的底层软硬件技术出现后，上层应用软件都需要很长一段时间才能够真正“认识”到新的软硬件给上层应用软件带来的价值，并开发新的软件架构，以便充分利用新软硬件的能力。

最典型的例子就是 x86 CPU和服务器在面世二十多年后，以CORBA、EJB、RPC、瘦客户端等为主的多层架构才逐步成为应用开发的主流架构。

类似的还有容器技术，它最早是由 FreeBSD 于2000年在 Jails 中提出的，但真正得到大规模应用是在 2013 年 Docker 兴起之后。

应用层的代表则是微服务架构。微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始。同时在至少30年以前，一些软件设计人员就已经意识到领域建模和设计的重要性，并形成一种思潮，Eric Evans 将其定义为领域驱动设计 (Domain-Driven Design，简称DDD)，在 2003 年还出了一本书。2014年， Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务于业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API通信。但在容器出现的几年之后，基于容器的微服务架构才得以释放光彩，领域驱动设计(DDD)也逐渐热了起来。

对于云计算这一新基础设施来说，也是如此。在2015年之前，对于大多数应用来说，云端只是一个用于计算的场所，开发人员所要做的就是将原来在私有数据中心或IDC中的应用，迁移到云端。在迁移的过程中，应用无须重新编写，只需要重新部署，因为云平台提供的计算、存储、网络等，完全兼容应用迁移之前的计算环境。在迁移模式中，应用通常会将原来的物理机部署模式改成虚拟机(规格更小)部署模式；存储则选用兼容的块存储或者文件存储；网络使用SLB(Server LoadBalancer，服务器负载均衡) 替换传统的负载均衡器，构建VPC(Virtual PrivateCloud，虚拟私有云) 或NAT (Network Address Translation，网络地址转换) 网络环境；使用云数据库替换原来的MySQL或SQL Server，或者自行在云上搭建Oracle数据库。迁移之后，应用的整体成本(Total Cost of Ownership，TCO) 因为采用了「按量付费」的模式而大幅下降，同时，企业的IT支出从CapEx (CapitalExpenditure，资本性支出) 模式转变为OpEx(Operating Expense，管理支出) 模式，整个IT支出变得更可控。

如果对迁移过程进行技术分析，就会发现大部分应用使用的技术或者产品都在进行“一对一”的替换，只有极少量应用会基于OSS (对象存储服务)、MaxCompute(大数据计算服务)等云服务进行部分重构。OSS能够帮助解决分布式状态的存储问题，而MaxCompute能够解决数据仓库的快速搭建和成本问题。但由于没有或者只进行了少量重构，因此应用的技术栈本身几乎没有发生变化，也就是说，软件的架构没有发生变化，只是软件运行的平台和运维的技术体系发生了变化，即只有平台层面的变化。而软件在分布式场景下需要解决的问题，包括稳定性、组件或服务之间的数据同步、整体的高可用或容灾、CI/CD过程的自动化、资源利用率不高、端到端链路跟踪等，仍然需要应用自行解决。这些问题并不会因为应用迁移到了云平台就从根本上得到了解决。当然，各云平台为了帮助应用解决上述分布式复杂性问题，不断推出各类云服务，但是由于应用架构本身并没有发生变化，因此这些云服务并不能帮助应用解决整体问题，只能从局部提升应用的效率。

面对大量的业务需求和场景迭代，很多云平台都提供非常专业的垂直领域服务，这些服务比企业基于开源自行搭建的系统具备更高的SLA(Service LevelAgreement，服务等级协议)。比如，在数据持久性方面，亚马逊AWS的数据持久性可以达到99.9…%(11个9)，阿里云OSS的数据持久性甚至达到了99.9…%（12个9）；在跨可用区的高可用方面，阿里云RocketMQ的高可用达到了99.95%，即使整个机房不可用也能继续对外提供消息服务。如果不是应用的所有存储访问代码都在S3或OSS上重构，那么「木桶效应」就会凸显，即整个系统的数据持久性将取决于能力最差的组件；如果应用不是将所有自持的开源组件都迁移到云平台上，那么当一个机房出现故障时，应用仍然会出现高可用性的问题；如果应用不是基于FaaS (Functionas a Service，功能即服务) 技术开发的，那么应用仍然需要自行解决单个组件不可用时的Fail Over (失效转移)以及故障恢复时的Fail Back (失效后自动恢复)等问题。

可见，应用迁移到云上并不代表从此以后就高枕无忧了，如果应用本身没有基于“新”的云服务进行重构，而是继续采用「老」的架构，那么即使业务运行没有问题，应用也不能充分利用“新”的云运行环境的能力。因为这些架构是为了“老”的分布式运行环境而设计的，不是「云原生的」，所以需要对这些架构以及围绕这些架构建立的技术栈、工具链、交付体系进行升级，依托于云技术栈将其重新部署、部分重构甚至全部重写，才能将应用变成“云原生的”，从而保证能够充分利用云计算的能力。

下面我们来看看「云原生」的演进历史：史前阶段(萌发火种)、启蒙阶段(概念探讨)、技术发展阶段(1.0时代)、产业落地阶段(2.0时代)。

史前阶段 - 萌发火种 #

源于资源隔离技术的出现和演进 - 容器。

容器的最初的目的不是为了部署软件，而是为了隔离计算机中的各类资源，以便降低软件开发、测试阶段可能产生的误操作风险，或者专门充当蜜罐，吸引黑客的攻击，以便监视黑客的行为。

1979 年， Version 7 UNIX系统中提供的 chroot 命令，这个命令是英文单词「Change Root」的缩写，功能是当某个进程经过 chroot 操作之后，它的根目录就会被锁定在命令参数所指定的位置，以后它或者它的子进程将不能再访问和操作该目录之外的其他文件。

1991 年，世界上第一个监控黑客行动的蜜罐程序就是使用 chroot 来实现的，那个参数指定的根目录当时被作者戏称为「Chroot 监狱」(Chroot Jail)，黑客突破 chroot 限制的方法就称为 Jailbreak。后来，FreeBSD 4.0 系统重新实现了 chroot 命令，用它作为系统中进程沙箱隔离的基础，并将其命名为 FreeBSD jail，再后来，苹果公司又以 FreeBSD 为基础研发出了举世闻名的 iOS 操作系统，此时，黑客们就将绕过 iOS 沙箱机制以 root 权限任意安装程序的方法称为「越狱」(Jailbreak)，这些故事都是题外话了。

2000 年，Linux Kernel 2.3.41 版内核引入了 pivot_root 技术来实现文件隔离，pivot_root 直接切换了根文件系统（rootfs），有效地避免了 chroot 命令可能出现的安全性漏洞。本文后续提到的容器技术，如 LXC、Docker 等也都是优先使用 pivot_root 来实现根文件系统切换的。

2002 年，Linux Kernel 2.4.19 版内核引入了一种全新的隔离机制： Linux 名称空间 (Linux Namespaces)。名称空间的概念在很多现代的高级程序语言中都存在，用于避免不同开发者提供的 API 相互冲突，相信作为一名开发人员的你肯定不陌生。Linux 的名称空间是一种由内核直接提供的全局资源封装，是内核针对进程设计的访问隔离机制。进程在一个独立的 Linux 名称空间中朝系统看去，会觉得自己仿佛就是这方天地的主人，拥有这台 Linux 主机上的一切资源，不仅文件系统是独立的，还有着独立的 PID 编号(譬如拥有自己的 0 号进程，即系统初始化的进程)、UID/GID 编号(譬如拥有自己独立的 root 用户)、网络(譬如完全独立的 IP 地址、网络栈、防火墙等设置)，等等，此时进程的心情简直不能再好了。

2006 年，Google 的工程师 (主要是 Paul Menage 和 Rohit Seth) 发起了 cgroups 项目，当时取的名字就叫作「Process Containers」(进程容器)。不过「Container」(容器)这个名词的定义在那时候尚不如今天清晰，不同场景中常有不同所指，为避免混乱，在 2007 年这个项目被重命名为 cgroups。

2008 年，cgroups 合并到 2.6.24 版的内核后正式对外发布。

2008 年，Linux Kernel 2.6.24 内核刚刚开始提供 cgroups 的同一时间，就马上发布了名为 Linux 容器(LinuX Containers，LXC) 的系统级虚拟化功能。这是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源，为了降低普通用户综合使用 namespaces、cgroups 这些低级特性的门槛。

LXC 是 Docker 最初使用的具体内核功能实现，当然，这是很多年之后的事情了。2013 年宣布开源的 Docker 毫无疑问是容器发展历史上里程碑式的发明，然而 Docker 的成功似乎没有太多技术驱动的成分。至少对开源早期的 Docker 而言，确实没有什么能构成壁垒的技术。它的容器化能力直接来源于 LXC，它镜像分层组合的文件系统直接来源于 AUFS，Docker 开源后不久，就有人仅用了一百多行 Shell 脚本便实现了 Docker 的核心功能(名为 Bocker，提供了docker build/pull/images/ps/run/exec/logs/commit/rm/rmi等功能)。

启蒙阶段 - 概念探讨 #

2010 年 5月 28 日，WSO2的CTO和联合创始人Paul Frematantle在博客中首次提出了Cloud Native概念。在当时 Paul Fremantle 的一篇博客中被提及，他一直想用一个词表达一种架构，这种架构能够描述应用程序和中间件在云环境中的良好运行状态，他选了「Cloud Native」(云原生)。他定义云原生的主要特征为分布式的、松散的、多租户、自服务、按需计量和计费、持续部署与测试的。当时提出云原生是为了能构建一种符合云计算特性的标准来指导云计算应用的编写。

2011 年，为了让应用能够更好地使用云的PaaS平台能力开发SaaS (Software as aService，软件即服务)，PaaS提供商Heroku的Adam Wiggins提出 12因素(12-factor)，用于指导开发者在 Heroku 平台上部署和运行应用。12因素应用适用于任何编程语言，通常被认为是最早的云原生应用的技术特征。

2013 年，Docker 项目正式发布，组合LXC，Union File System和cgroups等Linux技术创建容器化标准，Docker 风靡一时，container 逐步替代VM，云计算进入容器时代。 Docker 项目的发布使得全操作系统语义的沙盒技术唾手可得，使得用户能够更好地、更完整地打包自己的应用，使得开发者可以轻而易举的获得了一个应用的最小可运行单位，而不需要依赖任何 PaaS 能力。这对经典 PaaS 产业其实是一个“降维打击”。

2013 年，Netflix 云架构师 Adrian Cockcroft 介绍了 Netflix 在 AWS 上基于Cloud Native的成功应用，Netflix在AWS上有上万个实例，每天都有数以万计的实例被创建或者删除。Adrian Cockcroft在介绍netflix在AWS上成功经验时，从目标、原则和措施三个方面进行了讲述：

目标：可扩展性、高可用、敏捷、效率。
原则：不变性，服务一旦创建，不能修改，只能重建；关注点分离，通过微服务架构实现关注点分离，避免决策瓶颈；反脆弱性，默认所有的依赖的都会失效，在设计阶段考虑这些失效问题；高信任的组织，相信自己的员工可以做出正确的决策，倡导底层员工的自主决策权；共享，透明的管理，共享能够促进技术人员的成长。
措施：利用AWS实现可扩展、高可用和共享；利用非标准化数据实现关注点分离；利用猴子工程师实现反脆弱性；利用默认开源实现敏捷和共享；利用持续部署实现敏捷、不变性；利用devops实现高度信任和共享；利用运行自己写的代码实现反脆弱性开发演进。

2014年底，CoreOS正式发布了CoreOS的开源容器引擎Rocket (简称rkt)。

2014年10月，Google 开源 kubernetes，并在 2015 年捐赠给 CNCF，kubernetes 成为 CNCF 管理的首个开源项目。

2015 年，来自 Pivotal 的 Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的特征：12因素、微服务、自服务、基于API协作、抗脆弱性。而由于这本书的推广畅销，这也成了很多人对云原生的早期印象，同时这时云原生也被 12因素(12-factor)变成了一个抽象的概念。他认为单体架构在向云原生架构的演进过程中，需要流程、文化、技术共同变革。

2015 年，Pivotal 明确地提出了云原生的概念，指出云原生是一种可以充分利用云计算优势构建和运行应用的方式。

2015 年 7 月，Google联合Linux基金会成立了CNCF组织。CNCF 成立，标志着云原生从技术理念转化为开源实现。 Linux基金会发起了一个 The Cloud Native Computing Foundation（CNCF）基金组织，CNCF基金会的成立标志着云原生正式进入高速发展轨道， google、Cisco、Docker各大厂纷纷加入，并逐步构建出围绕 Cloud Native 的具体工具，而云原生这个的概念也逐渐变得更具体化。最初定义云原生为容器化封装+自动化管理+面向微服务。

2015年6月，OCI组织成立，旨在制定并维护容器镜像格式和容器运行时的正式规范，以便在不同的操作系统和平台之间移植。

2015 年 7 月 21 日，Kubernetes 项目正式发布 v1.0。 Kubernetes 项目发布，其意义在于 Google 将内部的 Borg/Omega 系统思想借助开源社区实现了“重生”，并且提出了“容器设计模式”的思想。而 Google 之所以选择间接开源 Kubernetes 而不是直接开源 Borg 项目，其实背后的原因也比较容易理解：Borg/Omega 这样的系统太复杂了，是没办法提供给 Google 之外的人使用，但是 Borg/Omega 这样的设计思想却可以借助 Kubernetes 让大家接触到，这也是开源 Kubernetes 的重要背景。

2015 年到 2016 年，处于容器编排“三国争霸”的时代，当时 Docker、Swarm、Mesos、Kubernetes 都在容器编排领域展开角逐，他们竞争的原因其实也比较容易理解，那就是 Docker 或者容器本身的价值虽然大，但是如果想要让其产生商业价值或者说对云的价值，那么就一定需要在编排上面占据一个有利的位置。其中，Swarm 更偏向于生态，而 Mesos 技术更强一些。相比之下， Kubernetes 则兼具了两者优势，最终在 2017 年“三国争霸”的局面中得以胜出，成为了当时直到现在的容器编排标准。这一过程的代表性事件就是 Docker 公司宣布在核心产品中内置了 Kubernetes 服务，并且 Swarm 项目逐渐停止维护。

2017年9月，Mesos宣布了对Kubernetes的支持。而主导 Mesos 的 Mesosphere 公司在2019年更名为D2IQ。

2017年10月，Docker宣布将在下一版Docker，将同时支持自家调度引擎Swarm和来自Google的调度平台Kubernetes。

2017 年，Matt Stine 将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理等六个特质；而 Pivotal 最新官网对云原生概括为 4 个要点：DevOps+持续交付+微服务+容器。

2017 年，CNCF 达到 170 个成员和 14 个基金项目。

2018年3月，Kubernetes 从 CNCF 毕业，成为 CNCF 第一个毕业项目。

这里有两个重要的里程碑：

2013年，Docker发布，容器逐步替代VM，云计算进入容器时代
2017年底，Kubernetes 赢得容器编排的胜利，云计算进入 Kubernetes 时代

在容器编排大战期间，以 kubernetes 为核心的 CNCF Cloud Native 生态系统也得以迅猛发展，云原生成为云计算市场的技术新热点。一度有人把「云原生」定义为「Kubernetes 原生」。

技术发展阶段 - 1.0 时代 #

这个阶段以技术发展为主，以及主要从技术角度定义云原生，概念定义逐渐收敛和清晰化。

2018 年 6 月 11 日，CNCF正式下了定义，CNCF Cloud Native Definition v1.0：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

2018 年，云原生技术理念开始逐渐萌芽，这是因为此时 Kubernetes 以及容器都成为了云厂商的既定标准，以“云”为核心的软件研发思想逐步形成。各云厂商都在逐渐转向 Kubernetes，提供以Kubernetes为基础服务。

2018 年，CNCF 成立三周年有了 195 个成员，19 个基金会项目和 11 个孵化项目，如此之快的发展速度在整个云计算领域都是非常罕见的。

2018 年 12 月，由微软联合Docker等公司全新推出了云原生应用管理规范 CNAB，它定义了一套分布式应用打包、部署和生命周期管理的标准。

2019 年，云原生技术的普及元年。阿里巴巴宣布要全面上云，而且“上云就要上云原生”。我们还可以看到，以“云”为核心的软件研发思想，正逐步成为所有开发者的默认选项。像 Kubernetes 等云原生技术正在成为技术人员的必修课，大量的工作岗位正在涌现出来。

2019 年，CNCF 毕业了 8 个项目。

2019 年 4 月，阿里云联合 CNCF 发布了《CNCF X Alibaba 云原生技术公开课》，用于普及云原生技术

2019 年 4 月，云计算开源产业联盟发布《云原生技术实践白皮书(2019年)》

2019 年 10 月 17 日，阿里云与微软联合推出开放应用模型 Open Application Model （OAM）开源项目。OAM 的愿景是以标准化的方式沟通和连接应用开发者、运维人员、应用基础设施，让云原生应用管理与交付变得更加简洁，高效，并且可控。

2020 年 7 月，中国通信院云原生产业联盟发布《云原生发展白皮书(2020年)》

2020 年 7 月 21 日，阿里云发布《云原生架构白皮书》。阿里云发起「共同定义」云原生架构的倡议，收集了诸多架构师、开发者眼中的云原生及云原生架构的定义与思考，将之提炼并融入书中。涵盖了云原生架构的产生缘由、阿里云对于云原生架构的定义、云原生架构成熟度的定义、目前行业领先的云原生技术、阿里巴巴的云原生架构设计、云原生架构的实践案例、云原生架构未来发展趋势等内容。

上面这些定义，分别从顶层架构原则、计算模型和代表技术的角度，对云原生进行了描述。这些定义的共同点是它们都将云原生看作一种新的计算方式，让应用能够充分使用云的计算优势。进一步分析这些定义所体现出的技术观点，我们可以达成这样一个共识：只有结合云原生所提供的云服务，改造应用的架构，才能够更好地使用云原生技术，更好地构建弹性、稳定、松耦合的分布式应用，并解决分布式复杂性问题。此外，对架构的改造还意味着相关的开发模式、交付方式、运维方式等都要随之改变，比如，采用微服务架构重写应用，用声明式API和自动化工具升级运维方式，等等。

而这些技术更迭，只有一个目的，那就是通过更先进的生产力为产业提供商业价值。

产业落地阶段 - 2.0 时代 #

2021 年，云原生迈向 2.0 时代。云原生 1.0 关注技术，在技术社区形成广泛关注度；云原生 2.0 关注商业价值和产业落地，商业人群对云原生的接受度会越来越高。

2021 年 4月，华为云&中国通信源发布《云原生2.0白皮书》。

2021 年 5 月 20 日，华为云 TechWave 云原生 2.0 专题日线上举行，提出「云原生 2.0」。华为云提出云原生 2.0 八大架构原则，为企业智能升级提供架构设计参考，具体包括：容器化原则、分布式原则、微服务化原则、Serverless 原则、Service Mesh 架构原则、DevSecOps 原则、声明式 API 原则和可观测性原则。

时代还会继续发展，后续持续更新……

我对云原生的理解 #

云原生是云计算的延伸，云原生以云计算为基础，云原生是云计算的新阶段。
从利益相关者的角度来看，云原生涉及的利益相关者范围包括：
- 云基础设施提供商(私有云、公有云)
- 数字化转型的企业
- IT技术开发者(或技术爱好者)
从发展趋势来看，云原生已经从关注技术，发展到关注商业价值和产业落地；圈子的发展已经从开源/技术社区、互联网企业、大型企业，发展到中小企业、传统企业等。
从基础设施的角度来看，云计算基础设施关注资源，云原生时代的云原生基础设施关注应用，即从「以资源为中心」演进到「以应用为中心」。
从技术角度来看，云原生像其他技术体系概念一样，涉及到架构、理念、组件、技术等4个方面：
- 架构：微服务架构、12因素…
- 理念：不可变基础设施、声明式设计、DevOps、GitOps…
- 组件：Docker、Kubernetes…
- 技术：容器、微服务…
从技术生态角度来看，云原生技术生态已经在爆发式增长。从早期的容器、微服务、DevOps等领域，扩展到几十个细分领域，包括应用定义、服务网格、可观测性、云原生数据库、消息中间件等。从CNCF的 Landscape 来看，已经有1000+的开源和商业化的项目。
从商业角度来看，云原生是产业数字化转型和创新的新基建和加速器，服务于数字化转型的企业/开发者。在资源利用、环境适应性、业务连续性、交付效率等方面为客户降本增效，让客户专注于自身业务的价值挖掘。
云原生解决的核心问题：
- 为数字化转型的企业组织，提供管理数字化系统的复杂度的能力，让组织能够专注于自身的业务价值。这些复杂性体现在这些数字化系统应对环境变化、需求变化、业务规模增长等方面。
- 为云基础设施提供商提供新的思路，细化产业分工，专注资源价值、能力价值：
  - 资源价值：提供高效、低成本的资源
  - 能力价值：提供生于云、长于云的软件架构、交付和运维体系
- 并不解决这些数字化系统最终使用者的使用体验和业务能力问题，这些是数字化转型企业的业务范畴。