云应用成功的12-Factors原则

嘿，开发者！你是否关心如何使用最佳的方式将你的程序应用到云上？如果是这样，你应该根据 12-Factors 原则设计应用。12-Factors 原则是一种建立软件即服务（SaaS）的方法。今天，我将介绍这个上月我在 Red Hat 峰会上向一个小组提出的12-Factors 原则。

每个把应用程序迁移到云中的开发人员都将会面临与他们的数据中心、日常惯于使用或本地所不同的环境，这正是他们应该考虑 12-Factors 原则的理由。 Heroku 是一家云计算供应商，他们为大多数客户遇到的问题找到了一个通用的解决方案，并决定将这些[1]解决方案总结为一种方法发布（即 12-Factors 原则）。这种方法包含的12个因素旨在解决与在云中运行的应用程序相关的问题。仅仅记忆这12个因素并没有多少意义，对每一点之所以重要的原因的理解才是这篇文章或许能带给读者的收获。

1. 基准代码 - 使用版本控制工具，一份基准代码对应多个部署。
2. 依赖关系 - 使用包管理器，并且不要在代码库中提交依赖包。
3. 配置 - 将配置存储在环境变量中，需要（针对不同部署环境）重新打包你的应用程序意味着错误的设计。
4. 备份服务 - 一份 12-Factors 应用[2]部署应能够在不更改代码的情况下从本地MySQL数据库切换到第三方托管的数据库（如Amazon RDS）。
5. 构建，发布，运行 - 12-Factors 应用应严格分离构建，发布和运行阶段。每个发布版本要始终有唯一的版本ID，并且应允许回滚。
6. 进程 - 以一个或多个无状态进程形式运行应用。12-Factors 应用的进程应当是无状态，无共享的。
7. 端口绑定 - 通过端口绑定提供服务，12-Factors 应用是完全独立、自我加载（不依赖网络服务器）的。
8. 并发性 - 通过进程模型扩展系统。每个进程都应该能够单独进行扩展，无状态特性将使得服务扩展易于实现。
9. 易处置性 - 通过快速启动和优雅终止最大化稳健性（鲁棒性），我们可以通过容器来实现这一点。
10. 开发/生产环境等价 - 尽可能保持相似的开发、预发布和生产环境，12-Factors 应用通过缩小开发与生产环境差异实现持续部署的设计目标。
11. 日志 - 将日志视为事件流，12-Factors 应用本身从不考虑管理（routing）或存储自己的输出流。
12. 管理进程 - 将管理/管理任务作为一次性进程运行。

12-Factors 原则很难通过简单的技术或语言来描述，但是容器(Containers)，微服务(Microservices),和CI/CD流水线这些关注DevOps的工具满足了这一原则。您可以在这里访问关于 12-Factors 原则的更多信息。

[1] 原文如此

[2] 即根据 12-Factors 原则设计的应用程序