十二要素应用——微服务成功指南

为什么选择十二要素应用？

现在让我们来探讨一下这12个因素：

十二要素应用实践

结论

为什么选择十二要素应用？

如今，微服务几乎成了主流。无论你在初创公司还是大公司工作，都会遇到微服务架构。Heroku 在定义构建稳固架构的基础方面做得非常出色。

2011年，Heroku联合创始人Adam Wiggins发表了《十二要素应用方法论》，该方法论基于他们自身的经验，用于构建软件即服务（SaaS）。它不依赖于特定的技术和语言，但能够成功地与微服务、容器和持续集成/持续交付（CI/CD）流水线兼容，并专注于DevOps，因此，这个话题引起了我的关注。

12要素应用框架基于部署云原生应用的几个参数：

Tibco 的 Matt Ellis 表示：“12 要素应用清单实际上是一套指导原则，它规定了如何构建微服务才能更好地支持独立管理和迭代服务的概念。这些要素在构建解耦、无状态的微服务时至关重要。” 那么，12 要素应用应该是什么样的呢？观看这段 28 秒的视频：https://www.youtube.com/watch?v= 7PH3AOePAXc

这份文件是发给谁的？

作者表示：“任何构建以服务形式运行的应用程序的开发人员，以及部署或管理此类应用程序的运维工程师。”

现在让我们来探讨一下这12个因素：

全部内容都已公开，无需赘述。我仅概述以下各点的核心信息：

因素 1：代码库

基于单一代码库构建，并完全由版本控制系统 (VCS) 进行跟踪。部署应实现自动化，以便所有程序都能在不同环境中轻松运行。每个应用程序应始终拥有一个独立的代码仓库，以简化 CI/CD 流水线。

因素 2：依赖关系

不要将任何依赖项复制到项目代码库中，而应使用包管理器。务必始终使用正确的依赖项版本，以确保所有环境保持同步并重现相同的行为。

因素 3：配置

将配置信息存储在环境变量中。配置和代码应该严格分离。无论应用程序部署在何处，代码都应该保持不变，但配置信息可以有所不同。

因素 4：支持服务

将后端服务视为附加资源，因为您的服务应该易于互换。您必须能够在不更改代码的情况下轻松地将后端服务从一个提供商切换到另一个提供商。这将确保良好的可移植性并有助于维护您的系统。

要素五：构建、运行、发布

十二要素应用要求构建、发布和运行阶段严格分离。每个版本都应该有唯一的发布 ID，并且版本发布应支持回滚。自动化和系统维护应尽可能简单。然后，将所有内容整合到一个可以发布、安装到环境中并运行的系统中。

因素 6：无状态过程

你不应该在服务中引入状态，应用程序应该作为一个单一的、无状态的进程执行。十二要素流程是无状态且不共享任何信息的。这一要素是微服务架构的核心。

因素 7：端口绑定

您的服务应该通过端口绑定对其他服务可见。如果您构建了一个服务，请确保其他服务可以根据需要将其视为资源。十二要素应用是完全自包含的。

因素 8：并发性

与其试图通过在最强大的机器上运行单个实例来扩大应用程序的规模，不如将应用程序拆分成更小的模块。小型、定义明确的应用程序可以根据需要进行横向扩展，以应对不同的负载。每个进程都应该单独扩展，而 Factor 6（无状态）可以轻松实现服务的扩展。

因素9：可处置性

流程应该更省时。确保能够快速运行和停止，并且能够应对故障。否则，自动扩展和部署、开发的便捷性都会降低。容器可以实现这一点。

因子 10：开发环境与生产环境的一致性

尽可能保持开发、测试和生产环境的一致性，以便任何人都能理解并发布。持续部署需要基于匹配环境的持续集成，以减少偏差和错误。这也有助于构建DevOps文化，实现软件开发和运维的统一。容器化技术在这方面发挥着巨大的作用。

因子 11：对数

将日志视为事件流。日志记录对于调试和检查应用程序的整体运行状况至关重要。同时，应用程序本身不应负责存储这些信息。相反，这些日志应被视为由单独的服务捕获和存储的连续流。

因素 12：管理流程

将管理任务作为一次性流程运行，例如数据库迁移或在环境中执行一次性脚本。为避免直接操作数据库，请使用与应用程序一同构建的工具来检查数据库。

十二要素应用实践

Greg Pryzby在他的演讲“你必须达到 12 要素高度才能驾驭”中探讨了这种方法，并解释了 12 要素应用和 OpenStack 如何相互补充：https://youtu.be/GZ4sAEUMOnM

还有两篇文章值得一读：《为什么 12 要素应用模式、微服务和 CloudFoundry 很重要》，作者是 Tim Spann；《我如何使用 12 要素应用方法论来构建 Java 和 Scala 的 SaaS 应用》，作者是 Jay Kapadnis。

结论

微服务架构模式仍然相对较新，因此我强烈建议您详细学习十二要素应用方法论。根据我的经验，大多数微服务项目在初期都会失败。这并非由于深层次的设计问题或编码困难，而是因为基础工作做错了。

12 因素中的一些要点可能看起来微不足道，但当通过少数环境运行 20 多个服务时，它们可能非常重要。

最后，我想引用蒂姆·斯潘对为何决定将十二要素应用模式、微服务和 Cloud Foundry 结合起来的独特解释：

“好的代码如果没有良好的流程和平台支持也会失败。好的团队如果没有拥抱 DevOps、微服务而非庞大单体架构的良好文化也会失败。”

也发布在这里