The Twelve-Factors App 笔记

现如今, 软件通常会作为一种服务来交付, 即SAAS(softwaware-as-a-service). Twelve-Factor 为构建具有如下特征的SAAS提供了方法论:

• 使用标准化的配置流程, 来减少项目组加入新成员所需要的时间.
• 与底层OS 含有明确的契约, 来获得最大的执行环境可移植性.
• 适合部署在云环境中.
• 最小化开发和生产间的差异, 使用持续发布.
• 扩展(scale up) 时的代价尽可能小.

Twelve-Factor 包含以下的条款:

• Codebase.
  • 一个置于版本控制下的代码库, 多份部署(dev,staging,pro).
• Dependency.
  • 明确声明并隔离依赖.
  • 不要隐式地依赖于系统级别的包, 和系统工具(curl).
• Config.
  • 在环境(而非代码)中存储配置.
  • 代码不会随着发布而变化.
  • config 是会根据发布而变化的: 资源,认证,环境特定值.
• Backing Services
  • 将后端服务(backing services) 视为附加资源(attached resources).
  • 代码不应区分本地和第三方的服务.
    • 它们都是�资源, 通过配置中的URL 来访问.
  • 资源可以被随意的加载/卸载(attach/detach).
• 严格区分build,release 和run 阶段
  • 从codebase 到deploy 的过程.
• 以无状态的进程的方式运行app.
  • 这样有利于扩展.
• app 应该自包含的(self-contained)
  • 并�通过端口绑定的方式来提供(HTTP)服务.
  • 将webserver(如jetty)添加到app (code)中,而不依赖于外部执行环境.
• Process 是一等公民
  • 将不同的工作分配给不同类型的process.
  • app 进程�不需要守护进程或写入PID 文件, 而是依赖于OS 的进程管理器(process manager).
• Disposable(�易处理):
  • app 应该可以快速地启动和优雅地关闭.
• 保持�开发和线上环境尽量一致.
  • �开发和线上环境之间的�差异(gap): 时间,人员,工具.
  • app 应使用�持续部署来减少两者间的差异.
  • 即使adapter理论上能够隔离不同�后端服务, 但是最好还是在开发和线上环境中使用相同的后端服务. 因为不同�服务间的差异, 可能会导致代码上的分支.
    • 由于包管理和虚拟化环境的出现, 轻量级的本地环境变得不再重要.
• Log
  • 把log 视为事件流(event stream).
  • app 本身不关心输出流的routing/storage.
  • 由执行环境来负责流的归档目的地(terminal, file).
• 管理进程(admin process)
  • 以一次性进程(one-off process) 的形式运行后台管理任务.
    • 例如: 数据移植, 控制台脚本等.