简介

12-Factor 为构建如下的 SaaS 应用提供了方法论：

  • 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
  • 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
  • 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
  • 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
    = 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

1、基准代码

一份基准代码（Codebase），多份部署（deploy）

尽管每个应用只对应一份基准代码，但可以同时存在多份部署。每份 部署 相当于运行了一个应用的实例。

2、依赖

显式声明依赖关系（ dependency ）

显式声明依赖是为新进开发者简化了环境配置流程。新进开发者可以检出应用程序的基准代码，安装编程语言环境和它对应的依赖管理工具，只需通过一个 构建命令 来安装所有的依赖项，即可开始工作。

3、 配置

在环境中存储配置

应用的 配置 在不同 部署 (预发布、生产环境、开发环境等等)间会有很大差异。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码；与配置文件不同，不小心把它们签入代码库的概率微乎其微；与一些传统的解决配置问题的机制（比如 Java 的属性配置文件）相比，环境变量与语言和系统无关。

4、后端服务

把后端服务(backing services)当作附加资源。

后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL，CouchDB），消息/队列系统（RabbitMQ，Beanstalkd），SMTP 邮件发送服务（Postfix），以及缓存系统（Memcached）。

对应用程序而言，通过一个 url 或是其他存储在配置中的服务定位/服务证书来获取数据。12-Factor 应用的任意 部署 ，都应该可以在不进行任何代码改动的情况下，将本地 MySQL 数据库换成第三方服务（例如 Amazon RDS）。

5、 构建，发布，运行

基准代码 转化为一份部署(非开发环境)需要以下三个阶段：

  • 构建阶段 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包 依赖项，编译成二进制文件和资源文件。
  • 发布阶段 会将构建的结果和当前部署所需配置相结合，并能够立刻在运行环境中投入使用。
  • 运行阶段 （或者说“运行时”）是指针对选定的发布版本，在执行环境中启动一系列应用程序进程。

6、进程

以一个或多个无状态进程运行应用

任何需要持久化的数据都要存储在 后端服务 内，比如数据库。Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间的缓存中。

7、端口绑定

通过端口绑定(Port binding)来提供服务

互联网应用 通过端口绑定来提供服务 ，并监听发送至该端口的请求。本地环境中，开发人员通过类似http://localhost:5000/的地址来访问服务。在线上环境中，请求统一发送至公共域名而后路由至绑定了端口的网络进程。

8、并发

通过进程模型进行扩展

将不同的工作分配给不同的 进程类型 。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。

9、易处理

快速启动和优雅终止可最大化健壮性

12-Factor 应用的进程是易处理（disposable）的，意思是说它们可以瞬间开启或停止。 这有利于快速、弹性的伸缩应用，迅速部署变化的 代码 或 配置 ，稳健的部署应用。

进程应当追求 最小启动时间。

进程 一旦接收 终止信号（SIGTERM） 就会优雅的终止 。

10、开发环境与线上环境等价

尽可能的保持开发，预发布，线上环境相同。

12-Factor 应用想要做到 持续部署 就必须缩小本地与线上差异。 再回头看上面所描述的三个差异:

  • 缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。
  • 缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。
  • 缩小工具差异：尽量保证开发环境以及线上环境的一致性。

11、日志

把日志当作事件流

日志应该是 事件流 的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，日志最原始的格式确实是一个事件一行。

12、 管理进程

后台管理任务当作一次性进程运行

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