我们为什么需要云原生？

在著名的《集装箱改变世界》当中，我们能看到集装箱的发明对于二十世纪全球化的巨大推动作用。集装箱，这一看起来并无多少技术含量的发明，却因为进行标准化和系统化运输的创新彻底改变了全球的货物贸易体系。

如今在 IT 领域，云计算的出现和发展相当于一次数字世界的“全球化”大发现，而云原生就相当于一次“集装箱式”的创新变革。

如果把互联网看作是数字世界里的贸易航线，那么应用软件和其中的数据就是穿行在航线上的船只和货物。在传统的 IT 架构当中，最小的货运单位就是船只（单体应用），不同的企业都有自家的船只，因此每个船只上都要配备全套的 IT 基础设施（计算、存储、网络等），船只要根据业务软件的规模提前规划，如果遇到业务增长，就只能在船上增补硬件设备，但业务下降，这些设备也只能闲置吃灰。

而云计算的出现，相当于是成立了几家大型货运公司，推出了一些超大型的标准化船只，其他企业可以选择把一部分货物交给这些货运公司去托运，甚至直接租用货运公司的船只去运货，这就涉及到云计算几种不同的服务提供方式。

伴随着云计算这种“集中式货运”的出现，一种适应云计算架构特点的应用开发技术和运维管理方式也出现了，那就是云原生。云原生的一个核心技术就是容器（Container），而容器的创新之处就非常类似于集装箱的创新。正如物理世界货运的最小单元从船只变成了集装箱，在云计算中，软件的最小单元不再是主机箱或者虚拟机，而是一个个容器。

正是随着云计算服务和容器化技术的发展下，越来越多的软件开发者和 IT 运维管理人员开始改变过去独立开发运行的传统模式，从而提出一套基于云计算特点的新的软件应用开发架构和模式，从而诞生了云原生的概念。

云有“原生”初长成

提及云原生，就必然要提到云计算。众所周知，按照云计算的服务提供方式，可以分为基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)三层。从 IaaS 到 PaaS，再到 SaaS，意味着云平台提供的工具和服务越来越多，购买云服务的企业所要做的开发相关的任务就越来越少，这一趋势为云原生的出现提供了技术基础和方向指引。

（来源：CNCF 基金会）

企业业务要想真正的云化，不仅要在基础设施和平台层面实现，而且应用本身也应该基于云的特点进行开发，从架构设计、开发方式、部署维护等各个阶段和方面重新设计，构建真正应“云”而生的“云原生应用”。

根据行业内的说法，云原生（Cloud-Native）概念的提出有几个版本，公认的是由 Pivotal 公司 CTO Matt Stine 在 2013 年首次提出。当然，这一概念被提出来是没有定义的，只是一系列技术的集合。

比如在 2010 年，WSO2 公司 CTO Paul Fremantle 在博客里也提到“Cloud Native”的概念，不过他给出的相关解释包含了分布式、多租户、按需收费、弹性可伸缩这些特点，但这些主要是云计算服务的普遍特性，还不够细化。

对于云原生概念，Matt Stine 在 2015 年发表的《迁移到云原生应用架构》的一书中列举出以下技术和特点：十二因素，微服务，子服务敏捷基础设施，基于 API 的协作，反脆弱性。

后面，这家公司的另外一位技术大牛 Kevin Hoffman 在《Beyond the 12 factor App》一书，基于原十二要素新增了三个新要素，即云原生十五要素。

对于应用开发领域的从业者，这些要素想必都非常熟悉，相当于是一份 SaaS 应用的最佳实践标准，可以适用于任何语言开发的后端应用服务，将开发流程自动化和标准化，降低开发者的学习成本。

到 2017 年，Matt Stine 再次将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理 6 特质；而 Pivotal 官网则给出了云原生的最新定义，概括为 4 个要点：容器、微服务、DevOps、持续交付。

另外一个比较正式的云原生定义是由云原生计算基金会（CNCF）提出的。在 2015 年，CNCF 成立之初，这一组织将云原生定义为包括：容器化封装、自动化管理、面向微服务；到 2018 年，CNCF 又把服务网格（Service Mesh）和声明式 API 给加到云原生的定义中来。

