1.1.1　云原生的概念

既然说到了云原生（计算），那么哪些计算方式不是云原生（计算）呢？要回答这个问题，同时辨析云原生的概念，我们需要先回顾云计算的发展历史，以及与之密切相关的分布式计算的复杂性问题。

云计算的概念最先由戴尔公司于1996年提出。2006年，亚马逊公司率先推出了弹性计算云（Elastic Compute Cloud，EC2）服务，随后越来越多的企业开始逐步接受云计算这一概念，并将应用逐步迁移到云端，享受这一新型计算方式带来的技术红利。2009年，阿里巴巴率先开始研制具有完全自主知识产权的云产品——飞天操作系统，由此揭开了中国云计算的序幕。

纵观软件架构的演化历史可以发现，任何新的底层软硬件技术出现后，上层应用软件都需要很长一段时间才能够真正“认识”到新的软硬件给上层应用软件带来的价值，并开发新的软件架构，以便充分利用新软硬件的能力。最典型的例子就是x86 CPU和服务器在面世二十多年后，以CORBA、EJB、RPC、瘦客户端等为主的多层架构才逐步成为应用开发的主流架构。类似的还有容器技术，它最早是由FreeBSD于2000年在Jails中提出的，但真正得到大规模应用是在2013年Docker兴起之后，而应用层的代表则是几年之后基于容器的微服务架构。

对于云计算这一新基础设施来说，也是如此。在2015年之前，对于大多数应用来说，云端只是一个用于计算的场所，开发人员所要做的就是将原来在私有数据中心或IDC中的应用，迁移到云端。在迁移的过程中，应用无须重新编写，只需要重新部署，因为云平台提供的计算、存储、网络等，完全兼容应用迁移之前的计算环境。在迁移模式中，应用通常会将原来的物理机部署模式改成虚拟机（规格更小）部署模式；存储则选用兼容的块存储或者文件存储；网络使用SLB（Server Load Balancer，服务器负载均衡）替换传统的负载均衡器，构建VPC（Virtual Private Cloud，虚拟私有云）或NAT（Network Address Translation，网络地址转换）网络环境；使用云数据库替换原来的MySQL或SQL Server，或者自行在云上搭建Oracle数据库。迁移之后，应用的整体成本（Total Cost of Ownership，TCO）因为采用了“按量付费”的模式而大幅下降，同时，企业的IT支出从CapEx（Capital Expenditure，资本性支出）模式转变为OpEx（Operating Expense，管理支出）模式，整个IT支出变得更可控。

如果对迁移过程进行技术分析，就会发现大部分应用使用的技术或者产品都在进行“一对一”的替换，只有极少量应用会基于OSS（对象存储服务）、MaxCompute（大数据计算服务）等云服务进行部分重构。OSS能够帮助解决分布式状态的存储问题，而MaxCompute能够解决数据仓库的快速搭建和成本问题。但由于没有或者只进行了少量重构，因此应用的技术栈本身几乎没有发生变化，也就是说，软件的架构没有发生变化，只是软件运行的平台和运维的技术体系发生了变化，即只有平台层面的变化。而软件在分布式场景下需要解决的问题，包括稳定性、组件或服务之间的数据同步、整体的高可用或容灾、CI/CD过程的自动化、资源利用率不高、端到端链路跟踪等，仍然需要应用自行解决。这些问题并不会因为应用迁移到了云平台就从根本上得到了解决。当然，各云平台为了帮助应用解决上述分布式复杂性问题，不断推出各类云服务，但是由于应用架构本身并没有发生变化，因此这些云服务并不能帮助应用解决整体问题，只能从局部提升应用的效率。

