时间是技术最好的刻度尺！
9年前,Netscape公司创始人马克 安德森说：软件正在改变世界；
6年前，OpenStack创始人说：世界的一切源于开源；
在之后，业界普遍认为云计算已改变填空的颜色；
现在，云原生才是那条最大的鱼。
为什么这么说？我们在说云原生之前，先来简单聊聊原来使用公有云的问题。
我们知道，传统企业使用公有云，特别是运行关键业务负载时，遇到的资源扩展和适配上的限制，对数据安全的顾虑，以及在性能输出上难以避开的虚拟化层的损耗。
尤其是需要频繁升级迭代在线应用和服务的互联网企业，难以在基于虚拟机的基础设施上实现高效DevOps所需的更优灵活度和更细的应用颗粒度，应用的移植也不够方便。
那么，我们最近听得比较多的是，裸金属和容器即服务。那这两种服务究竟有哪些独到优势，可用于解决上述难题呢？
为什么是裸金属和容器呢？
裸金属服务提供商可在其上，为企业用户提供在公有云基础设施上构建其私有云或专属云的服务，来运行那些数据密集型和对数据安全和隐私要求较高的应用，让用户减少在构建和运维自有云平台或数据中心上投注的精力和成本，更专注于业务创新。
容器即服务的优势，则在于“轻量”，其主要特点，如一致性、可移植性、支持微服务、快速启动、便于DevOps等，几乎都是为那些计划导入云原生架构的企业“量身定制”的。
但是这两种技术尤其局限性。
裸金属即服务如果仅从服务器层面实施，还是会受制于其物理机资源的限制，不足以充分释放其潜力。
容器即服务虽然讲究轻量，但也一样需要“重量级”性能平台的加速。
现在云原生来了，就是来解决我们的瓶颈的。
云原生，是一种全新运维模式，其不亚于核弹一样的威力，自打诞生那一该即震惊了整个行业的运维从业人员。
究竟什么是云原生？
不同企业对于云原生有不同的解释，当前在业界具有广泛影响力的云原生计算基金会（Cloud Native Computing Foundation, CNCF）认为: 云原生是一类技术的统称，通过云原生技术，我们可以构建出更易于弹性扩展的应用程序。
这些应用可以被运行在不同的环境当中，比如说私有云、公有云、混合云、还有多云的场景。云原生技术包括：
容器
微服务
服务网格
Serverless
DevOps
API管理
不可变基础架构等
现在通过一张图让你预览一下云原生的架构组成：
通过云原生技术构建出来的应用程序，称之为云原生应用，底层基础架构的耦合比较轻，因此易于迁移，它可以充分地利用云所提供的能力，因此云原生应用的开发、部署、管理相对于传统的应用程序更加高效和便捷。
前面我们其实讲到了容器服务，其实，容器服务就是云原生的前生。因为云原生其实是一种基于容器构建的微服务应用，通过持续交付的方式部署在弹性的云基础设施之上的理念。
在这里，大家就发现了，要了解云原生，就是要了解容器服务，了解微服务，了解持续交付。知道这3个方面，你就基本上明白了云原生是什么了。
首先，我们了解容器服务是什么？
容器：就是我们常说的Docker。标准的解释是：Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。Docker 容器通过 Docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。
你看到这个解释也很难理解什么叫容器。
那我先告诉你容器的典型场景：
1、使应用的打包与部署自动化；
2、创建轻量、私密的PAAS环境；
3、实现自动化测试和持续的集成/部署；
4、部署与扩展webapp、数据库和后台服务。
一句话说就是这4个方面没有容器之前，我们的工作非常繁琐，现在变得简单而自动化。
如果用一个比喻来告诉你什么是容器，我会这么说：
我们现在很多人是理解虚拟机的，其实Docker容器与虚拟机类似，但二者在原理上不同。容器是将操作系统层虚拟化，虚拟机则是虚拟化硬件，因此容器更具有便携性、高效地利用服务器。
英文单词docker的中文翻译是码头工人（名词）。所以，你可以把容器理解为在操作系统这个环境中虚拟出很多个隔离互不影响的空间来安装部署你要的服务。
虽然云原生架构没有硬性规则，但大多数云原生应用程序都是由微服务组织而成。微服务主要用于将应用程序分解为可由小型团队维护的自治、松散耦合的单元，每个微服务通常部署为一个容器或一组容器。
所以，微服务其实很好理解，就是将你原来的一个大程序分解成很多个小程序，再安装到很多个容器中运行，比方说聊天的一个容器，文档服务器一个容器，邮件一个容器，web服务一个容器，数据库一个容器，等等。
最后来说持续交付这个事情。
讲这个事情，还得熟悉一个工具就是DevOps。
什么是DevOps呢？
DevOps包含development和operations，是开发和运营维护的总称。软件设计过程中，应对开发部门、运维部门进行协调，确保各项工作流程与方法高效使用，为项目管理工作提供可靠参考。
按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。所以，DevOps不光是方便IT软件部署，更加是工作流程的优化和整合，使得工作更加高效，并且是跟云原生模式匹配的。
DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。
那么，持续交付跟DevOps有什么关系呢？
说白了，持续交付是一种工作方法。就是让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。而这个工作当中，DevOps就是一个可以执行的方法和工具，帮助IT持续交付。
持续交付与DevOps的含义很相似，所以经常被混淆。但是它们是不同的两个概念。DevOps的范围更广，它以文化变迁为中心，特别是软件交付过程所涉及的多个团队之间的合作（开发、运维、QA、管理部门等），并且将软件交付的过程自动化。另一方面，持续交付是一种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。因此，DevOps可以是持续交付的一个产物，持续交付直接汇入DevOps。
云原生这么好，我们如何用起来？
其实最关键的是微服务，也就是应用改造，我们之前使用的旧系统，很多是统一集成的，没有按照模块化开发，所以，要想使用云原生，还有一个过程就是应用解耦，模块化开发和改造。
只有实现了这个过程，才能真正把云原生匹配起来！
请登录之后再进行评论