从云原生的多个定义来看，这一概念在不断完善和更新，不同组织和企业对于云原生的侧重点也有所不同。根据行业专家的总结，现在我们已经能够看到云原生的一个全貌特征：

（图源：王银利《云原生体系下的技海浮沉与理论探索》）

因此，整体来说，云原生是一套在云端构建和运行软件应用的方法，可以归结为一套技术方法论。“云原生”的“Cloud”，代表了软件应用是放在云端而非传统的 IT 设备中，而“Native”则代表软件应用从一开始设计，就是根据云的环境，采用云端的技术，充分利用云平台的弹性伸缩和分布式特点，最终在云端高效、稳定、安全运行。

从本质上来说，云原生是架构根植于云，基于云上开发、部署、维护的一套技术方法体系。

点开云原生的“技能树”

根据以上云原生概念的共性，我们主要拆解下容器化、微服务、持续交付，DevOps 这些涉及云技术和运维管理方法的主要特征。

首先来介绍代表性的容器技术。最初，一个软件应用都是放在物理主机上的，管理起来非常不方便，后面出现了虚拟化技术，可以通过服务器资源共享的方式，按需构建应用实例，但是虚拟化构建出的虚拟机仍然是一个完整操作系统，虽然比物理机更灵活，但仍然资源浪费的情况。那么，容器技术，就如同 IT 开发当中的集装箱，采用更小单元彻底将一个应用的资源打包在不同的容器里，从而可以适应各种应用的运行环境。

从 2004 年开始，谷歌就在内部大规模使用 Cgroups 等的 OS 虚拟化技术，2008 年，谷歌推出的 LXC（Linux Container）项目具备了 Linux 容器的雏型。2013 年，Docker 横空出世，让 Linux 容器技术快速席卷开发界。Docker 的成功，也让构建应用的最小单元变成了容器，而容器是微服务的最佳载体。

微服务就是一种跟单体应用相对应的新的应用架构，是应用服务单元的小型化和微型化。有个比喻非常贴切，单体应用就是一个大茶壶里煮很多饺子，现在变成一个小茶壶里煮一个饺子，但是拥有很多个茶壶。微服务就是要将应用的颗粒度做到最小，使之独立承担对外服务的职责。微服务的理念是随着软件系统的复杂度上升，需要投入的人力和时间资源越来越多，但却需要及时交付而出现的。

DevOps，是 Development+Operations 的组合词，也就是开发和运维的合体，当然也包含测试。DevOps 是一种敏捷开发思维和 IT 组织的沟通方法，可以促进开发、技术运营和质量保障部门之间的沟通、协作和整合，从而提高软件和服务的交付效率。反映在云原生上面，就是提高持续交付的能力。

云原生的持续交付，要做到不误时开发，不停机更新，小步快跑，要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。对于广大用户来说，现在一个最直观的感受就是很多巨型应用可以做到几乎在悄无声息见就完成更新，根本不用再一次次进行应用的下载和安装，而这就要归功于云原生的这些能力。

在软件开发领域，曾经有一个“不可能三角”的说法，也就是功能复杂程度、交付周期和可靠性这三者无法同时实现，但基于以上云原生的技术和管理方法，相当于解决了这一的一个开发难题，从而帮助企业提升应用开发效率，实现业务创新。

云原生的能力将造成这样一个结果，那就是让一个应用的底座变得越来越复杂，数据处理也越来越自动化，而应用的业务层面则越来越轻，越来越简单化。对于大众用户来说，就是应用的更新、功能的使用越来越便捷和“聪明”。

云原生“江湖”

云原生是顺应云计算时代的应用开发特点而产生的一种技术理念，因此在云原生概念一直没有明确的定义，而只有不同组织的不同的解释。相伴而生的就是云原生技术的演化和厂商的纷争。

现在一提到云原生，基本就会提及 Docker 和 Kubernetes（简称 K8s）。那么，这两者到底是怎样的关系呢？

