目录

什么是 Twelve-Factor App

目录

在学习 Spring Cloud 的时候,文档一开始就提到了一个概念:Twelve-Factor App。这勾起了我的好奇心,刚好有个网站用来解释这个东西,这里谈谈我的理解。 https://12factor.net

什么是 Twelve-Factor App

首先,twelve-factor app 是由 Heroku 提出的一种用于构建 software-as-a-service (SaaS) 应用的方法论。但不是所有的 SaaS 应用都是 twelve-factor app,只有符合一些特征,才是一个 twelve-factor app。

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;

    通过声明的方式来自动化配置,以达到最小化项目新成员的时间成本和学习成本。这一点很好理解。

  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;

    和底层系统之间有明确的契约,这样就能提供最大的可移植性。

    类似于我们现在推崇的使用 docker 来输出我们的软件,这样我们只需要 docker 的环境就能运行我们的软件;而不是提供一个 jar 包或者前端打包的压缩文件,需要我们自行安装 java 或者 nginx 才能运行。

  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;

    适用于部署到现代云计算平台,从而避免对服务器或系统管理员的需求。

    其实,这样的要求就是在减小移植的成本。

  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;

    最小化开发环境和生产环境的差异,并启用持续部署来最大化敏捷实践。

    减少开发环境和生产环境的差异,有利于我们提早发现问题和排查问题。持续部署作为一种敏捷实践,应该大力推行。

  • And can scale up without significant changes to tooling, architecture, or development practices.

    可以在不对使用的工具、基础设施和开发实践进行重大改动的情况下进行“放大”。

    这里的“放大”,可以指部署上的水平扩容或者功能上的改进等等。

为什么需要 Twelve-Factor App

在面对现代软件开发过程中,我们会遇到很多系统性的问题。Heroku 提出 Twelve-Factor App 的初衷,是为了增强我们对这些问题的认知,并提供专用的名次来命名这些问题,同时提出针对这些问题的广义上的解决方案。

这里的 广义上的 ,原文用词 conceptual ,可以理解为是抽象的解决方案,而不是具体的解决方案。

这些问题和解决方案,也不是随便找了一些人来闭门造车想出来的,而是邀请了直接或间接参与了大量应用的开发、部署、运维以及扩展的拥有丰富经验的 IT 从业人员参与讨论,得出了这些系统性的问题和对应的解决方案。

Twelve-Factor 是哪十二个

Twelve-Factor App 提出了十二个方面的解决方案,这也是它的名字的由来。而每一点,官网都提供了一句话的总结和详细的描述。这里暂时简单记录一下。

1.Codebase

一句话总结:一份基准代码,多次部署。

2.Dependencies

一句话总结:显式的声明依赖。

3.Config

一句话总结:在部署的环境中存储配置。

这里说的配置,是指在各个部署环境中不同的值。如果某个配置在不同的环境中是相同的,那么它就不应该是一个配置。所以,这里的配置一定会针对到具体的环境中,我们应该将它们与环境绑定起来。

4.Backing services

一句话总结:将后端服务当作附加资源。

后端服务,不是平时所理解的 Web 应用的服务器那个后端,而是应用所调用到的其他服务,比如数据库、对象存储等等。当作附加资源,要求我们可以在不修改代码的情况下,可以切换所依赖的这些资源。比如,通过修改数据库的 URL、用户名等,切换到其他的数据库服务。

5.Build, release run

一句话总结:严格分离构建、发布和运行的阶段。

由于每一个阶段对系统健壮性、信息完整度的要求并不一致,对不同的阶段采取不同的措施是很有必要的。

6.Processes

一句话总结:以一个或多个无状态进程运行应用。

7.Port binding

一句话总结:通过绑定端口来提供服务。

8.Concurrency

一句话总结:通过进程模型来进行扩展。

在 twelve-factor app 中,进程是一等公民。Twelve-factor app 借鉴 unix 守护进程模型 来设计应用架构,将不同的工作分配给不同的进程类型来处理。

9.Disposability

一句话总结:快速和优雅的启动、终止进程,可最大化健壮性。

易处理的进程,意味着进程可以瞬间完成启动和终止。这样有利于快速的对应用进行伸缩、部署新的代码或配置。

10.Dev/prod parity

一句话总结:尽可能的保持 Dev、staging 和 production 环境一致。

11.Logs

一句话总结:像对待事件流一样对待日志。

12.Admin processes

一句话总结:后台管理任务当作一次性进程运行。


总结

可以将 Twelve-Factor App 理解为一种构建 cloud native 应用的指导原则(方法论),按照这样的原则设计并开发出来的应用,将会十分适用于部署到类似于 Heroku 这样的服务中。