面对大量的业务需求和场景迭代，很多云平台都提供非常专业的垂直领域服务，这些服务比企业基于开源自行搭建的系统具备更高的SLA（Service Level Agreement，服务等级协议）。比如，在数据持久性方面，亚马逊AWS的数据持久性可以达到99.9…%（11个9），阿里云OSS的数据持久性甚至达到了99.9…%（12个9）；在跨可用区的高可用方面，阿里云RocketMQ的高可用达到了99.95%，即使整个机房不可用也能继续对外提供消息服务。如果不是应用的所有存储访问代码都在S3或OSS上重构，那么“木桶效应”就会凸显，即整个系统的数据持久性将取决于能力最差的组件；如果应用不是将所有自持的开源组件都迁移到云平台上，那么当一个机房出现故障时，应用仍然会出现高可用性的问题；如果应用不是基于FaaS（Function as a Service，功能即服务）技术开发的，那么应用仍然需要自行解决单个组件不可用时的Fail Over（失效转移）以及故障恢复时的Fail Back（失效后自动恢复）等问题。

可见，应用迁移到云上并不代表从此以后就高枕无忧了，如果应用本身没有基于“新”的云服务进行重构，而是继续采用“老”的架构，那么即使业务运行没有问题，应用也不能充分利用“新”的云运行环境的能力。因为这些架构是为了“老”的分布式运行环境而设计的，不是“云原生的”，所以需要对这些架构以及围绕这些架构建立的技术栈、工具链、交付体系进行升级，依托于云技术栈将其重新部署、部分重构甚至全部重写，才能将应用变成“云原生的”，从而保证能够充分利用云计算的能力。

为了让应用能够更好地使用云的PaaS平台能力开发SaaS（Software as a Service，软件即服务），Heroku于2011年提出了十二因子应用的概念。十二因子应用适用于任何编程语言，通常被认为是最早的云原生应用的技术特征，详情请参考http://12factor.net/zh_cn/。

之后，Pivotal于2015年明确地提出了云原生的概念，指出云原生是一种可以充分利用云计算优势构建和运行应用的方式。

在经过CNCF的修改后，最新版云原生的定义为：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。”[1]

上面三个主流的定义，分别从顶层架构原则、计算模型和代表技术的角度，对云原生进行了描述。这些定义的共同点是它们都将云原生看作一种新的计算方式，让应用能够充分使用云的计算优势。进一步分析这些定义所体现出的技术观点，我们可以达成这样一个共识：只有结合云原生所提供的云服务，改造应用的架构，才能够更好地使用云原生技术，更好地构建弹性、稳定、松耦合的分布式应用，并解决分布式复杂性问题。此外，对架构的改造还意味着相关的开发模式、交付方式、运维方式等都要随之改变，比如，采用微服务架构重写应用，用声明式API和自动化工具升级运维方式，等等。简单来说，云原生使得整个软件的生产流水线都发生了巨大的变化，而具体的变化程度又取决于企业对云原生的使用情况。

实际上，云原生的范围还不止于此。要正确实施云原生这一新计算模式，还需要企业的IT决策者、架构师、开发人员与运维人员正确理解和应用云原生的理念，利用合适的云原生技术及产品。有太多的反例可以证明，仅靠单边的技术升级是很难让云原生升级产生价值的。云原生相关概念之间的关系如图1-1所示。

图1-1　云原生相关概念之间的关系

在图1-1中，现代化应用在不少场合与云原生应用的概念是等同的，因为它们的很多特征都是相似的，比如，都采用了容器技术打包和交付，都具备很强的弹性能力等。这两个概念的细微差别在于：现代化应用可以与云相关，也可以与云不相关；而云原生应用通常都与云相关。

所以云原生（或者说云原生计算）应当包括云原生技术、云原生产品、云原生架构以及构建现代化应用的开发理念，如DevOps，具体说明如下。

1）云原生产品和云原生技术需要基于公有云、私有云或混合云的云基础设施（IaaS）。

2）云原生架构和云原生开发理念是基于云原生技术和产品构建或实现的。注意，对于不是基于云原生技术或者产品的架构和理念，如基于传统物理服务器发布、构建的DevOps，是不会被划分到云原生范畴的。

3）现代化应用和云原生应用是基于云原生的架构和开发理念构建或实现的。

[1] 参考来源为https://github.com/cncf/toc/blob/master/DEFINITION.md。