理解了云原生，才能正确迎接云时代的到来

在探讨过无服务器技术《沉寂多年，无服务器爆发，其硬核是什么？丨技术前沿》和裸金属技术《将来将是容器和裸金属的天下，这话有道理吗？| 技术前沿》的发展后，本篇咱们讨论云原生（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缺一不可。

总结一下，云时代必须以全新的理念来看待软件架构和基础设施，只有从这个角度理解云原生才能获得正确的答案。将来必然是属于云原生的，因此，企业变革的毫不仅仅是工具，而是从思想到方法，再到工具的一整套理念。只有这样，才能更好迎接云时代的到来。

本文由百度开发者中心发布，一个面向开发者的知识分享平台,专一于为开发者打造一个有温度的技术交流社区,开发者经过平台来分享知识、相互交流。 developer 发布！