云原生才是「吞噬世界」的那条大鱼...

过去的一整年里，云原生(Cloud Native)无疑是云计算领域最热的热点。但一年过去了，到现在位置仍然很少有人能说清到底什么是云原生，网上的科普也都是写的云里雾里，看完仍然是似懂非懂...

这期的「SFKP • 计算机百科」，我们就来尝试着理清云原生的概念、特性以及应用场景，帮助你得出心中「云原生」的定义。

Cloud Native 翻译为云原生，是 Matt Stine 提出的一个概念，它是一个思想的集合，包括 DevOps、持续交付、微服务、敏捷基础设施、康威定律等，以及根据商业能力对公司进行重组。Cloud Native既包含技术也包含管理，可以说是一系列Cloud技术、企业管理方法的集合。(Via.百度百科)

「云原生」这个词其实也不是没爹没娘的孩子，最早由 Pivotal(一家位于美国加州的计算机软件公司)在 2013 年提出。2015 年，这家公司的 Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12 因素、微服务、自敏捷架构、基于 API 协作、扛脆弱性;

到了 2017 年，Matt Stine 在接受媒体采访的时候又将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理这六项特质;

而 Pivotal 最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

2015 年，云原生计算基金会(CNCF)成立，他们最初把云原生定义为：容器化封装 + 自动化管理 + 面向微服务;

到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式 API 给加了进来，变成了现在的版本：不可变基础设施、容器、服务网格、微服务、声明式 API。

可见，云原生的概念确实是在不断变化的，并且哪怕都是权威机构，对于云原生的概念和定义也是有所区别的。

但这些其实并不重要，因素在不断变化，根本原因是实现云原生的方式在不断变化。上面提到的这些因素都是实现云原生的方式，但有了他们也未必就一定是云原生，没有他们不一定就不能实现云原生。

又但是，既然我们在讨论什么是云原生，那就只能基于现阶段的发展情况来分析。综合各权威机构和组织的说法，微服务、容器、DevOps 和持续交付这四个因素是必不可少的，我们今天就着重分析一下这四项：

1. 微服务

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的 API 集相互通信。

几乎每个云原生的定义都包含微服务，微服务的核心方法是切割，从而解决我们软件开发中一直追求的低耦合 + 高内聚的问题，也让未来的系统变更具有弹性。

2. 容器

容器化为微服务提供实施保障，起到应用隔离作用。优势是每个服务都被无差别地封装在容器里，可以被无差别地管理和维护。现在比较流行的工具是 Docker 和 Kubernetes。

Docker 是一个开源项目，让应用程序部署在软件货柜下的工作可以自动化进行，借此在 Linux 操作系统上，提供一个额外的软件抽象层，以及操作系统层虚拟化的自动管理机制。Docker 也是目前应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用。

而 Kubernetes 是由谷歌建立的，它是一个允许自动化部署、管理和伸缩容器的工具，并且提供了一些强大的功能，例如容器之间的负载均衡，重启失败的容器以及编排容器使用的存储。

容器为云原生应用程序增加了更多优势。使用容器可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上，而无需重新配置环境，这样就实现了强大的可移植性。

3. DevOps

DevOps (Development 和 Operations 的组合词) 是一种重视软件开发人员和 IT 运维技术人员之间沟通合作的文化、运动或惯例。透过自动化「软件交付」和「架构变更」的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

DevOps 的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。

当企业或者项目有良好的沟通效率，才可以有更大的生产力。DevOps 的引入能对产品交付、测试、功能开发和维护(包括──曾经罕见但如今已屡见不鲜的──“热补丁”)起到意义深远的影响。

4. 持续交付

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!