万字长文揭穿你，根本就不懂云原生！

随着云计算技术的发展，企业上云已成为趋势，越来越多的企业都已将应用部署到了云上。但是应用上云并不意味着就能充分利用云平台的优势。目前，大部分云化的应用，都是基于传统的软件架构来搭建的，然后再移植到云上去运行，和云平台的整合度非常低，主要表现在以下几个方面：

传统应用程序和底层操作系统、硬件、存储和后备服务之间存在紧密的依赖关系，这些依赖关系使得应用程序在跨越云基础设施进行迁移和扩展时非常复杂且有风险。

传统的企业应用多采用单体架构，将许多不同的功能模块捆绑在一个部署包中，导致功能模块之间产生不必要的依赖，并导致开发和部署过程中丧失敏捷性，无法独立的部署、发布更新、重启。

通过手工管理基础设施，包括手工编写管理服务器、网络和存储的配置脚本。在大规模复杂的操作中，操作人员在诊断问题时会很慢，而且无法大规模地实施。手工制作的自动化脚本还有可能将人为错误硬编码到基础设施中。

基于虚拟机的基础设施相对于基于微服务的应用程序来说，是缓慢而低效的。因为单个虚拟机启动/关闭的速度很慢，并且在部署应用程序代码之前就会带来巨大的开销。

传统应用的开发模式，IT团队定期发布软件，通常间隔几周或几个月。尽管发布的许多组件已经提前准备好了，并且没有依赖关系，也必须等待版本中的其他组件。客户想要的功能被延迟，企业失去赢得客户和增加收入的机会。

总体来说，提供方便的基础设施，只是对云计算最初级的利用（提升利用率，按需使用，不够了随时扩容），无法充分发挥云计算的优势，要想充分发挥云计算的优势（弹性、高可用性、易扩展性），就必须进行真正的云化，不仅仅是基础设施和平台的变化，应用也需要做出改变，这就需要摈弃传统的方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点重新设计，从而建设全新的云化的应用，也就是云原生的应用。

关于什么是云原生，不同的人定义不同，目前比较权威的定义主要来自Pivotal公司和云原生计算基金会（Cloud Native Computing Foundation，简称CNCF）。

Pivotal公司是云原生应用的提出者，并推出了Cloud Foundry和Spring系列开发框架。早在2015年，Pivotal公司的Matt Stine写了一本名为《迁移到云原生应用架构》的小册子，其中探讨了云原生应用架构的几个主要特征：符合12因素的应用、面向微服务架构、自服务敏捷架构、基于API的协作以及抗脆弱性。

在2017年10月，接受采访时，Matt Stine对云原生的定义做了小幅调整，将云原生架构定义为具有以下六个特质：模块化（Modularity）、可观测性（Observability）、可部署性（Deployability）、可测试性（Testability）、可处理性（Disposability）以及可替换性（Replaceability）。而Pivotal官网对云原生概括为4个要点：DevOps、持续交付、微服务以及容器化。

Matt Stine认为云原生是一个思想的集合，云原生既包含技术（微服务，敏捷基础设施），也包含管理（DevOps、持续交付、康威定律以及重组等），云原生也可以说是一系列云技术、企业管理方法的集合。

CNCF是在2015年由Google联合Linux基金会成立的，它是一个非盈利组织，主要宗旨是统一云计算接口和相关标准，通过技术优势和用户价值创造一套新的通用容器技术，推动云计算和服务的发展。起初CNCF对云原生（Cloud Native）的定义包含以下三个方面：

到了2018年，随着云原生生态的不断壮大，所有主流云计算供应商都加入了该基金会，且从云原生的全景图中可以看出云原生正在蚕食原先非云原生应用的部分。

CNCF基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF为云原生进行了重新定位，并于2018年6月11日明确了云原生定义1.0版本：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

依据CNCF发布的云原生1.0版本的定义，云原生技术主要包括容器、微服务、服务网格、不可变基础设施以及声明式API，下面就这几类技术做个概述：

容器技术和云原生好比一对螺旋体，容器技术催生了云原生思潮，云原生生态推动了容器技术发展。从2013年Docker技术诞生，到2015年CNCF这个云原生领域重量级联盟成立，这不是历史的巧合而是历史的必然。作为云原生关键技术之一的容器，从2013年诞生以来一直是行业关注的焦点之一。

2013年之前，云计算行业一直在为云原生的正确打开姿势而操心。Platform as a Service（PaaS）看起来是个有前途的方向。2006年Fotango公司发布的Zimi服务，可以说是PaaS行业的鼻祖，具有按使用付费、免运维（Serverless）、API化配置和服务等典型云原生的特征；2008年Google推出Google App Engine（GAE）；2011年Pivotal发布Cloud Foundry。

这些早期的PaaS平台在云原生领域进行了非常有益的探索，推动了云原生生态的健康发展，但是这些早期探索技术并没有形成大的行业趋势，而是局限在一些的特定的领域。直到Docker开源，大家才如梦方醒，原来不是方向不对，而是应用分发和交付的手段不行。

