Heroku创始人Adam Wiggins发布十二要素应用宣言

Heroku是业内知名的云应用平台，从对外提供服务以来，他们已经有上百万应用的托管和运营经验。前不久，创始人Adam Wiggins根据这些经验，发布了一个“十二要素应用宣言（The Twelve-Factor App）”,该宣言由国内工做于安居客的程序员梁山将其翻译为中文，InfoQ中文站摘录以下。

十二要素应用宣言

简介：

现在，软件一般会做为一种服务来交付，它们被称为网络应用程序，或“软件即服务”（SaaS）。“十二要素应用程序”（12-Factor App）为构建以下的SaaS应用提供了方法论：

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

这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。

背景

本文的贡献者者参与过数以百计的应用程序的开发和部署，并经过Heroku平台间接见证了数十万应用程序的开发，运做以及扩展的过程。

本文综合了咱们关于SaaS应用几乎全部的经验和智慧，是开发此类应用的理想实践标准，并特别关注于应用程序如何保持良性成长，开发者之间如何进行有效的代码协做，以及如何避免软件污染 。

咱们的初衷是分享在现代软件开发过程当中发现的一些系统性问题，并加深对这些问题的认识。咱们提供了讨论这些问题时所需的共享词汇，同时使用相关术语给出一套针对这些问题的广义解决方案。本文格式的灵感来自于Martin Fowler的书籍： Patterns of Enterprise Application Architecture， Refactoring 。

读者应该是哪些人？

任何SaaS应用的开发人员。部署和管理此类应用的运维工程师。

I. 基准代码

一份基准代码，多份部署

基准代码和应用之间老是保持一一对应的关系：

• 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每个组件都是一个应用，每个应用能够分别使用12-Factor进行开发。
• 多个应用共享一份基准代码是有悖于12-Factor原则的。解决方案是将共享的代码拆分为独立的类库，而后使用依赖管理策略去加载它们。

尽管每一个应用只对应一份基准代码，但能够同时存在多份部署。

全部部署的基准代码相同，但每份部署可使用其不一样的版本。

II. 依赖

显式声明依赖关系

12-Factor规则下的应用程序不会隐式依赖系统级的类库。 它必定经过依赖清单 ，确切地声明全部依赖项。此外，在运行过程当中经过 依赖隔离 工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一作法会统一应用到生产和开发环境。

III. 配置

在环境中存储配置

12-Factor推荐将应用的配置存储于环境变量 中 (env vars, env) 。环境变量能够很是方便地在不一样的部署间作修改，却不动一行代码；与配置文件不一样，不当心把它们签入代码库的几率微乎其微；与一些传统的解决配置问题的机制（好比Java的属性配置文件）相比，环境变量与语言和系统无关。

12-Factor应用中，环境变量的粒度要足够小，且相对独立。它们永远也不会组合成一个所谓的“环境”，而是独立存在于每一个部署之中。当应用程序不断扩展，须要更多种类的部署时，这种配置管理方式可以作到平滑过渡。

IV. 后端服务

把后端服务看成附加资源

12-Factor应用不会区别对待本地或第三方服务。 对应用程序而言，两种都是附加资源，经过一个url或是其余存储在 配置 中的服务定位/服务证书来获取数据。12-Factor应用的任意 部署 ，都应该能够在不进行任何代码改动的状况下，将本地MySQL数据库换成第三方服务(例如 Amazon RDS)。相似的，本地SMTP服务应该也能够和第三方SMTP服务(例如Postmark)互换。

V. 构建，发布，运行

严格分离构建和运行

12-facfor应用严格区分构建，发布，运行这三个步骤。

每个发布版本必须对应一个惟一的发布ID。

新的代码在部署以前，须要开发人员触发构建操做。可是，运行阶段不必定须要人为触发，而是能够自动进行。

VI. 进程

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

12-factor应用的进程必须无状态且无共享 。任何须要持久化的数据都要存储在后端服务内，好比数据库。粘性Session是twelve-factor极力反对的。Session中的数据应该保存在诸如Memcached 或 Redis 这样的带有过时时间的缓存中。

VII. 端口绑定

经过端口绑定提供服务

12-factor应用彻底自我加载而不依赖于任何网络服务器就能够建立一个面向网络的服务。互联网应用 经过端口绑定来提供服务，并监听发送至该端口的请求。

VIII. 并发

经过进程模型进行扩展

在12-factor应用中，进程是一等公民。 12-factor应用的进程主要借鉴于 unix守护进程模型 。开发人员能够运用这个模型去设计应用架构，将不一样的工做分配给不一样的进程类型 。

IX. 易处理

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

12-factor应用的进程是可支配的，意思是说它们能够瞬间开启或中止。 这有利于快速、弹性的伸缩应用，迅速部署变化的代码或配置，稳健地部署应用。进程应当追求最小启动时间；进程一旦接收终止信号(SIGTERM) 就会优雅的终止 。进程还应当在面对忽然死亡时保持健壮 ，

X. 开发环境与线上环境等价

尽量的保持开发、预发布、线上环境相同

12-factor应用想要作到持续部署就必须缩小本地与线上差别。12-factor应用的开发人员应该反对在不一样环境间使用不一样的后端服务 ，即便适配器已经能够几乎消除使用上的差别。

XI. 日志

把日志看成事件流

12-factor应用自己从不考虑存储本身的输出流。 不该该试图去写或者管理日志文件。相反，每个运行的进程都会直接的标准输出(stdout)事件流。开发环境中，开发人员能够经过这些数据流，实时在终端看到应用的活动。

XII. 管理进程

后台管理任务看成一次性进程运行

一次性管理进程应该和正常的 常驻进程 使用一样的环境。这些管理进程和任何其余的进程同样使用相同的代码和配置，基于某个发布版本运行。后台管理代码应该随其余应用程序代码一块儿发布，从而避免同步问题。全部进程类型应该使用一样的依赖隔离技术。12-factor尤为青睐那些提供了REPL shell的语言，由于那会让运行一次性脚本变得简单。

但愿详细了解“十二要素应用宣言”的同窗，能够点击这里查看英文版，或是直接查看梁山同窗翻译的中文版。