文章目录

前言

在互联网行业，越来越多的人开始谈云原生，却鲜少有人会说清楚到底什么是云原生，若是找资料来看，读完大多会感觉云里雾里，一知半解，总之虚得很。

其实云原生之所以解释不清楚，是因为云原生的确没有固定的定义，云原生一直在发展变化之中，不同企业或个人，对云原生的理解也不相同、再加上云原生的概念其实也一直在升级变化。就导致新人想要理解云原生，变得越发困难，找不到着力点。

所以今天我们就来简单易懂的解释下到底什么是云原生，以便新人也能理解云原生，也能参与到云原生中。

定义

技术的变革，一定是思想先行。

云原生并不是某种技术、框架或者软件，而是一套构建和运行应用程序的方法，是一套技术体系或方法论。云原生这个专业术语（CloudNative）是一个组合词，是Cloud和Native的组合。

Cloud表示应用程序位于云上，关于云的概念大家应该都懂吧，可以理解为是线上的。其实也就是指git，maven这样的代码仓库，都位于云端，而不再是传统的代码都存本地；微服务化，服务与服务之间相互调用，这些都是“位于云上”最好的理解方式。

Native表示应用程序从设计之初即考虑到云的环境，充分利用和发挥云平台的弹性以及分布式优势。熟悉docker的同学都知道，云端的程序并不运行在本地，而是运行在远端机器上。准确的说是远端机器的docker容器中，配合k8s对docker进行管理，实现了弹性扩容缩容。这样的效率和易操作性是传统的部署方式无法比拟的。

Matt Stine首次提出云原生（CloudNative）的概念，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性，Matt Stine将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器云原生计算基金会（CNCF）成立，把云原生定义为包括：容器化封装+自动化管理+面向微服务，CNCF又更新了云原生的定义，在原有基础上加入了服务网格(Service Mesh)和声明式API

而我理解作为小白，最容易也最快速理解云原生，无非以下几个元素，架构符合这几个元素，就是“云原生”了：

采用开源堆栈（K8S+Docker）进行容器化基于微服务架构快速迭代运维自动化利用云平台设施实现弹性伸缩、动态调度、优化资源利用率

再精简点？那就是：

K8S+Docker 进行容器化微服务架构

这样理解起来是不是容易多了？

但是，是否满足上面几点就一定是“云原生”呢，其实也并不一定。这样的定义只是为了方便小白入门，而真正严格意义的云原生，当然要复杂一些。接下来我们再看下云原生的四大特征：

特征

微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务就不多解释了吧~

每个服务完成一个独立的功能，基于SpringBoot，服务与服务之间通过rpc或者消息中间件来进行通信。

微服务架构的好处就是服务解耦，内聚更强，变更更易。

容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC（linux容器技术）技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡。

DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑，比如灰度发布。

那么再反问一句，满足以上要求就一定是“云原生”吗？

其实也不一定，因为所谓“云”，是一种思想，而并不是一个固定的格式或者固定的模式。

极端而言，如果你自己买了两台服务器，放在办公室，上面部署了容器，然后用Kubernetes来管理，那就是云原生吗？

并不是，因为缺乏弹性、API自动化部署和运维的能力。

所谓云原生，除了上述的特征外，其实更重要的是它的核心思想：弹性。

云原生，更看重的是应用的弹性，部署服务器可多可少，开发持续交付等，其实这些，都指向一个灵活，弹性。

与传统开发的固化，死板相对应。

即，能够做到灵活、弹性、持续，这才称得上云原生。

如果觉得《如何通俗易懂理解云原生》对你有帮助，请点赞、收藏，并留下你的观点哦！