你知道的越多，不知道的就越多，业余的像一棵小草！

成功路上并不拥挤，因为坚持的人不多。

编辑：业余草

blog.csdn.net/gavinchen1985

推荐：https://www.xttblog.com/?p=5233

什么是云原生架构

所谓云原生架构，Cloud Native Computing Foundation 的定义是这样的：

❝

Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

❞

云原生架构的目的是使企业能够在公有云，私有云或者混合云等动态环境中构建和运行可扩展的应用。代表技术包括容器，服务网格，微服务，不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师们能够轻松地对系统作出频繁和可预测的重大变更。

软件架构的目的一般都是帮助开发团队将关注点尽可能聚焦在业务代码的实现上。通常，开发软件系统，代码包含三部分内容，即处理业务逻辑的代码、第三方依赖、处理非功能特性的代码。这三部分中只有业务代码真正产生业务价值，另外两个部分都只算附属物。软件规模越大、非功能特性要求越复杂，非业务代码开发量越大，复杂度越高，系统迭代会越来越缓慢，成本业务越来越高。所以，在软件规模较大、功能复杂的情况下又要保证敏捷迭代，就需要将非业务代码尽可能剥离出来，利用可靠的第三方托管服务来提升开发效率和系统质量。而云平台提供了丰富的用于处理非功能需求的服务和组件，所以利用云原生架构充分利用云平台上的各类资源，可以很好的解决这方面的问题，下面是微软整理应用云原生技术的实际案例：

云原生架构必要条件

所以，云原生架构要解决的问题不是只简单的将应用迁移到云上，而是通过一组架构原则和设计模式，将应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。而为了实现这些，云原生架构应具备如下条件：微服务架构，不可变基础设施和托管服务。

微服务架构

云原生架构的初衷是为了充分利用云平台的技术资源来减轻应用开发非功能业务需求的负担，但同时对应用本身架构的影响也很大。传统的单体应用是无法上面提到的特性的，所以微服务架构是实现云原生应用的必要条件（再说一次，把应用迁移到云平台上的虚拟机里不叫云原生应用）。而成熟度较高的云原生的架构设计要求也更多， 12-Factor 可以作为云原生架构的方法论：

• 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目；

• 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性；

• 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源；

• 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发；

• 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展；

这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。

THE TWELVE-FACTOR APPLICATION

在文章 Beyond the Twelve-Factor App中， Kevin Hoffman 解释了 12 factors (written in 2011). 另外基于现在对于云应用开发的需求又增加了三个要素。

不可变基础设施

云原生架构理想的计算环境是动态的，平台提供的计算资源可以随时快速交付，提升、扩展、迁移或者销毁。并且，整个基础环境变化过程中都是在无人关注的情况下自动实现的。如何实现呢？在DevOps中提出了一个Pets vs. Cattle （宠物和牲口）的概念。

在过去依赖传统的高可靠性基础设施的时代，服务的可靠性依赖于高可靠性的服务器。因此对待服务器就像对待宠物一样，要实时关注服务的状态并精心维护，在系统故障或需要升级的时候需要通过对服务器进行修复、配置实现。但这种模式下，基础设施具有很高的拥有成本，并且初始化，配置的成本也非常高（对于大中型机，甚至重启都是一种奢侈）。

而“牲口”模式下，处理就简单粗暴的多了，如果底层系统故障或者需要升级，直接杀掉然后重新创建一个新的就好了。而云原生架构下底层基础资源采用的就是这种“Cattle”的运维模式，即所谓“「不可变基础设施」”。不可变基础设施里的“不可变”非常类似于程序设计中的“不可变”概念。程序设计中不可变变量（Immutable Variable）就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不再进行更改。这一点是通过容器镜像来实现的，其含义就是应用的基础设施应该是不可变的，是一个自包含、自描述可以完全在不同环境中迁移的东西。

Cloud Native Computing Foundation (CNCF)定义了如下的云原生架构模型。

基础设施层（Infrastructure）代表实际的计算资源，包括物理服务器或者虚拟机。提供层（Provisioning）实现对宿主机的管理，包括安装操作系统等。

运行时层（Runtime）主要包括容器运行时环境，包含容器运行时接口（CRI），例如 Docker。容器网络接口（CNI）和容器存储接口（CSI）。

容器编排和管理层（Container orchestration and management）帮助在多宿主机上实现大量容器化应用的部署。Cloud Foundry, Mesos, Nomad和Kubernetes都是流行的容器编排工具。

在应用定义层（Application Definition）开发者负责实现云原生应用的功能，定义应用架构，配置，部署文件，镜像仓库，持续集成/持续交付等。

托管服务

托管服务（managed service）以服务的形式提供如网络、应用、基础设施以及安全功能，并向用户提供持续的支持和底层运维。托管服务的好处就是开箱即用，省去了用户开发相应功能甚至运维的烦恼，一切交给 MSP（managed service provider）。并且在云平台中，服务的交付都是采用 XaaS，即按需付费的方式，所以计费也很灵活方便。

目前成熟的 PaaS 云平台中，都已经提供了相对完善的托管服务列表，如访问控制、数据库、缓存、权限管理、持续集成等，帮助用户尽可能将非功能实现都外移到 PaaS 或 SaaS 服务中，而更加关注业务代码的实现。

云原生架构成熟度模型

如何判断应用架构是不是云原生架构？可以参考阿里的云原生架构成熟度模型（SESORA）：

综上所述，云原生架构在系统规模较大、功能较复杂的情况下，可以最大化的分离非功能需求代码实现并充分利用云平台提供的各种资源，但相对的架构要求和复杂度也较高，如何选择还需要开发团队和架构师认真权衡。

参考资料

• https://github.com/cncf/foundation/blob/master/charter.md

• https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition

• https://www.infoq.com/articles/cloud-native-architecture/

• https://www.infoq.cn/article/NZUG7uR1kdwhrIQ05HMM

• https://www.infoq.cn/article/2017/11/WHAT-SERVICE-MESH-WHY-NEED

• https://blog.csdn.net/alisystemsoftware/article/details/103370388

• https://www.gartner.com/en/information-technology/glossary/msp-management-service-provider

• http://www.uml.org.cn/yunjisuan/202101071.asp