微服务架构中如何适应12要素应用（Twelve‑Factor App）

Heroku是业内知名的云应用平台，从对外提供服务以来，他们已经有上百万应用的托管和运营经验。其创始人Adam Wiggins根据这些经验，发布了一个“十二要素应用宣言（The Twelve-Factor App）”，这个设计原则对SaaS平台非常具有指导意义。

十二要素应用宣言
如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论：

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

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

12-factor为Web应用程序或SaaS平台的建立非常有用的指导原则，但它在有些地方并不适合微服务体系。因此在实施微服务架构时修改和扩展了12-factor，将“十二因子应用”中的核心思想应用于针对持续交付和优化的通用微服务架构。

微服务应用的十二个因素
1 - Codebase
一份基准代码，多份部署

Twelve-Factor App为每个应用推荐一个代码库。在微服务架构中，正确的方法实际上是每个服务的一个代码库。此外，我们强烈建议使用Git作为存储库，因为它具有丰富的功能集和巨大的生态系统。GitHub已经成为开源社区的默认Git托管平台，但根据贵组织的需求，还有许多其他优秀的Git托管选项。

2 - 依赖关系
显式声明依赖关系

正如The Twelve-Factor App中所建议的那样，无论您的应用程序在哪个平台上运行，都要使用您的语言或框架附带的依赖关系管理器。您如何安装操作系统或平台依赖性取决于平台：

• 在非集成环境中，使用配置管理工具（Chef，Puppet，Ansible）来安装系统依赖关系。
• 在一个容器化的环境中，在Dockerfile中执行此操作。

注意：我们建议您在全面的基础架构即代码策略背景下选择依赖管理机制，而不是作为单独的决策。

3 - 配置
在环境中存储配置

任何部署之间的差异都可以视为配置。Twelve-Factor App指南建议将所有配置存储在环境中，而不是将其提交到存储库。我们推荐以下具体做法：

• 使用非版本控制的.env文件进行本地开发。Docker支持在运行时加载这些文件。
• 将所有.env文件保存在一个安全的存储系统（如Vault）中，以使这些文件可供开发团队使用，但不会提交给Git。
• 对运行时可能更改的任何内容以及不应提交给共享存储库的任何内容使用环境变量。
• 将应用程序部署到交付平台后，使用交付平台的机制来管理环境变量。

4 - 支持服务
把后端服务当作附加资源

Twelve-Factor App指南将支持服务定义为“作为其正常操作的一部分，应用程序在网络上使用的任何服务”。微服务的含义是服务外部的任何内容都被视为附加资源，包括其他服务。这确保了每个服务都是完全可移植的，并且松散地耦合到系统中的其他资源。此外，严格的分离会在开发过程中提高灵活性 - 开发人员只需运行他们正在修改的服务，而不需要运行其他服务。

5 - 构建，发布，运行
严格分离构建和运行

为了支持严格分离构建，发布和运行阶段，我们推荐使用持续集成/持续交付（CI / CD）工具来自动构建。Docker镜像可以轻松分离构建和运行阶段。理想情况下，镜像是从每次提交创建的，并被视为部署工件。

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

对于微服务，进程因素中的重要一点是您的应用程序需要无状态。这可以通过简单地添加更多的服务实例来轻松扩展服务。将任何有状态数据或需要在实例之间共享的数据存储在后备服务中。

7 - 数据隔离
通过端口绑定提供服务

作为使端口绑定因子对微服务更有用的修改，建议只允许通过服务的API访问服务拥有的持久数据。这可以防止微服务之间的隐式服务契约，并确保微服务不能紧密耦合。数据隔离还允许开发人员为每项服务选择最适合其需求的数据存储类型。

8 - 并发性
通过进程模型进行扩展

Unix进程模型在很大程度上是微服务架构的一个前辈，因为它允许在单个应用程序中对不同任务进行特例化和资源共享。在微服务体系结构中，您可以独立地水平扩展每项服务，并在底层基础结构支持的范围内。使用集装箱化服务，您可以免费获得Twelve-Factor应用程序推荐的并发性。

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

服务实例需要一次性使用，以便可以快速启动，停止和重新部署，并且不会丢失数据。部署在Docker容器中的服务会自动满足此要求，因为它是容器的固有功能，可以立即停止并启动它们。将状态或会话数据存储在队列或其他后备服务中可确保在发生容器崩溃时无缝处理请求。

10 - 开发/产品奇偶校验
尽可能的保持开发，预发布，线上环境相同

尽可能保持所有的环境 - 开发，阶段，生产等 - 以减少只在某些环境中出现错误的风险。为了支持这个原则，我们再次推荐使用容器 - 这里是一个非常强大的工具，因为它们使您能够从本地开发到生产全过程运行完全相同的执行环境。但请记住，底层数据的差异仍然会在运行时造成差异。

11 - 日志
把日志当作事件流

不要在微服务中包含用于路由或存储日志的代码，而要使用市场上许多优秀的日志管理解决方案之一，其中几个列于十二因子应用程序中。此外，决定如何使用日志需要成为更大的APM和/或PaaS策略的一部分。

12 - 管理进程
后台管理任务当作一次性进程运行

在生产环境中，与应用程序分开运行管理和维护任务。容器使得这很容易，因为你可以启动一个容器来运行一个任务，然后关闭它。

结论
希望您在开发您自己的应用时使用这些原则，使用Twelve-Factor App和这些附加原则来帮助您创建可持续交付，并进行了优化的基于微服务的应用程序。