温馨提示：本文3000字，估计阅读时间12分钟。
在探讨过无服务器技术《沉寂多年，无服务器爆发，其硬核是什么？丨技术前沿》和裸金属技术《未来将是容器和裸金属的天下，这话有道理吗？| 技术前沿》的发展后，本篇我们讨论云原生（Cloud Native）技术。
如果说无服务器和裸金属的爆发属于间歇性的，那云原生这几年的热度就称得上持续火热，且随着云计算普及进程的不断加深，有愈演愈烈的趋势。今天再谈云原生已经不是少数几个大企业的专属，越来越多的企业正在拥抱它，享受它带来的红利。
究竟什么是云原生？能带来什么价值？本文第一篇将进行全面的梳理，后续将逐步介绍相关的技术和趋势。
云原生四要素
云原生，顾名思义，面向云而设计的。设计的什么？一套方法、一套理念、一套工具……
最早人们对云计算的认识就是改变了基础资源的使用方式，业务会逐步迁移上云。但现在再看呢？远不止这一点。云计算在重新构建IT运行的规则，“上云”和“云上”是两个概念。上云是过去对云计算的认知，也就是迁移；而云上是现在及未来对云计算的认知，是云上重新构建，这是云原生的本质。
举个例子对比，上云和云上就像后天培养和天生就有，区别是显而易见的。
进一步说，云原生的概念最早由来自Pivotal的Matt Stine于2013年提出，一直延用至今。它是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，包含内容非常多，囊括众多板块，如：
DevOps
持续交付（Continuous Delivery）
微服务（MicroServices）
敏捷基础设施（Agile Infrastructure）
12要素（The Twelve-Factor App）
……
不仅有企业文化、组织架构的重组与建设，也有方法论与原则，以及具体的操作工具。
12要素已经说了很多年了，这里将思维导图整理出来，供参考。
所以，云原生不是一个具体的产品，也绝非是把原先在传统IT架构中的东西搬上云，而是基于云的一种全新IT理念，必须是与之相关的包括应用的架构、应用的开发方式、应用的部署和维护方式都要做出改变，这样才能真正发挥出云的价值，包括弹性、动态调度、自动伸缩等，享受新IT技术带来的红利。
为了更好地推进云原生技术的发展，2015年由谷歌牵头成立CNCF，即云原生计算基金会。目前，基金会成员已有一百多家企业与机构，包括百度、亚马逊、微软、思科等巨头。
当前，CNCF所托管的应用已达14个，下图为其公布的Cloud Native Landscape，给出了云原生生态的参考体系。
CNCF认为云原生系统应该具备三大特征：
容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
自动化管理：统一调度和管理中心，从根本上提高系统和资源利用率，同时降低运维成本。
面向微服务：通过松耦合方式，提升应用程序的整体敏捷性和可维护性。
要充分理解云原生，必须对其每一个板块进行了解。而当前，业界对云原生的看法是非常一致的，那就是四要素：持续交付、DevOps、微服务、容器。
一个一个展开。
容器，云原生的基石
容器不是新概念，1979年就出现了。
很多人会将Docker与容器划等号，其实不然，Docker只是容器理念最普及的一种应用技术。容器的英文单词是Container，有集装箱的含义，而借用集装箱技术会很好理解容器的优势。集装箱的特点，在于标准化，这样可以大量堆叠，装卸也很方便。容器也是这样。
与容器做比较的是虚拟化技术。早期，大家认为硬件抽象层基于Hypervisor的虚拟化方式能够最大程度实现系统管理的灵活性，因为各种不同操作系统的虚拟机都能通过Hypervisor生成、运行、销毁。但是，随着时间推移发现，Hypervisor没有想象的那么好，因为它的原理是每个虚拟机都要安装一个完整的操作系统和大量的应用，而实际生产环境大家更关心的是自己部署的应用。显然，如果每次都部署一个完整的操作系统和大量关联的开发环境，开发效率、管理效率都会很低下。
于是有了容器这种方式，简单说，它只把应用代码运行所需相关的环境打包、封装进了一个系统，就像集装箱一样，直接运走就行，不用关心船是什么样，到哪都可以跑起来。
容器技术有四大特点：
极其轻量：只打包了必要的Bin/Lib；
秒级部署：根据镜像的不同，容器的部署大概在毫秒与秒之间（比虚拟机强很多）；
易于移植：一次构建，随处部署；
弹性伸缩：Kubernetes、Swam、Mesos这类开源、方便、好使的容器管理平台有着非常强大的弹性管理能力。
换句话说，使用容器，用户可以将微服务及其所需的各种配置、依赖关系和环境变量很方便的移动到全新的服务器节点上，而无需重新配置环境。
在容器领域，Docker是最受欢迎的容器格式标准。同时，与Docker配合使用的Kubernetes则成为了容器编排和管理工具中的事实标准。
微服务，改变产品开发方式
微服务是什么？重点在“微”。它的核心是将单个应用程序作为一组小型服务来开发。原来一个产品的开发可能是拆成几个大的模块，然后由几个团队来做，然后再合，微服务的理念是把一个产品拆的更细，可能一个人、几个人负责一个服务的开发，每个服务之间都是独立的。
每个服务都在自己的进程中运行，并使用轻量级机制（通常是基于HTTP的API）进行通信。 这些服务是围绕业务功能构建，可以通过全自动部署机制独立部署，不需要集中管理，可以用不同的编程语言编写，并使用不同的数据存储技术。
所以，微服务核心就是服务粒度要小，每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。但是又不能太小，否则易发生“服务爆炸”。通常在工程实践中，如果一个功能被两个或两个以上的服务调用，就可以被封装为服务。
所以，微服务的优点很明显，小而美、松耦合、灵活、易集成，但是挑战也很明显，最大的问题在于服务如何切分。其实，早在1968年康威就提出了——康威定律，系统的服务划分应该是根据组织架构的功能来划分。这一点用在微服务领域也非常合适。
这样按照组织架构划分的优势在于：
1.内聚更强，所有遵循同一种业务准则的人内聚在一起，就容易解决问题。
2.服务解耦，变更容易，更加敏捷。
DevOps，内部协作更紧密
DevOps，如果从字面上来理解，是Dev（开发）+Ops（运维）。
实际上，可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
为什么要整合？因为能帮助企业提升效率。
众所周知，传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。
每个部门需求都不同，怎么调和？DevOps的价值就体现在这。DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。其最大的价值在于，透过自动化“软件交付”和“架构变更”的流程，能使得构建、测试、发布软件更加地快捷、频繁和可靠，这是每一个企业都期望的。
因此，更深层次的理解，DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动。
持续交付，云原生终极目标
如何理解持续交付？听着比容器、微服务、DevOps更抽象。简单来说，它是一种状态，一种能力，就像生产线能持续交付产品一样。
具体而言，持续交付是一种软件工程手法，它能让软件产品的产出过程在一个短周期内完成，保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
为什么要有持续交付？这是和曾经的软件开发方式相比的，过去的软件开发周期以月、季度、年来计算，今天呢？一个应用晚上线一个小时造成的损失都可能是巨大的，所以要小步快跑、快速迭代，这就是持续交付的价值所在，不断的交付，不断的修正。
很显然，如果把云原生的四要素串联起来，持续交付才是最终目标。但要实现持续交付，容器、微服务、DevOps缺一不可。
总结一下，云时代必须以全新的理念来看待软件架构和基础设施，只有从这个角度理解云原生才能得到正确的答案。未来必然是属于云原生的，所以，企业变革的绝不仅仅是工具，而是从思想到方法，再到工具的一整套理念。只有这样，才能更好迎接云时代的到来。
免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与 无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
