SaaS 应用的 12 因素

SaaS 应用的 12 因素

基准代码

• 分布式系统中的每一个组件都是一个应用
• 每一个应用只有一份基准代码
• 共享代码拆分为独立类库
• 一份基准代码可以有有多个部署

依赖

• 通过依赖清单指明所有依赖项
• 如果使用到系统工具，例如 curl, 同样把它放到应用中

配置

• 代码和配置分离
• 使用配置文件
• 推荐将配置存储于环境变量(env vars)，在部署启动时注入(环境变量的粒度要足够小，且相对独立)

后端服务

• 把后端服务当作附加资源
• 按需加载

构建、发布、运行

把基准代码变成实际可用的产品需要下面三个阶段：

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

每次发布都必须对应一个唯一的 ID，一旦发布就不修改，任何变动都应该产生一个新的版本

进程

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

• 必须无状态切无共享
• 持久化数据保存在后端服务中
• 永远不考虑缓存在内存或硬盘上的内容在未来可用
• 不使用 “粘性 session”，会话数据应该存在 Redis 这类带有过期时间的服务中

端口绑定

• 互联网应用通过端口绑定来提供服务 ，并监听发送至该端口的请求
• 应用独立，可以独立启动服务
• 需有一个路由层转发请求
• 一个应用程序可以成为另一个应用程序的支持服务

并发

• processes 是一等公民
• 遵行 UNIX 进程模型
• 为不同类型工作分配到不同应用程序
• 应用必须能够跨越多台物理机运行
• 应用自身不管理进程或写入 PID 文件，使用系统或三方工具进行管理

通过快速启动和正常关闭来最大限度地提高鲁棒性

• 进程最小化启动时间，最好在几秒钟内
• 当进程收到来自进程管理器的 SIGTERM 信号时，进程会正常关闭
  • 停止监听端口
  • 完成当前请求
  • 退出
• 对于 worker processes, 当前工作应该回到工作队列，当前工作的锁应该被释放
  • 所有作业都是可重做的（使用事务或 idempotent.）
• 在底层硬件出现故障的情况下，进程还应该能够抵御突然死亡

保持开发、暂存和生产尽可能相似

• 缩小时间间隔：开发者写了几个小时或几分钟代码就进行部署
• 缩小人员差距：谁写代码谁部署
• 缩小环境差距：开发环境和生产环境应尽可能相似
• 不依赖适配器在开发和生产之间使用不同的支持服务

将日志视为事件流

• 应用不关心日志的路由或存储

• 应用程序只需将其未缓冲的事件流写入 stdout

• 每个流程的流将由执行环境捕获，并整理在一起

• 日志系统功能

  • 查找过去的某些事件
  • 大规模趋势图
  • 主动警报

将管理/管理任务作为一次性任务运行

• 数据库迁移
• 控制台运行代码
• 一次性脚本

一次性管理任务应在与应用程序在相同的环境中运行，管理程序和应用程序一起提供避免同步问题