云原生架构总览，发展定义架构及趋势

随着云计算发展的成熟和企业需求的推动，云原生技术和理念得到了用户的广泛接受，云原生应用场景不断丰富，云原生正在成为云上的必然趋势。

文章目录

一、云原生技术发展
二、云原生的定义
三、云原生应用
四、云原生架构原则及常用模式
五、云原生未来发展趋势

一、云原生技术发展

• 2001年，VMware发布了第一个针对x86服务器的虚拟化产品ESX和GSX，即ESX-i的前身。
• 2006年10月，以色列的创业公司Qumranet在完成了虚拟化Hypervisor基本功能、动态迁移以及主要的性能优化之后，正式对外宣布了KVM的诞生。2009年4月，
VMware推出业界首款云操作系统VMware vSphere。
• 2006年，AWS推出首批云产品Simple Storage Service (S3)和Elastic Compute Cloud（EC2），使企业可以利用AWS的基础设施构建自己的应用程序。
• 2010年7月，Rackspace Hosting和NASA联合推出了一项名为OpenStack的开源云软件计划。
• 2011年，Pivotal推出了开源版PaaS Cloud Foundry，作为Heroku PaaS的开源替代品，并于2014年底推出了Cloud Foundry Foundation。
• 2008年，LXC（Linux Container）容器发布，这是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。LXC是Docker最初使用的具体内核功能实现。
• 2013年，Docker发布，组合LXC，Union File System和cgroups等Linux技术创建容器化标准，docker风靡一时，container逐步替代VM，云计算进入容器时代。
• 2015年7月，Google联合Linux基金会成立了CNCF组织，kubernetes成为CNCF 管理的首个开源项目。
• 2018年3月，Kubernetes从CNCF毕业，成为CNCF第一个毕业项目。

据《中国云原生用户调查报告2020》显示，2019年中国云原生市场规模约为350.2亿元，云原生技术加速向垂直行业渗透。

数据显示，43.9%的用户已在生产环境中采纳容器技术，超过七成的用户已经或计划使用微服务架构进行业务开发部署。现阶段已有9%的用户云原生相关投入已占总IT投入的一半以上，技术研发、运维是企业主要支出部分。

二、云原生的定义

1、Pivotal早期观点
①Pivotal公司的Matt Stine 于2013年首次提出云原生的概念，并推出了Pivotal Cloud Foundry和Spring系列开发框架，是云原生的探路者。
②2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》——书中定义了符合云原生架构的几个特征：

符合12因素应用(12 Factors Application)
面向微服务架构(Microservices)
自服务敏捷集成设施(Self Service Agile Infrastructure)
基于API的协作(API-Based Collaboration)
抗脆弱性(Antifragility)

2、Pivotal当前论述

云原生是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势;
云原生关注如何创建和部署应用程序，而不是在何处;
虽然现在公有云影响了几乎每个行业的基础设施投资思想，但类似云的交付模式并不仅限于公有云环境，它适用于公有云和私有云;
云原生结合了DevOps、持续交付、微服务和容器的概念;
当公司以云原生方式构建和运营应用程序时，它们可以更快地将新想法推向市场并更快地响应客户需求;

3、CNCF早期观点
①云原生计算基金会(以下简称CNCF)是一个开源软件基金会，成立于2015年7月，致力于云原生(Cloud Native)技术的普及和可持续发展。
②起初，CNCF对云原生的定义包含以下三个方面：

应用容器化(Software stack to be Containerized)
口面向微服务架构(Microservices Oriented)
应用支持容器的编排调度(Dynamically Orchestrated)

③到2018年，随着社区对云原生理念的广泛认可和云原生生态的不断扩大，还有CNCF项目和会员的大量增加，起初的定义已经不再适用。

4、CNCF当前定义
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

5、云原生理念
①利用容器和服务网格等技术，解耦软件开发，提高了业务开发部署的灵活性和
易维护性。
②以Kubernetes为核心的多层次、丰富的开源软件栈，被各大厂商支持，用户选
择多，避免厂商绑定。
③以Kubernetes为核心的松耦合平台架构，易扩展，避免侵入式定制 Kubernetes
已被公认是platform for platform。
③中心式编排，对应用和微服务进行统一的动态管理和调度，提高工作效率和资
源利用率。

6、云原生技术版图

7、容器技术——提高应用可移植性，提升业务敏捷
①容器可以将应用本身及其依赖打包，使得应用可以实现“一次封装，到处运行”。
②容器也可以理解成-种沙盒技术，沙盒在计算机安全领域中是-种安全机制，为运
行中的程序提供的隔离环境。

主流的容器技术，如Docker，它是通过内核虚拟化技术（namespace以及cgroups
等）来提供容器的资源隔离与安全保障。由于Docker通过操作系统层的虚拟化实现隔离，所以Docker容器在运行时，不需要类似虚拟机额外的操作系统开销，提高资源利用率。同时，Docker能够帮助你快速地测试、快速地编码、快速地交付，并且缩短从编码到运行应用的周期，从而使得企业实现业务敏捷。

