使用 Redis 优化特性发布和错误分类

为了不断前进、不断发展……你肯定不想犯下 Knights Capital 在 2012 年犯下的 4.6 亿美元的错误。这家领先金融市场做市商仅用一天时间就发生的计算机系统故障，为更广泛的 IT 社区提供了多项教训，包括系统组件的设计、实现和 DevOps 细节的至关重要性。在这篇分为两部分的博客中，我将分享一些想法，帮助开发团队确保他们的持续集成和持续部署 (CI/CD) 流程万无一失。特别是，我将展示如何利用特性开关（feature toggles）和特性上下文（feature context）来指导代码路由，存储日志数据以便轻松访问，以及使用 Redis 创建一个快速查找的错误数据库，从而管理持续更新。

想象一下，你是一名工程总监，管理着一个由几名开发人员组成的团队，负责一个拥有数千名并发用户的 Web 应用程序的前端。你的应用程序部署在 AWS 上，并且你每周都会进行更新。业务不能承受 Web 应用程序的任何中断，因此如果发生错误，你的团队必须立即回滚最新的更新。

你必须快速找出问题代码，让相应的开发人员修复它，并将修改纳入后续版本。此外，产品团队总是要求尽快普遍提供新特性。那么，如何在业务要求的高速度下迅速应对错误并安全地部署特性请求呢？

在 2019 年游戏开发者大会 (GDC) 上，我参加了一个会议，其中描述了一个经过深思熟虑的流程，用于可靠地执行每周软件发布。该会议的标题是“大规模调试：面向 7000 万+ 月活跃用户的跨平台稳定性”，由 Redis 客户 Roblox 的 Chris Swiedler 共同主讲。Chris 分享了一个有趣的见解，讲述了他的团队如何在不修改代码的情况下修改 Roblox 应用程序的行为，以防遇到生产问题。他们使用特性标志（feature flags），这与 Martin Fowler 的“特性开关”（feature toggle）方法非常相似。

新特性发布的 CI/CD 示例流程

Redis - Figure 2: Feature development and promotion — 图 2：特性开发与推广

让我们详细解读图 2，它概述了一种可以作为你 CI/CD 和错误分类流程一部分的方法。

开发人员开始开发新特性。
开发人员和产品管理团队决定哪些场景将使用新特性（可能仅针对部分用户）。
然后，开发人员提出一种开关策略，其中新代码和旧代码通过“if 和 else”块进行分隔。
开发人员完成新特性代码后，他们在（DevOps 的帮助下）将金丝雀发布（canary release）推广到生产环境。
用户使用应用程序一段时间，根据他们的画像和开关设置，他们会访问新代码或旧代码。
如果出现问题，可以将开关设置为 false，将所有用户重定向到旧代码。
一段时间后，该特性被推广至普遍可用 (GA)。

这种策略有助于

将金丝雀发布部署到生产环境，使用实时流量和真实用户进行测试，而非模拟；
无需回滚任何代码即可即时禁用特性；
通过开关标志启用特性或特性组合；以及
通过存储在开关标志中的元数据对代码进行指纹识别，以便轻松识别负责的开发人员（适用于大型开发团队）。

但这种方法可以更进一步，帮助分布式开发团队安全地发布新特性，并在需要时以最小的影响回滚它们。

使用 Redis Enterprise 进行 CI/CD

Redis - Figure 3: Managing toggles, context, errors & logs with Redis Enterprise — 图 3：使用 Redis Enterprise 管理开关、上下文、错误和日志

Redis Enterprise 在你需要一个快速、持久的数据库时非常适用。其功能包括

一个完全托管的 Redis 数据库即服务，具有持久的网络存储，可以防止实例存储的易失性。
CRDB（或称无冲突复制数据库），它跨位于全球不同数据中心的多个 Redis Enterprise 集群创建。这提供了高可用性，包括主-主和主-备部署形式。
强大的搜索功能（通过 RediSearch 模块），用于跨数据库集群运行搜索查询。

Redis - Figure 4: CRDB deployment of Redis Enterprise — 图 4：Redis Enterprise 的 CRDB 部署

在本系列的下一篇文章中，我将提供更多详细信息和代码片段，具体展示如何使用 Redis 构建的特性开关、特性上下文、错误数据库和日志数据库，从而使你的 CI/CD 错误分类流程更有效率和高效。