作者简介
Gavin，程序员、软件架构师、企业架构师，关注智能制造。
本文是专栏《智能制造系统架构》中的文章，其它文章请参阅入坑智能制造系统架构。
什么是云原生架构
所谓云原生架构，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。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师们能够轻松地对系统作出频繁和可预测的重大变更。
软件架构的目的一般都是帮助开发团队将关注点尽可能聚焦在业务代码的实现上。通常，开发软件系统，代码包含三部分内容，即处理业务逻辑的代码、第三方依赖、处理非功能特性的代码。这三部分中只有业务代码真正产生业务价值，另外两个部分都只算附属物。软件规模越大、非功能特性要求越复杂，非业务代码开发量越大，复杂度越高，系统迭代会越来越缓慢，成本业务越来越高。所以，在软件规模较大、功能复杂的情况下又要保证敏捷迭代，就需要将非业务代码尽可能剥离出来，利用可靠的第三方托管服务来提升开发效率和系统质量。而云平台提供了丰富的用于处理非功能需求的服务和组件，所以利用云原生架构充分利用云平台上的各类资源，可以很好的解决这方面的问题，下面是微软整理应用云原生技术的实际案例：
| 公司 | 案例 |
|---|---|
| Netflix | 生产环境中部署 600+个服务。每天部署上百次。 |
| Uber | 生产环境中部署 1000+个服务。每周部署数百次。 |
| 生产环境中部署 3000+个服务。每天部署上千次。 |
云原生架构必要条件
所以，云原生架构要解决的问题不是只简单的将应用迁移到云上，而是通过一组架构原则和设计模式，将应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。而为了实现这些，云原生架构应具备如下条件：微服务架构，不可变基础设施和托管服务。
微服务架构
云原生架构的初衷是为了充分利用云平台的技术资源来减轻应用开发非功能业务需求的负担，但同时对应用本身架构的影响也很大。传统的单体应用是无法上面提到的特性的，所以微服务架构是实现云原生应用的必要条件（再说一次，把应用迁移到云平台上的虚拟机里不叫云原生应用）。而成熟度较高的云原生的架构设计要求也更多，12-Factor 可以作为云原生架构的方法论：
- 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目；
- 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性；
- 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源；
- 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发；
- 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展；
这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。:
| 要素 | 解释 | |
|---|---|---|
| 1 | 基准代码 | 一份基准代码（Codebase），多份部署（deploy）。
|
| 2 | 依赖 | 显式声明依赖关系（ dependency ） 通过依赖清单 ，确切地声明所有依赖项。此外，在运行过程中通过 依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。 |
| 3 | 配置 | 在环境中存储配置 12-Factor推荐将应用的配置存储于 环境变量 中（ env vars, env ）。 |
| 4 | 后端服务 | 把后端服务(backing services)当作附加资源 2-Factor 应用不会区别对待本地或第三方服务。 对应用程序而言，两种都是附加资源，通过一个 url 或是其他存储在配置中的服务定位/服务证书来获取数据。 |
| 5 | 构建，发布，运行 | 严格分离构建和运行 基准代码 转化为一份部署(非开发环境)需要以下三个阶段：
|
| 6 | 进程 | 以一个或多个无状态进程运行应用 12-Factor 应用的进程必须无状态且无共享 。 任何需要持久化的数据都要存储在后端服务内，比如数据库。 |
| 7 | 端口绑定 | 通过端口绑定(Port binding)来提供服务 互联网应用有时会运行于服务器的容器之中。 12-Factor 应用完全自我加载 而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务 ，并监听发送至该端口的请求。 |
| 8 | 并发 | 通过进程模型进行扩展 在 12-factor 应用中，进程是一等公民。12-Factor 应用的进程主要借鉴于 unix 守护进程模型 。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的 进程类型 。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。 |
| 9 | 易处理 | 快速启动和优雅终止可最大化健壮性 12-Factor 应用的进程是易处理（disposable）的，意思是说它们可以瞬间开启或停止。 这有利于快速、弹性的伸缩应用，迅速部署变化的 代码 或 配置 ，稳健的部署应用。 |
| 10 | 开发环境与线上环境等价 | 尽可能的保持开发，预发布，线上环境相同 12-Factor 应用想要做到 持续部署 就必须缩小本地与线上差异。 再回头看上面所描述的三个差异:
|
| 11 | 日志 | 把日志当作事件流 日志应该是事件流的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，日志最原始的格式确实是一个事件一行。日志没有确定开始和结束，但随着应用在运行会持续的增加。 12-factor应用本身从不考虑存储自己的输出流。 不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（stdout）事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。 |
| 12 | 管理进程 | 后台管理任务当作一次性进程运行 一次性管理进程应该和正常的 常驻进程 使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置，基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。所有进程类型应该使用同样的依赖隔离技术。12-factor尤其青睐那些提供了REPL shell的语言，因为那会让运行一次性脚本变得简单。 |
在文章 Beyond the Twelve-Factor App中， Kevin Hoffman 解释了 12 factors (written in 2011). 另外基于现在对于云应用开发的需求又增加了三个要素.
| New Factor | Explanation | |
|---|---|---|
| 13 | API优先 | 万物皆服务。假设你的代码将会被一个前端客户端、网关或者其它服务调用。 |
| 14 | 资源监控 | 确保你的设计包含监控以及领域相关的健康/系统数据。 |
| 15 | 认证/授权 | 从一开始就实现认证。考虑在公有云环境下可用的RBAC (role-based access control,基于角色的访问控制) |
不可变基础设施
云原生架构理想的计算环境是动态的，平台提供的计算资源可以随时快速交付，提升、扩展、迁移或者销毁。并且，整个基础环境变化过程中都是在无人关注的情况下自动实现的。如何实现呢？在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?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&dist_request_id=1328740.26522.16169095587137867&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.control
- https://www.gartner.com/en/information-technology/glossary/msp-management-service-provider
- http://www.uml.org.cn/yunjisuan/202101071.asp