微服务持续交付的 5 个注意事项

微服务架构将软件构建为一系列相互协作的服务。如今，这些架构被普遍认为是构建应用程序的更佳方式。

持续交付是任何软件交付实践的重要组成部分。无论目标部署环境如何，您都必须设计一个持续交付 (CD) 工作流，以便将软件变更投入生产。

在 ThoughtWorks，在与客户合作构建业务关键型软件的过程中，我们克服了构建微服务持续交付 (CD) 工作流的诸多挑战。在这篇博文中，我将分享我们在架构设计和应用程序开发中需要考虑的事项。

微服务和持续交付

根据Martin Fowler的说法，微服务架构是“将软件应用程序设计为可独立部署的服务套件的一种特殊方式”。这些架构目前在基于分布式系统概念构建应用程序方面非常流行。

Jez Humble 在他的开创性著作中将持续交付描述为“以可持续的方式安全、快速地将各种类型的变更（包括新功能、配置、错误修复和实验）投入生产的能力”。

无论目标部署环境或架构选择如何，无论是过去的单体架构还是如今的微服务架构，设计持续交付工作流以将变更投入生产都至关重要。持续交付工作流是 DevOps 流程的核心，并且涵盖组织中的各种职能，包括开发、质量保证和 IT 运营。

微服务持续交付面临的四大挑战

1. 维护复杂分布式系统的完整性。由于您将大型单片系统分解为更小、更易于管理的微服务，系统本身的整体复杂性也会增加。现在您必须处理分布式系统问题。

2. 持续安全快速地发布功能。当您的功能可能涉及一个或多个微服务的变更时，管理频繁的功能发布需要特别注意。

3. 管理不同技术栈的部署。微服务环境通常包含不同的服务技术栈。管理跨这些不同技术栈的部署流程极具挑战性。

4. 用于独立和带外部署服务的流程和工具。市面上有很多工具可用于建模持续交付 (CD) 工作流。最初规划您的持续交付 (CD) 工作流并选择最能代表此工作流的工具并非易事。

微服务持续交付的五个注意事项

在微服务架构上设计持续交付工作流时，我建议牢记以下五个注意事项。我将在本系列的后续文章中对每个注意事项进行深入讨论。以下仅作概述：

1. 制定有效的测试策略。 微服务系统的测试和验证比传统的单体应用测试更加细致和复杂。有效的测试策略既需要考虑单独测试各个服务，也需要考虑验证整个系统的行为。

对于服务的预生产测试，尤其是以独立方式进行的测试，传统的测试方法仍然适用且有意义。测试金字塔仍然可以帮助您在不同类型的测试之间保持平衡。然而，这种测试方式在测试服务集合时效果有限。有些类型的错误您无法在测试环境中模拟，例如，高度分布式系统中的最终一致性问题，以及导致系统部分功能失效的硬件和网络故障。

您必须使用合成用户测试、轻量级用户验收测试和故障注入测试等技术来补充传统的测试技术。

2. 检查你的CI实践

持续集成是成功的持续交付策略的关键实践。除了围绕构建服务器和构建定义进行的一些显而易见的考虑之外，基于主干的开发和功能切换也是两项关键实践，它们对于实现简单而强大的持续交付流程大有裨益。

在基于主干的开发中，开发人员在一个名为“主干”的分支上协作编写代码。其主要优势在于避免开发分支的漂移以及由此产生的合并地狱。这与维护长期功能和发布分支的做法背道而驰。在分支模型中，尽管您可能在各个分支上运行构建，但可以说您并没有进行持续集成。

要进行基于主干的开发，您需要使用称为功能切换的控件。功能切换允许对 WIP 和已完成功能的组合进行多次提交。使用这些切换，您可以关闭生产环境中未完成功能的显示，直到这些功能在预生产环境中开发完成并经过充分测试。功能切换通常存储在靠近代码库的规范或配置文件中，并由持续交付流水线中的自动化系统在特定环境中启用切换。

一旦您有了维护功能切换的机制，您就可以使用相同的机制来引入其他类别的切换，如发布切换（用于控制对未完成代码的访问）、Ops 切换（用于控制生产代码的行为）、权限切换（用于为特权用户打开特定行为）和实验切换（用于多变量测试 - 在将功能永久化之前，其接受程度如何）。

3. 规划您的环境 环境计划包括您的环境集、它们的预期用途、通过这些环境推广工件的策略以及这些环境上的切换状态。

首先，思考需要哪些环境及其预期用例。组织中的不同团队会有不同的需求冲突。创建环境时，您应该满足所有这些需求冲突。其次，如果可能，考虑使用云基础设施动态创建环境。例如，使用 Kubernetes 的标签功能创建用于自动化测试的动态测试环境，而不是长期存在的环境。第三，制定工件推广策略。持续交付 (CD) 流水线会生成大量工件。您应该考虑：需要存储多少工件，需要多少个仓库等等。

4. 战略性地管理配置

应用程序的配置包含所有因部署而异的内容，应该与代码分开存储。当您拥有一系列微服务时，应该如何处理配置？

我们发现一种有效的技术是在Consul或Vault等存储库中集中管理部署配置。将部署配置分散到Chef和持续交付管道等工具中只会使其难以理解和推理。

我们采用的另一种技术是，无论服务采用哪种技术栈，都标准化配置分发流程，让服务根据其技术栈来处理配置的使用。例如，我们通常遵循12 要素建议，避免分发配置文件。

最后，像证书这样的机密信息需要一个治理流程来确保得到妥善管理。这通常是一个手动过程，但您需要提前考虑并落实到位。

5. 做好应对可能出现问题的准备

在微服务系统中，多个服务频繁更新，当服务部署引入不稳定性或错误时，您如何应对？

前滚意味着找到故障的根本原因并尽快应用修复，这在大多数情况下是最好的补救措施。要做到这一点，前提条件是确保您能够从热修复分支直接发布到生产环境。您可能不希望生产中断的修复通过 CD 管道，这取决于更改通过管道所需的时间。 在生产系统中，回滚总是很棘手。在大多数情况下，如果更改很细粒度并且可以推理，则很容易回滚。但如果部署包括不易推理的更改，例如数据库更改，尤其是导致架构更改的更改，则需要在连续部署中将数据库更改与代码更改分开部署，以确保数据库更改与早期版本的代码向后兼容。

概括

这是我们“微服务持续交付”系列博客的第一部分。我们讨论了在微服务架构上构建持续交付流水线的四大挑战和五大注意事项。在下一篇博客中，我将深入探讨第一个注意事项：基于微服务架构的系统的测试策略。