云原生的不同解释及正确含义

云原生的解释可以说五花八门，本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。

云原生起源

网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念”。我搜索了英文“CloudNative”，阅读了首页的所有文章，里面没有一篇提到“Matt Stine首次提出云原生”，但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书，叫《迁移到云原生架构》，他以前确实在Pivotal公司工作，但说他“首次提出云原生（CloudNative）的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。

我觉得比较接近的说法是Netflix公司首创了云原生，详见 Going Cloud Native: 6 essential things you need to know 。

虽然那篇文章主要是讲的Netflix如何开创了微服务，但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步，各方面都不成熟，Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能，最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起，共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的，它的“Netflix OOS”系列工具至今仍被广泛使用，特别是Java社区，并被移植到其他语言。在这个过程中，也同时开创了云计算的先河，它的起点是2009年。详情请见 Goto Berlin - Migrating to Microservices (Fast Delivery) 。

但我想说的是云计算（Cloud）和云原生（Cloud Native）还是有很大区别的。Netflix是云计算的开拓者，但并不是云原生的创造者。云原生的基石是k8s，没有k8s就没有云原生， 而k8s的1.0版诞生于2015年。云原生计算基金会（CNCF）也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行，因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。

云原生计算基金会（CNCF）的定义：

下面就让我们看一下CNCF给出的云原生的定义：

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”

摘要来源： CNCF Cloud Native Definition v1.0

这个定义还是比较靠谱的，尽管它并不严谨，也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同，看问题的角度不同，CNCF的主要目的是培育云原生工具市场，因此它的定义带有很重的实用色彩，偏重工具方面。若是从这个角度看，这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去，其他的都没什么问题。

让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石，也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）。其中容器（Container）是k8s的底层引擎，服务网格（Service Mesh）是建立在k8s上的针对请求的扩展功能，不可变基础设施（immutable infrastructure）是现代运维的基石，声明式API（declarative APIs）是k8s的编码方式，这些无一不是和k8s紧密相关的。但微服务（Microservice）就不同了，它其实跟云原生没什么关系，它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配，它们现在的演进轨道交织在一起密不可分。

但实际上没有容器技术，微服务也可以部署在虚机上，只不过资源的利用率可能不够高。没有微服务，容器技术虽然不能大展宏图，但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼，但把微服务划归到云原生里实在是有点扩大外延，跑马圈地的意味。因为云原生的重点还是在基础设施，运维和运行环境以及软件的开发环境，而微服务是一个软件的架构，两者之间有明显的不同。

云原生的表层含义

那么到底什么是“云原生（Cloud Native）”呢？它分表层含义和深层含义。表层含义从字面上理解就比较容易了，我们管母语叫“Native Language”，也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时，大部分的程序都是从本地环境移植到云上的，它们在设计是就根本没考虑云环境的问题。

云环境与本地环境的差异

那么部署到云环境和部署到本地服务器有什么不同？这个才是问题的本质。

你可能会说“是容器技术”，这个是现代云计算的不可或缺的支撑，但云计算开始的时候是基于虚拟化的，并没有容器技术，是在发展的过程中才有了容器技术。

是“自动伸缩（auto-scaling）”吗?这是云环境的一个主要优点和特性，但它只是结果，不是本质。

云技术的三大基石：

基础设施即代码 (Infrastructure As Code）

基础设施即代码是指把创建基础设施（包括服务器和网络环境）的命令像应用程序一样储存在源码库中，并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境，出了问题就在原来的基础之上进行修修补补，一旦需要把整个环境重新建立，很难保证与原来的一样。 当使用基础设施即代码之后，再也没有了这个担心。

详情请见 InfrastructureAsCode

不可变基础设施（immutable infrastructure）

说道这里，我们不得不提“不可变基础设施（immutable infrastructure）“，它是基础设施即代码的升级版。有了基础设施即代码之后，随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备，并且还能预装应用程序，创建的时间还是秒级的。这时当服务器出现问题时，就没有必要去花时间查找原因了并修复了，而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的，只有创建和删除，而没有修改操作。这彻底改变了运维的方式。

详情请见 What is "Immutable Infrastructure"?

声明式API（declarative APIs）

声明式API也是基础设施即代码的升级版。最开始时，当用软件定义基础设施时是用的过程式描述，也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态，而由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。

上面讲了云计算环境和传统基础设施的不同，其实随着云计算的发展，传统基础设施也在不断地采纳云计算的先进技术和理念，例如虚拟化和容器技术，而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大，而通常本地私有云的版本是公有云的一个简化版。

云原生应用程序的不同

上面讲到了，只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢？

它主要有两个部分:

第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“ http://127.0.0.1 :80”, 其中“http”是协议，“127.0.0.1”是IP地址，“80”是端口。由于程序是部署在k8s上的，k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器，并创建新的服务器，IP地址就变成了动态的，而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名，并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的，软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。

第二部分是数据的持久存储。在程序运行时，经常要访问持久存储（硬盘）上的数据，例如日志，配置文件或临时共享数据。程序在容器中运行，一旦出现问题，容器会被摧毁，k8s会自动重新生成一个与原来一模一样的容器，并在上面重新部署应用程序。在集群环境下，用户感觉不到容器故障，因为系统已经自动修复了。但当容器被摧毁时，容器上的数据也一起被摧毁了，因此要保证程序运行的连续性，就要让持久存储不受容器故障的影响。

如果你对它的具体设计感兴趣，请参见 把应用程序迁移到k8s需要修改什么？

云原生的深层含义

不过云原生还有一层引申含义。当你的最终生产环境是云环境时，你的本地开发环境最好也是云环境，这虽然不是必须的，但它能保证本地环境和生产环境的一致性，减少部署时的意外，是一个很自然的选择。而要在本地使用云环境来进行开发，你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具，请继续阅读下一篇“ 云原生开发环境初探 "。

索引：

1. Going Cloud Native: 6 essential things you need to know
2. Goto Berlin - Migrating to Microservices (Fast Delivery)
3. CNCF Cloud Native Definition v1.0
4. InfrastructureAsCode
5. What is "Immutable Infrastructure"?
6. 把应用程序迁移到k8s需要修改什么？
7. 云原生开发环境初探

不堆砌术语，不罗列架构，不迷信权威，不盲从流行，坚持独立思考