The Twelve-Factory App
Cloud Native是一种应用开发风格，鼓励在持续交付和价值驱动开发领域轻松采用最佳实践。相关的学科是建立12因素应用程序，其中开发实践与交付和运营目标相一致，例如通过使用声明式编程和管理和监控。
软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论：
- 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
- 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
- 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
- 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
- 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。
一、基准代码
一份基准代码（Codebase），多份部署（deploy）
所有部署的基准代码相同，但每份部署可以使用其不同的版本。比如，开发人员可能有一些提交还没有同步至预发布环境；预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码，我们就认为它们只是相同应用的不同部署而已。
二、依赖
显式声明依赖关系（ dependency ）
12-Factor规则下的应用程序不会隐式依赖系统级的类库。 它一定通过 依赖清单 ，确切地声明所有依赖项。此外，在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。
三、 配置
代码和配置严格分离
判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。
12-Factor推荐将应用的配置存储于环境变量中。
四、后端服务
把后端服务(backing services)当作附加资源
12-Factor 应用不会区别对待本地或第三方服务, 对应用程序而言，两种都是附加资源，通过一个ur 或是其他存储在配置中的服务定位/服务证书来获取数据。每个不同的后端服务是一份资源 。例如，一个 MySQL 数据库是一个资源，两个MySQL数据库（用来数据分区）就被当作是 2 个不同的资源。12-Factor 应用将这些数据库都视作附加资源 ，这些资源和它们附属的部署保持松耦合。
部署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 – 整个过程都不需要修改代码。
五、构建，发布，运行
严格分离构建和运行
基准代码 转化为一份部署(非开发环境)需要以下三个阶段：
- 构建阶段: 代码仓库转化为可执行包的过程
- 发布阶段 :将构建的结果和当前部署所需配置相结合.
- 运行阶段: 启动一系列应用程序进程。
六、进程
以一个或多个无状态进程运行应用
12-Factor 应用的进程必须无状态且无共享。 任何需要持久化的数据都要存储在后端服务内， 比如数据库。一些互联网系统依赖于 “粘性session”， 这是指将用户session中的数据缓存至某进程的内存中，并将同一用户的后续请求路由到同一个进程。粘性 session 是 12-Factor 极力反对的。Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间的缓存中。
七、端口绑定
通过端口绑定(Port binding)来提供服务
12-Factor 应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务，并监听发送至该端口的请求。
八、并发
通过进程模型进行扩展
在 12-factor 应用中，进程是一等公民。12-Factor 应用的进程主要借鉴于 unix 守护进程模型。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型 。例如，HTTP 请求可以交给web进程来处理，而常驻的后台工作则交由 worker 进程负责。
12-Factor 应用的进程不需要守护进程或是写入PID文件。相反的，应该借助操作系统的进程管理器(例如 Upstart ，分布式的进程管理云平台，或是类似 Foreman 的工具)，来管理输出流 ，响应崩溃的进程，以及处理用户触发的重启和关闭超级进程的请求。
九、易处理
快速启动和优雅终止可最大化健壮性
- 12-Factor 应用的进程是易处理（disposable）的，意思是说它们可以瞬间开启或停止.
- 进程应当追求最小启动时间
- 进程 一旦接收终止信号（SIGTERM） 就会优雅的终止
- 对于 worker 进程来说，优雅终止是指将当前任务退回队列
- 进程还应当在面对突然死亡时保持健壮
十、开发环境与线上环境等价
尽可能的保持开发，预发布，线上环境相同
十一、日志
把日志当作事件流
日志使得应用程序运行的动作变得透明。在基于服务器的环境中，日志通常被写在硬盘的一个文件里，但这只是一种输出格式。
12-factor应用本身从不考虑存储自己的输出流。不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（stdout）事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。
十二、管理进程
后台管理任务当作一次性进程运行
一次性管理进程应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码 和配置 ，基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。
待续，研读《beyond-the-twelve-factor-app》
参考：