8、微服务——加速企业应用架构升级
在CNCF的定义中，微服务也是作为一种代表性的技术，而实际上，微服务更侧重于描述软件架构，这种软件架构相比单体架构，更加能够发挥云原生相关的技术优势。

微服务是一种用于构建应用的架构方案，它是松散耦合的分布式架构框架，因此一个团队的更改不会破坏整个应用。使用微服务的好处是，开发团队能够快速构建应用的新组件，以满足不断变化的业务需求。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。比如你在线购物时，使用搜索栏来找产品，这个搜索功能就是一项服务，同时你也看到了相关产品推荐，这些推荐也是来自于另外一项服务，还有购物车等，都是一项一项的服务。

9、DevOps——促进开发运维一体化

DevOps=开发（Development）+运维（Operations），是打通开发与运维之间的壁
垒，促进开发、运营和质量保障（QA）等部门之间的沟通协作，以便对产品进行小
规模、快速迭代式地开发和部署，快速响应客户的需求变化。它强调的是开发运维一体化，加强团队间的沟通和快速反馈，达到快速交付产品和提高交付质量的目的。

10、云原生能力已获广泛认可，加速企业向‘新云原生企业”转型

从技术维度来看，容器在性能、弹性伸缩方面得到广泛认可，容器和微服务对应用现代化、改进DevOps运作模式都取得广泛认可，另外云原生技术提高架构开放性，更符合市场技术趋势，在业务价值方面，微服务的平台化复用提升创新敏捷性得到86%调研人员认可，容器化可以提升资产利用率降本增效、更好的弹性伸缩，容器标准镜像封装和CI/CD结合可以更快交付应用，云原生技术对人工智能、大数据等新兴技术框架的支撑，加速业务创新都得到80%以上用户认可。总体上来说云原生应用价值已获得调研用户广泛认可，以应用为中心的云原生模式正在加速企业数字化进程，加速企业向“新云原生企业”转型。

三、云原生应用

“云原生应用程序是专为云模型构建的。这些应用程序由小型专用功能团队快速构建和部署到一个平台，可提供轻松的横向扩展和硬件解耦-为组织提供跨云环境的更高灵活性，弹性和可移植性。”——Pivotal

“云原生应用是独立的小规模松散耦合服务的集合，旨在提供备受认可的业务价值，例如快速融合用户反馈以实现持续改进。简而言之，通过云原生应用开发，可以加速构建新应用，优化现有应用并将这些应用全部组合在一起。其目标是以企业需要的速度满足应用用户的需求。”——RedHat

云原生应用综合理解：
①基于云原生的相关技术，设计运行在云上的，充分发挥云优势的应用。
②一般采用容器的打包、分发、部署的形式，应用内(间)采用微服务的架构，充分利用云提供的组件服务，采用DevOps的组织架构和方法，通过CI/CD工具链，实现产品和服务的持续交付。

传统应用与云原生应用的区别：

云原生应用12要素：

第一，基准代码。一份代码库对应多份部署，所有部署的基准代码相同，但每份部署可以使用不同的版本。
第二，依赖。显式声明依赖关系，通过依赖清单确切的声明所有依赖项，这一做法会统一应用到生产和开发环境。
第三，配置。
在环境中存储配置，推荐将应用的配置存储于环境变量中，环境变量可以非常方便地在不同的部署间做修改，却不动一行代码。与配置文件不同，不小心把它们迁入代码库的概率微乎其微，与一些传统的解决配置问题的机制，比如Java的属性配置文件相比，环境变量、语言和统计无关。
第四，后端服务。把后端服务当作附加资源，每个不同的后端服务是一份资源，例如一个mysql数据库是一个资源，两个mysql数据库被当做两个不同的资源，云原生应用将这些数据库都视作附加资源，这些资源和他们附属的部署保持松耦合。
第五，构建发布运行云原生应用，需严格区分构建、发布、运行这三个步骤。举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。
第六，进程。以一个或多个无状态进程运行应用，在运行环境中，应用程序通常是以一个或多个进程运行的。
第七，端口绑定。通过端口绑定来提供服务。
第八，并发。通过进程模型进行扩展，在 12-factor 应用中，进程是一等公民。12-Factor应用的进程主要借鉴于unix守护进程模型。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型。例如，HTTP请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。
第九，易处理。快速启动和优雅终止和最大化健壮性，这有利于快速弹性的伸缩应用、迅速部署变化的代码或配置文件的部署应用。
第十，开发环境与线上环境等价，尽可能的保持开发预发布线上环境相同。
第十一，日志。把日志当做事件流，日志应该是事件流的汇总，将所有运行中的进程和后端服务的输出流，按照时间顺序收集起来。
第十二，管理进程。后台管理任务当做一次性进程运行，一次性管理进程应该和正常的常驻进程使用同样的环境，这些管理进程和任何其他的进程一样，使用相同的代码和配置，基于某个发布版本运行，后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。