简单来说，Docker 是目前最成功的容器工具，K8s 是目前最流行的容器编排工具。所谓“编排”，源自音乐指挥家对不同乐器演奏的协调，那么用在云原生这里，就是对包含应用程序的容器的协同关系管理。

最初，Google 已经在容器技术上有了十多年的积累，只不过，Google 的做法是秘而不宣，把基础设施的复杂性都留在内部，只给开发者和用户提供最简单的操作工具就行。但是 2013 年开源容器工具 Docker 一经推出就大受欢迎，很快就成为事实上的容器标准，这严重刺激了 Google。因此，Google 采用了“敌人的敌人就是朋友”的战略，开始支持与 Docker 分道扬镳的 CoreOS，推出了 K8s 项目，并支持 CoreOS 提出的另一个开源容器引擎 Rocket。

2014 年，当 Google 发现 CoreOS 在容器生态领域实在不是 Docker 的对手之后，决定换道超车，于当年宣布推出 K8s 容器集群编排工具，并在 2014 年 6 月 7 日将初始版本代码提交到 Github 上完全开源。而此时的 Docker 公司也雄心勃勃，于年底在 DockerCon 上发布了自己研发的“Docker 原生”容器集群管理项目 Docker Swarm，并想与 K8s 一较高下。一场“容器编排”的战争打响。

（Kubernetes 来自于希腊语，含义是舵手或领航员）

但 Kubernetes 凭借 Google 在容器集群管理系统 Borg+Omega 上的多年技术积累，很快横扫 Docker Swarm 和其他容器编排工具。到 2017 年 6 月，据 CNCF 统计：K8S 占据着 77%的市场份额，到 10 月，Docker 宣布支持 K8s，这标志着容器编排的战争基本结束，最终以 K8s 的大获全胜告终。

Docker 被 K8s 成功收编，那最大的赢家就是 2015 年成立的云原生计算基金会（CNCF），当然还有全球的开发者。

CNCF 是由 Google 牵头成立，隶属于 Linux 基金会，初衷是围绕云原生服务云计算，致力于培育和维护一个厂商中立的开源生态系统，维护和集成开源技术，支持编排容器化微服务架构应用，通过将最前沿的模式民主化，让这些创新为大众所用。

截至 2020 年 4 月，CNCF 基金会共托管 49 个云原生项目，其中，Kubernetes 是 CNCF 托管的第一个云原生开源项目。现在全球主流的科技企业和云计算厂商绝大部分都是 CNCF 会员，云厂商们把加入 CNCF 作为企业技术竞争力的宣传点。

（CNCF 全景图）

可以说，云原生在今天的发展壮大，确实离不开 CNCF 这样的中立组织所发挥的作用。假如说 Docker 一家独大，就很容易提高容器技术的使用成本，如果 K8s 不在 CNCF 开源共享，开发者又可能要面临“二选一”的麻烦。

值得注意的是，在 2020 年 12 月，K8s 宣布弃用 Docker，并非是简单地对 Docker 的“卸磨杀驴”，而是对于容器编排的进一步优化。因此，我们可以看到云原生的具体的技术工具还 演变进化当中。

到这里，我们应该对云原生的前世今生有一个基本的印象。

总的来说，云原生没有一个固定的概念定义，但却有一个清晰的逻辑，那就是软件应用正在按照云原生的方式进行深度的云化，充分贴合云计算的弹性可扩展、敏捷、分布式、自动化的特点，因云而生，又应云而行。

同时，云原生体系的技术也处在不断的演化发展当中，目前正形成以容器及容器编排、微服务、敏捷基础设施、DevOps、声明式 API 等为特点的云原生应用的技术方法论。在这些云原生技术的演进过程中，CNCF 及其提供的开源项目和开发生态将发挥更加显著的作用。

当然，尽管我们看到云原生有这样那样的好处，但是云原生从诞生到如今的破圈而红并非是一蹴而就的，云原生本身的演化也经历一个从青涩到成熟的过程。但云原生的计算价值已经落地生根，某种程度上成为了企业 IT 的大势所趋，甚至必然选择。