一文简述：云原生应用十二要素

十二要素定义了一个优雅的互联网应用，在设计过程中，需要遵循的一些基本原则和云原生有异曲同工之处。基于十二要素的上下文关联，软件生产就变成一个个单一的部署单元；多个联合部署的单元组成一个应用，多个应用就可以组成一个复杂的分布式应用系统。

云原生应用十二要素

1．基准代码

一份基准代码，多份部署。在类似于 SVN 等集中式版本控制系统中，“基准代码”是指控制系统中的代码仓库；而在 Git 等分布式版本控制系统中，“基准代码”则是指最上游的代码仓库。基准代码和应用之间总是保持如下一一对应的关系。所有部署的基准代码相同，但每份部署可以使用其不同的版本。

2．依赖

显式声明依赖关系。十二要素规则下的应用程序不会隐式依赖系统级的类库，它一定通过“依赖清单”确切地声明所有依赖项。

在容器应用中，应用的依赖、环境的依赖和软件的安装等，都是通过 Dockerfile 来完成声明的，通过配置能明确把依赖关系（包括版本）都图形化地明确展示出来，不存在黑盒。

3．配置

十二要素推荐将应用的配置存储于环境变量（env vars、env）中。环境变量可以非常方便地在不同的部署中做修改，而不改变一行代码。判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。

4．后端服务

把后端服务当作附加资源。后端服务是指程序运行所需的通过网络调用的各种服务，如数据库、消息队列、简单邮件传输协议邮件服务，以及缓存等。十二要素应用不会区别对待本地或第三方服务。对应用程序而言，两种都是附加资源，通过一个统一资源定位器（URL）或其他存储在配置中的服务定位/服务证书来获取数据。

5．构建、发布、运行

十二要素应用严格区分构建、发布、运行 3 个阶段。举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建阶段。部署工具通常提供了发布管理工具，最引人注目的功能是退回至较旧运行稳定的发布版本。在云原生应用中，基于容器的 Build-Ship-Run 和这 3 个阶段完全吻合，也是 Docker 对本原则的最佳实践。

6．进程

以一个或多个无状态进程运行应用。在运行环境中，应用程序通常是以一个和多个进程运行的。十二要素应用的进程必须无状态且无共享。任何需要持久化的数据都要存储在“后端服务”内，如数据库。

7．端口绑定

通过端口绑定（port binding）来提供服务。十二要素应用完全自我加载，不依赖任何网络服务器即可创建一个面向网络的服务。互联网应用通过端口绑定来提供服务，并监听发送至该端口的请求。

在容器应用中，应用统一通过暴露端口来提供服务，尽量避免通过本地文件或进程来通信，每种服务通过服务发现来路由调用。

8．并发

通过进程模型进行扩展，以支持并发。十二要素应用的进程主要借鉴于 Unix 守护进程模型。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。

9．易处理

快速启动和优雅终止可使健壮性最大化。十二要素应用的进程是易处理的，即它们可以瞬间开启或停止。这有利于快速、弹性地伸缩应用，迅速部署变化的代码或配置，稳健地部署应用。

10．环境等价

尽可能地保持开发环境、预发布环境和线上环境相同。十二要素应用想要做到持续部署，就必须缩小本地与线上差异。

• 缩小时间差异：开发人员可以在几小时，甚至几分钟内就部署代码。

• 缩小人员差异：开发人员不仅要编写代码，还应该密切参与部署过程以及关注代码在线上的表现。

• 缩小工具差异：尽量保证开发环境与线上环境的一致性。

11．日志

把日志当作事件流。十二要素应用本身从来不考虑存储自己的输出流，不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接地标准输出（stdout）事件流。在开发环境中，开发人员可以通过这些数据流实时地在终端看到应用的活动。

12．管理进程

后台管理任务当作一次性进程运行。进程构成是指用来处理应用的常规业务（比如处理 Web 请求）的一组进程。与此不同，开发人员经常希望执行一些管理或维护应用的一次性任务。

一次性管理进程应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置，基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。