开源开发者关于 12-Factor App 方法论的指南

12-Factor App 方法论 为在短时间内构建应用程序并使其可扩展提供了指南。它由 Heroku 的开发人员创建，用于软件即服务 (SaaS) 应用程序、Web 应用程序以及可能的通信平台即服务 (CPaaS) 应用程序。对于有效地组织项目和管理可扩展的应用程序，12-Factor App 方法论为开源开发带来了强大的优势。

12-Factor App 方法论的原则

12-Factor App 方法论的原则是严格的规则，这些规则充当开发和部署 SaaS 应用程序的构建块，并且不受任何编程语言或数据库的约束。

1：一个代码库，在版本控制中跟踪，多次部署

图片来源：

^{Seth Kenlon CC-0}

每个应用程序都应该有一个代码库，并具有多个不同的环境/部署。

开发人员不应仅仅为了在不同环境中进行设置而开发另一个代码库。不同的环境代表不同的状态，但这些不同的环境应该共享相同的代码库。

在诸如 GitLab 之类的 Subversion 控制系统的上下文中，环境可以被视为分支，许多开源项目都存储在其中。例如，您可以在任何中央版本控制系统中为名为 VoIP-app 的云 VoIP 应用程序创建一个单一存储库，然后创建两个分支，development 和 staging，其中 “master” 作为发布分支。

2：显式声明和隔离依赖项

所有依赖项都应声明。您的应用程序可能依赖于外部系统工具或库，但不应隐式依赖于系统工具或库。您的应用程序必须始终显式声明所有依赖项及其正确的版本。

在代码库中包含依赖项可能会产生问题，尤其是在开源项目中，外部库中的更改可能会将错误引入代码库中。例如，代码库可能使用外部库，但未显式声明此依赖关系或版本。如果外部库更新到较新的、未经测试的版本，则可能会与您的代码产生兼容性问题。通过显式声明依赖项及其正确的版本，可以保护您的代码库免受此问题的影响。

根据技术堆栈，最好使用包管理器通过读取表示依赖项名称和版本的依赖项声明清单，在您的相应系统上下载依赖项。

3：将配置存储在环境中

当您需要支持多个环境或客户端时，配置将成为应用程序的重要组成部分。在不同部署之间变化的配置应存储在环境变量中。这使得在部署之间进行更改变得容易，而无需更改代码。

对于闭源应用程序，此原则是有益的，因为您不希望像数据库连接信息或其他秘密数据之类的敏感信息公开。但是，在开源开发中，这些详细信息是公开的。在这种情况下，优势在于您无需重复更改代码。您只需以这样一种方式设置变量，即只需更改环境即可使您的代码库完美运行。

4：将后备服务视为附加资源

所有后备服务（例如数据库、外部存储或消息队列）都被视为附加资源，并由执行环境附加和分离。根据此原则，如果这些服务的位置或连接详细信息发生更改，您仍然不需要更改代码。详细信息在配置中可用。

后备服务可以快速附加或分离部署。例如，如果您的基于云的 erp 的数据库无法正常工作，则开发人员应该能够创建一个从最近备份还原的新数据库服务器，而无需更改代码库。

5：严格分离构建和运行阶段

12-Factor App 要求在构建、发布和运行阶段之间严格分离。

• 第一阶段是构建 阶段。在此阶段，源代码被组装或编译为可执行文件，同时加载依赖项和创建资产。每次需要部署新代码时，构建阶段都会启动。

• 第二阶段是发布 阶段。在此阶段，构建阶段生成的代码与部署的当前配置相结合。生成的发布包含构建和配置，并准备好在执行环境中立即执行。

• 第三阶段是运行 阶段，也是最后阶段：应用程序在执行环境中运行。它不应被任何其他阶段中断。

通过严格分离这些阶段，我们避免了代码中断，并使系统维护更加易于管理。

6：将应用程序作为一个或多个无状态进程执行

应用程序在执行环境中作为一个或多个进程的集合执行。这些进程是无状态的，持久化数据存储在后备服务（例如数据库）上。

这对于开源很有用，因为使用该应用程序版本的开发人员可以在其云平台上创建多节点部署以实现可扩展性。数据不会持久存储在其中，因为如果其中任何一个节点崩溃，数据将会丢失。

7：通过端口绑定导出服务

您的应用程序应充当独立于其他应用程序的独立服务。它应该可以通过 URL 访问其他服务，充当服务。这样，您的应用程序可以在需要时充当其他应用程序的资源。使用此概念，您可以构建 REST API。

8：通过进程模型横向扩展

也称为并发原则，此原则表明您的应用程序中的每个进程都应该能够扩展、重启或克隆自身。

开发人员可以创建多个进程并将应用程序的负载分配给这些进程，而不是使一个进程更大。这种方法允许您通过将每个工作负载分配给一个进程类型来构建应用程序以处理不同的工作负载。

9：通过快速启动和优雅关闭最大程度地提高稳健性

您的应用程序应基于简单的进程构建，以便开发人员可以扩展进程，同时仍然允许他们在出现问题时重新启动它们。这使得应用程序的进程成为可丢弃的。

基于此原则构建应用程序意味着代码的快速部署、快速弹性扩展、发布过程的更高敏捷性和稳健的生产部署。所有这些在开源开发环境中都非常有帮助。

10：保持开发、暂存和生产环境尽可能相似

从事项目的团队应使用相同的操作系统、后备服务和依赖项。这降低了出现错误的可能性，并减少了开发所需的时间。

由于开源项目的开发人员分散性，他们可能无法就他们使用的系统、服务和依赖项进行沟通，因此将此原则付诸实践可能对开源项目构成挑战。减少这些差异的一种可能性是开发指南，建议使用哪些操作系统、服务和依赖项。

11：将日志视为事件流

日志对于解决生产问题或了解用户行为至关重要。但是，12-Factor App 不应关注日志的管理。

相反，它应该将日志条目作为事件流路由，以标准输出的形式写入，到一个单独的服务进行分析和存档。机器人流程自动化 (RPA) 技术可用作第三方服务来处理和分析日志。执行环境将决定如何处理此流。这为内省应用程序的行为提供了更大的灵活性和能力。

12：将管理/管理任务作为一次性进程运行

此原则实际上与开发无关，而是与应用程序管理有关。管理进程应在与应用程序的常规长时间运行进程相同的环境中运行。在本地部署中，开发人员可以使用应用程序检出目录中的直接 shell 命令来执行一次性管理进程。

结论

通过使用 12-Factor App 方法论开发您的应用程序，您可以提高效率并更快地推出。在开源开发中，偏离某些指南可能是有意义的，但最好尽可能严格地遵循这些指南。

开源 12-Factor App 是可能的。一个很好的例子是 Jitsi，一个开源视频会议平台，它在大流行期间成功扩展了 100 倍，并且是使用 12-Factor App 方法论构建的。