构建应用服务的十二条准则

构建一个稳健易扩展的应用服务一直是我们不断追求的事情。早在九年前，《The Twelve-Factor APP》一文便从 12 个方面进行了软件开发准则的相关总结，即使时光飞逝，软件开发领域发生了翻天覆地的变化，但此文仍具有很高的参考价值，本文将会进行简单的重温。

———————————————————————————

1. Codebase

基准代码应该与应用项目之间保持一一对应的关系。

同一个应用，即使针对不同的环境需要分别部署，也应该来源于同一份基准代码。对于多个应用如果存在需要共享的代码，则应该将其拆分为独立的类库，然后使用依赖管理策略去加载它们。

2. Dependencies

显示声明依赖关系。应用必须有一个依赖清单，确切地声明所有依赖项。需要注意的是不要隐式依赖某些系统工具，诸如 curl 之类。

3. Config

代码和配置严格分离。

不同的环境（如开发环境、预发布环境、生成环境等）通常会有不同的配置（如数据库、缓存系统、第三方服务等等）。有些应用使用硬编码的方式将这些配置项保存于代码的常量中，这种做法是 12-Factor 明确反对的。

判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立即开源，而不用担心会暴露任何敏感信息。

一种解决方法是使用配置文件，但不把它们纳入版本控制系统。12-Factor 更推荐的是使用环境变量的方式。

4. Backing services

我们的应用程序常常会依赖于其它一些后端服务，如数据库、消息队列、缓存系统等。不论这些服务是在本地还是第三方提供（如云平台），12-Factor 都只是把这些后端服务当做是附加的资源。

这些资源和它们附属的部署保持松耦合，部署可以按需加载或卸载资源，而不需要修改代码。

5. Build, release, run

严格区分构建、发布、运行三个步骤。比如直接修改运行状态的代码是非常不可取的做法。

6. Processes

应用的进程必须无状态且无共享，需要持久化的数据应该存储在诸如数据库之中。

粘性 session（用户 session 缓存至应用进程的内存中）是 12-Factor 极力反对的，你应该将 session 数据保存在诸如 memcached 或 redis 这样带有过期时间的缓存中。

7. Port binding

通过端口绑定来提供服务。

8. Concurrency

并发扩展。

12-Factor 建议开发人员根据不同的进程类型去设计应用架构，例如，处理 http 请求的交给 web 进程，常驻后台工作的交给 worker 进程。

应用程序必须可以跨越多台物理机具有良好的水平扩展能力。

9. Disposability

快速启动、优雅终止。

10. Dev/prod parity

保持环境的一致性。

11. Logs

应用本身并不考虑存储自己的输出流，所有日志应该通过标准输出到统一的日志系统。

12. Admin processes

管理操作不要在暗地里进行，有迹可循很重要。

最后，参考归参考，灵活运用最重要。