我们为什么需要云原生？

原标题：我们为什么需要云原生？

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

如今在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的大势所趋，甚至必然选择。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。