金丝雀部署通过逐步将更改推送给一小部分用户，然后再进行更广泛分发，为软件版本提供了强大的风险缓解策略。就像在煤矿中使用金丝雀来检测危险的历史做法一样，这种部署模式可以帮助团队尽早发现潜在问题，同时限制有问题版本的传播半径。通过将一定比例的流量路由到新版本，团队可以监控关键指标、收集用户反馈，并在出现问题时自信地回滚更改 - 同时为大多数用户保持系统稳定性。
**开箱即用的解决方案**
云提供商提供许多内置部署策略，但在管理应用程序层之间的依赖关系时，它们往往存在不足。例如，在部署依赖于新后端端点的前端更改时，您需要确保用户在每一层都收到一致的版本。虽然内置的云金丝雀工具功能强大，但它们通常无法统一多个层的版本，以保证用户在整个体验过程中获得相同的版本。在保持同步的同时实施逐步推出可能是一种强大的工具，尤其是对于 DevOps 资源有限的团队而言。
本指南中概述的方法可能需要根据您的具体架构和堆栈进行调整，但。我将在此概述该解决方案，并在以后的帖子中深入探讨每个组件。
基本概述：
设置部署控制中心 Canary 部署需要同时运行应用程序组件的两个版本。您的 CI/CD 管道需要知道哪个环境应该接收新更改，哪个环境应该保持稳定。为了获得流畅的体验，您需要一个单一事实来源来定义哪个环境接收更改（“活动”环境），而另一个环境（“后备”环境）不受管道的影响。我们已经使用 SSM 参数实现了 SST。准备数据库 虽然拥有大量资源的团队可能会为每个版本启动单独的数据库，但这种方法成本高昂，并且会带来金丝雀部署旨在避免的同步风险。相反，我们采用了扩展和收缩模式，允许多个应用程序版本同时使用单个数据库。我们在启动金丝雀发布之前运行扩展步骤，并在完成流量迁移后执行收缩步骤。配置后端 成功运行金丝雀部署需要维护后端的两个独立版本。我们使用 Lambda 版本和别名来实现这一点。每个 Lambda 函数都有两个别名，每个环境一个。合并代码时，我们的管道会部署新的 Lambda 版本并更新活动环境的别名，而后备别名仍保留在上一个版本上。同步只需要更新别名以指向较新的版本。拆分 API 您的 API 需要将请求路由到正确的后端版本。在 AWS 中，我们通过 API 网关为每个环境部署单独的阶段来实现这一点。每个阶段都有自己的基本路径映射并连接到其相应的 Lambda 别名。虽然我们通过自定义管道逻辑来处理这个问题，但使用阶段变量同样有效。让前端驱动版本统一版本控制的关键是让用户从一开始就声明他们的堆栈版本。在前端构建期间，我们会注入特定于环境的 API URL。当用户加载您的应用程序时，前端会连接到其指定的 API 阶段，该阶段会调用相应的 Lambda 函数，从而在整个堆栈中创建一致的版本链。根据 Canary 规则路由流量 在建立单独的环境后，您需要根据 Canary 规则实施流量拆分。这需要使用 cookie 来维护跨用户会话的版本一致性 - 您不希望用户在页面重新加载时获得不同的版本。我们在 CloudFront 分发中使用 Lambda@Edge 函数在托管不同版本的 S3 存储桶之间路由流量。部署工具使其变得简单一种按计划逐步增加新版本流量的机制和一种在新发布之前调整版本的同步工具。同步工具需要特别注意。考虑这种情况：您发布 v54 时对环境 A 进行了前端更改，然后发布 v55 时对环境 B 进行了仅限后端的更改。几周后，您准备发布 v56 时对环境 A 进行了前端更改。挑战在于环境 A 的后端从未收到过 v55 的更新，而如果 v56 中没有后端更改，您需要一种方法来确保环境包含所有最新更新。这在服务以不同频率更新的微服务架构中尤为重要。在进行新部署之前，请验证目标环境是否与所有组件的最新更改同步。对我们来说，这意味着构建我们的 API 和前端，然后运行脚本来更新所有必要的 Lambda 别名。