四、云原生架构原则及常用模式

弹性：微服务采用无状态设计，支持按需使用、自动水平伸缩；实例快速启动，并在不影响业务的前提下优雅中止。这一点可以充分利用云的弹性的特征，利用云环境提供的镜像、监控、资源动态编排和调度服务。设计应用程序时，不绑定特定基础资源，使其能够自由伸展，根据需要增删实例。

分布式：更多强调解耦。应用侧，则是业务逻辑和数据解耦、业务逻辑和会话解耦。数据分布式，每个服务拥有自己的数据库，服务不能直接访问其他服务的数据库，只能通过服务接口访问其他服务的数据。

高可用，高可用的概念范畴比较广，云原生应用的设计特征，Design For Failure，即“为失败而设计”，这里主要强调基于不可靠的基础设施资源来设计高可用系统，并且在应用实例失效的情况下，系统能快速发现并恢复。高可用的设计的主要原则有可观测、可灰度、可回滚等。实现的方式有很多种，比如，通过k8s实现POD状态的监测和维护，通过灰度发布、蓝绿部署等手段来保证升级、回滚时系统的高可用。

自动化：业务/服务的颗粒度更小，交付部署更频繁，迫切需要系统能够自动化部署，同时要增强对服务以及所部署的软硬件环境的全方位监控、评估能力。

自服务：自服务强调服务可被其他应用或开发者自助发现，自助按需获取，自助使用并计量，自助服务管理。自服务的前提是高度自治，同时，从易用性的角度，暴露友好的交互方式（Web界面、命令行、SDK…），使能应用开发者简单、高效地使用其提供的功能。

1、云原生架构模式：微服务架构

微服务架构就是其中一种实现方式。它实现了服务彻底拆分，各服务可以独立打包、独立部署和独立升级，对开发者而言，摆脱开发语言的束缚。每个微服务负责的业务比较清晰，利于后期扩展和维护。微服务之间可以采用REST和RPC协议进行通信。同时，微服务架构可以和其他云原生技术完美结合，充分发挥云的优势。

2、云原生架构模式：Serverless架构
Serverless (无服务器架构)指的是由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发，完全被第三方管理，Serverless是在传统容器技术和服务网格上发展起来，更侧重让使用者只关注自己的业务逻辑即可。

3、Serverless与微服务的关系：微服务向Serverless演进，并长期共存

Serverless与微服务同属服务化架构，二者在架构特征上有很多相似之处，比如：都追求基础设施的高可用、高容错，应用的快速弹性，快速发布，更好的运维可观测性等。但作为新一代应用架构，Serverless化的变化在于：更快的弹性（毫秒级）、更快的发布（分钟级）、更简化的运维（NoOps）、更细粒度的资源调度（函数级，可以是几十行）。

五、云原生未来发展趋势

①Kubernetes编排统一化，编排对象不断扩展延伸

Kubernetes 的编排对象持续丰富不断扩展，以容器为基础编排对象逐渐延展至虚拟机、函数等，理论上所有可编程、有API、可抽象成资源的对象，都在成为 Kubernetes 的编排对象。
应用侧围绕Kubernetes生态加速演进，以Kubernetes为核心的云原生技术栈将推广到更多的应用场景。在大数据领域，Spark和Kubernetes的集成已经非常普遍；机器学习方面，Kubernetes和Tensorflow等深度学习的框架深度集成，用Kubernetes去编排机器学习的工作流以取得业界的广泛共识。

②服务治理Mesh化，加速传统应用转型

传统应用架构中业务和功能耦合度较高，无法充分发挥云的效能。
传统应用中用于治理服务的中间件服务通常与应用强绑定部署，治理能力被植入每个应用，重复造轮子现象严重。Mesh化加速业务逻辑与非业务逻辑的解耦。将非业务功能从客户端SDK中分离出来放入独立进程，利用Pod中容器共享资源的特性，实现用户无感知的治理接管。
服务治理的 Mesh 化为传统应用轻量化改造提供了前提，也为云平台沉淀通用服务治理能力，加速中间件下沉为基础设施提供了可能

③应用服务Serverless化，更加聚焦业务的核心价值
Serverless将进一步释放云计算的能力，将安全、可靠、可伸缩等需求交由基础设施实现，使用户仅需关注业务逻辑而无需关注具体部署和运行，极大地提高应用开发效率。同时这个方式促进了社会分工协作，云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。

④云原生服务部署形态多元化，多云将成为主流
尽管上云已是大势所趋，但对于企业客户而言，有些业务出于对数据主权、安全隐私的考量，会采用混合云架构。一些企业为了满足安全合规、成本优化、提升地域覆盖性等需求，会选择多个云厂商。