Docker真正核心的创新是容器镜像（docker image），一种新型的应用打包、分发和运行机制。容器镜像将应用运行环境，包括代码、依赖库、工具、资源文件和元信息等，打包成一种操作系统发行版无关的不可变更软件包。

容器镜像打包了整个容器运行依赖的环境，以避免依赖运行容器的服务器的操作系统，从而实现“build once， run anywhere”。容器镜像一旦构建完成，就变成read only，成为不可变基础设施的一份子。

微服务架构是相对于单体架构来说的，两者分属不同的架构风格。在微服务架构中，服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能，服务的API封装了其内部实现，与单体架构不同，开发人员无法绕过服务的API直接访问服务内部的方法和数据，因此，微服务架构强制实现了应用程序的模块化。

微服务架构的最核心特性是服务之间的松耦合性。服务之间的交互采用API完成，这样做就封装了服务的实现细节，从而实现了在不影响客户端的情况下，对实现方式做出修改。

微服务架构通过将大的系统按照业务服务的粒度进行拆分，每个服务可独立开发、测试、验证和部署，这样分解后，带来的好处有如下几点：

服务网格是用于处理服务间通信的专用基础设施层，负责在微服务间进行可靠地请求传递。服务网格通常通过一组轻量级网络代理来实现，这些代理与应用程序代码一起部署，而不需要感知应用程序本身。

随着规模和复杂性的增长，服务网格包含的实现的功能越来越多，它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。其部署结构如下图所示：

服务网格有如下几个特点：

如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的TCP/IP，负责服务之间的网络访问、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层（比如通过HTTP协议的RESTful应用），同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如Spring Cloud、OSS，现在只要交给服务网格就可以了，从而极大地方便了微服务应用的开发。

一个工作负载（比如容器、虚拟机等）一旦部署以后就不会被修改。当需要更新，修复或修改某些内容的时候，只需要将新的、经过验证的工作负载替换旧的即可。

不可变基础设施的作用主要体现在系统的稳定性方面。传统的应用程序一旦部署到用户特定的服务器上以后，服务器系统是会不断变化的，不是操作系统升级，就是安装了新的应用，可能引起冲突，导致应用程序需要跟着用户系统环境的改变而不断升级，这中间就会不断地出现新的问题。而不可变基础设施就规避了所有的这些问题，因为云原生应用是部署在不可变的基础设施上的，因此就不存在变化的问题。

声明式API是一种比命令式API更高级的接口设计方式，简单来说，命令式API提供给用户怎么做的能力，而声明式API给用户提供了做什么的能力。

声明式API是比命令式API更高级的一种接口，举个例子，假如我们有一个炒菜机，如果炒菜机提供的接口是放油、放调料、放食材、大火、小火等操作，那就是命令式API。

如果炒菜机提供的接口是来盘宫保鸡丁、来盘鱼香肉丝之类的，那就是声明式API了。声明式API比较典型的例子就是数据库提供的SQL接口，只需要告诉数据库你需要什么数据即可，至于怎么去获取这些数据，数据库自己会去按步骤操作。

传统的软件开发模式，在使用云计算平台时和使用物理机时没有什么大的区别，那么就没有将云平台的能力利用充分，在一定程度上导致了资源的浪费。云原生就是用来解决这一类的问题，将云计算平台的优势发挥到极致。

让企业应用能够利用云平台实现资源的按需分配和弹性伸缩，是云原生应用重点关注的地方。它要求云原生应用具备可用性和伸缩性，以及自动化部署和管理能力，可随处运行，并且能够通过持续集成、持续交付提升研发、测试与发布的效率。云原生应用并未完全颠覆传统的应用，采用云原生的设计模式可以优化和改进传统应用模式，使应用更加适合在云平台上运行。

云原生存在的意义是解放开发和运维，而不是让开发和运维的工作变得更加复杂和繁重。云原生还关注规模，分布式系统应该具备将节点进行水平扩展的能力，能轻易地扩展到成千上万的规模，并且这些节点具备多租户和自愈能力。云原生使得应用本身具备“柔性”，即面对强大压力的缓解能力以及压力过后的恢复能力。

作为云原生领域最具权威的组织，CNCF在每年的年度报告中都会提及CNCF Landscape项目，该项目开始于2016年11月，旨在为云原生应用者提供一个资源地图，帮助企业和开发人员快速了解云原生体系的全貌。CNCF Landscape项目在Github上已经获得超过7000颗星，表明广大开发者和使用者对该项目的关注和重视。该项目给出当前云原生生态的全景图（如下图所示），通过该全景图我们可以了解云原生相关的各种类型的项目和产品：

这张全景图从云原生的层次结构，以及不同的功能组成上，展现了云原生体系的全貌，可以帮助用户在不同组件层次去选择恰当的软件和工具进行支持。总体来看，云原生生态分为以下几层：

图中最底层是Kubernetes认证的服务提供商，以及Kubernetes认证的培训伙伴。

有了物理机或虚拟机后，在运行容器化服务之前，需要为容器准备标准化的基础环境，这就是Provisioning这一层的作用。在Provisioning这一层中，分为以下几个功能组成模块：

Runtime这一层可以理解为容器的整个运行环境，是云原生中最核心的部分，它包括了计算、存储、网络三大块：