12要素官网地址：https://12factor.net/zh_cn/
12-Factor 为构建如下的 SaaS(software as a service 软件即服务) 应用提供了方法论：
- 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
- 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
- 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
- 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
- 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。
这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。
-
Codebase（基准代码）：一份基准代码，多份部署
每个应用只对应一份基准代码，但可以同时存在多份部署。每份部署相当于运行了一个应用的实例。通常会有一个生产环境，一个或多个预发布环境。此外，每个开发人员都会在自己本地环境运行一个应用实例，这些都相当于一份部署。 -
Dependencies（依赖）：显式声明依赖关系
12-Factor规则下的应用程序不会隐式依赖系统级的类库。 它一定通过依赖清单，确切地声明所有依赖项。此外，在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。 -
Config（配置）：在环境中存储配置
12-Factor推荐将应用的配置存储于环境变量中（ env vars, env ）。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码；与配置文件不同，不小心把它们签入代码库的概率微乎其微；与一些传统的解决配置问题的机制（比如 Java 的属性配置文件）相比，环境变量与语言和系统无关。 -
Backing Services（后端服务）：把后端服务当作附加资源
12-Factor 应用不会区别对待本地或第三方服务。 对应用程序而言，两种都是附加资源，通过一个 url 或是其他存储在配置中的服务定位/服务证书来获取数据。12-Factor 应用的任意部署，都应该可以在不进行任何代码改动的情况下，将本地 MySQL 数据库换成第三方服务（例如 Amazon RDS）。类似的，本地 SMTP 服务应该也可以和第三方 SMTP 服务（例如 Postmark ）互换。上述 2 个例子中，仅需修改配置中的资源地址。
每个不同的后端服务是一份资源，这些资源和它们附属的部署保持松耦合。
部署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 – 整个过程都不需要修改代码。 -
Build、Release和Run（构建，发布和运行）：严格分离构建和运行
12-factor 应用严格区分构建，发布，运行这三个步骤。
- 构建阶段 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包依赖项，编译成二进制文件和资源文件。
- 发布阶段 会将构建的结果和当前部署所需配置相结合，并能够立刻在运行环境中投入使用。
- 运行阶段 （或者说“运行时”）是指针对选定的发布版本，在执行环境中启动一系列应用程序进程。
-
Processes（进程）：以一个或多个无状态进程运行应用
12-Factor 应用的进程必须无状态且无共享。 任何需要持久化的数据都要存储在后端服务内，比如数据库。 -
Port Binding（端口绑定）：通过端口绑定提供服务
12-Factor 应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务 ，并监听发送至该端口的请求。
端口绑定这种方式也意味着一个应用可以成为另外一个应用的后端服务 ，调用方将服务方提供的相应 URL 当作资源存入配置以备将来调用。 -
Concurrency（ 并发）：通过进程模型进行扩展
在 12-factor 应用中，进程是一等公民。12-Factor 应用的进程主要借鉴于unix 守护进程模型。
image
-
Disposability（易处理）：快速启动和优雅终止可最大化健壮性
12-Factor 应用的进程易处理（disposable）的，意思是说它们可以瞬间开启或停止。 这有利于快速、弹性的伸缩应用，迅速部署变化的代码或配置，稳健的部署应用。
进程应当追求最小启动时间，一旦接收终止信号就会优雅的终止。进程还应当在面对突然死亡时保持健壮，例如底层硬件故障。 -
Dev/Prod Parity（开发环境与线上环境等价）：尽可能的保持开发，预发布和线上环境相同
12-Factor 应用的开发人员应该反对在不同环境间使用不同的后端服务，即使适配器已经可以几乎消除使用上的差异。这是因为，不同的后端服务意味着会突然出现的不兼容，从而导致测试、预发布都正常的代码在线上出现问题。这些错误会给持续部署带来阻力。从应用程序的生命周期来看，消除这种阻力需要花费很大的代价。
- 缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。
- 缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。
- 缩小工具差异：尽量保证开发环境以及线上环境的一致性。
-
Logs（日志）：把日志当作事件流
12-factor应用本身从不考虑存储自己的输出流。不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（stdout）事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。 -
Admin Processes（管理进程）：把后台管理任务当作一次性进程来运行
进程构成是指用来处理应用的常规业务（比如处理 web 请求）的一组进程。
网友评论