通过渐进式发布最小化交付风险

引言

微服务

微服务（也称为微服务架构）是一种将应用程序构建为一系列独立部署、松耦合、围绕业务能力组织、由小型团队拥有、高度可维护和可测试的服务集合的架构风格。许多软件产品都采用了微服务架构。它或多或少是一种时尚。

降低发布风险：生产环境测试和渐进式发布

为了减轻发布压力并降低发布风险，在将新版本/功能发布给所有公众/最终用户之前，我们可以采取两个步骤：生产环境测试（Testing in Production）和渐进式发布（Progressive Delivery）。

生产环境测试 (TIP) 是一种软件开发实践，其中新的代码更改在实时用户流量上进行测试，而不是在暂存环境中进行测试。它是持续交付中发现的测试实践之一。

渐进式发布 提供了一种额外的策略来帮助降低意外问题影响用户的风险。它们通过仅将发布提供给特定比例的用户群来提供帮助。此比例最初可能很小，例如 10% 或 20%，并随着对发布信心的增强而增加。

解决方案 - 流量路由

一种解决方案是使用流量路由在当前版本和新版本之间进行渐进式切换。它通常使用服务网格（App Mesh, Istio, Linkerd, Open Service Mesh）或入口控制器（Contour, Gloo, NGINX, Skipper, Traefik）进行流量路由。

例如，我们有一个新版本的微服务“句子表情符号分类算法”。我们可以使用流量路由解决方案，从旧算法渐进式交付到最新版本。

例如，flagger.app 是实现该解决方案的出色工具。

解决方案 - 功能标志

功能标志 是一种现代工程技术，可将代码部署与功能发布解耦，让您控制谁在何时看到每个功能。

借助功能标志，您可以渐进式地将单个功能发布给特定用户群，或从特定用户群回滚，而无需重新部署。您可以为用户子集切换功能的开启和关闭。

有多种功能标志管理平台，例如 Launchdarkly、Unleash、FeatBit 等。在本文中，我将使用 FeatBit 作为实际示例的演示工具，因为只有 FeatBit 的开源版本支持我演示所需的一切。

组合解决方案

上表列出了流量拆分和功能标志之间的主要区别。

在许多公司中，这两种解决方案都被采用以最大程度地减少发布风险。它们结合了这两种解决方案来降低发布风险。以下是渐进式交付新版本和功能的步骤：

1. 使用新容器部署新版本服务。
2. 关闭新容器上部署的新功能的特性标志。
3. 使用流量路由解决方案渐进式地将新版本部署到生产环境。
4. 单独开启新功能。
5. 在生产环境中单独测试功能。
6. 渐进式地单独发布新功能。

步骤 1-3 可防止您交付无法执行的版本。
步骤 4-6 可防止您交付具有负面影响的新功能。步骤 4-6 还可以防止在只有一个新功能出现问题时（尤其是在只有一小部分用户受到影响时）回滚整个新版本。

实际案例

我将使用一个家政服务平台来演示如何实现功能标志以降低发布风险。

家政服务平台介绍

家政服务平台 (HKSP) 是一个由云提供商开发者社区开发的开源项目。HKSP 是一个类似 Shopify 的家政服务平台。家政公司可以在平台上注册并建立自己的家政“在线商店”（可以拥有自己的域名）。

场景与背景

HKOSS 开发了一个新版本，其中包含一些错误修复、新功能和 UI/UX 增强。通知模块是 VanveHKC（HKOSS 团队的客户之一）要求的新功能之一。他们希望在不冒风险影响客户最终用户的情况下交付此功能。新版本已更改了一些内容

• 家政人员办公室和客户中心已针对“通知”功能和其他新功能进行了更新。
• 已为“通知模块”功能添加了消息服务。
• 发布服务已针对“通知”和其他新功能进行了更新。消息中心需要调用新版本发布服务提供的服务。
• 还有其他与功能相关的内容。此处不详述。

待解决的问题

1. 不同的新功能将交付给不同的家政公司租户。“通知模块”功能将交付给“VanvesHSK”公司；其他功能将交付给其他公司。
2. 如果某个功能出现 bug，不应影响其他功能的交付。

交付策略

• 步骤 1. 使用功能标志包装新功能，并对所有用户关闭新功能。
• 步骤 2. 构建新版本并在线部署新版本。
• 步骤 3. 使用流量路由解决方案将流量从旧版本渐进式地转移到新版本。这可以防止新版本容器破坏现有服务。
• 步骤 4. 开启通知模块的功能标志，只允许 QA 团队和 Beta 用户访问此功能。在生产环境中进行测试。
• 步骤 5. 使用功能标志将“通知模块”渐进式地交付给 VanveHKC 的最终用户。

如果我们详细来看，根据具体情况，有几种解决方案可以采用。对于“通知模块”，我提出了以下解决方案：

• 在 Web 应用项目中添加一个通知功能标志。使用流量路由渐进式地在旧版本和新版本之间切换。
• 消息服务项目上没有功能标志。因为它是一个新的独立服务。
• 发布服务项目上没有功能标志，因为它是一个新的独立接口。使用流量路由渐进式地在旧版本和最新版本之间切换。

第 1 步 - 使用功能标志包装新功能

1.1 构建您的功能标志环境

您可以通过 FeatBit 的 GitHub 仓库 学习如何构建系统。

1.2 将功能标志 SDK 连接到项目

我们需要使用功能标志来控制通知功能。我们需要将功能标志 SDK 安装到您的项目中。在这里，我们演示如何在前端应用程序中安装功能标志 SDK。运行命令

npm install featbit-js-client-sdk

然后我们需要使用用户的基本信息来初始化 SDK。以下是屏幕截图：

1. Secret，连接到远程功能标志服务器的密钥。
2. API URL，远程功能标志服务器的地址。
3. 您将用于发布功能的配置用户信息。

引用

⚠️ 我不会在这里显示细节，因为这不是关于如何使用 FeatBit 的教程。如果您对 FeatBit 感兴趣，可以访问其 GitHub 页面获取更多信息。FeatBit 提供各种 SDK，支持 JavaScript、Java、C#、Python、Go 等。

1.3 使用功能标志包装和控制功能代码

在 Web 应用项目中，找到运行“通知模块”的代码，并使用功能标志来包装相关代码。下图显示了一个示例：

前端应用程序是用 VUE（一个 JavaScript/TypeScript 框架）编写的。如果标志代码 featureStore.flags['notification'] 执行并返回 true，则“通知模块”运行并在前端应用程序中显示。“通知模块”将不会执行，如果返回 false。

1.4 关闭功能标志

在策略的第 4 步之前，当新版本部署到生产环境时，不应将新功能“通知模块”交付给用户。我们需要在功能标志管理平台上进行配置。如下图所示，功能标志“notification”已关闭，并将返回 false 值。

第 2 步 - 构建新版本并将其部署到微服务系统

在此演示中，我们必须重建 前端应用 项目、消息服务、发布服务 等。然后我们将新版本部署到微服务系统上的独立容器中。

许多云解决方案、DevOps 工具和微服务框架都帮助我们实现此操作。我之前使用的大多数方法是将 Docker 化应用程序/服务镜像注册到在线注册中心，然后将镜像推送到在线容器服务（如 Azure Web App、AWS ECS、K8s 等）。

我不会在这篇文章中详细介绍。

第 3 步 - 使用流量路由渐进式部署新版本

一旦将新版本部署到微服务系统，您就需要一个框架来管理流量，以便您可以从旧版本切换流量路由到新版本。

您可以使用服务网格（App Mesh, Istio, Linkerd, Open Service Mesh）或入口控制器（Contour, Gloo, NGINX, Skipper, Traefik）来实现该目标。这取决于微服务架构。许多云还提供微服务的流量路由。

您可以尝试 Istio/flagger.app 组合解决方案进行实践。我不会在这篇文章中详细介绍。

第 4 步 - 生产环境测试

您还记得我们在第 1 步中编写的代码吗？我们需要配置门户 UI 来控制谁可以看到功能以及何时看到它。（用户只有在标志返回 true 时才能看到功能）。

开启通知模块的功能标志，只让 QA 团队和 Beta 用户查看（访问）此功能。在生产环境中进行测试。

• 如果用户属于 QA 组或“通知模块”的 Beta 用户之一，则 featureStore.flags['notification'] 应返回 true。
• 如果不是，则 featureStore.flags['notification'] 返回 false。

4.1 在 FeatBit 的 Segment 页面，创建一个新的 Segment QA 团队，在“Targeting users”选项卡下的“Including users”列表中输入 QA 成员，然后单击“Review and save”。

4.2 在功能标志列表页面，选择“Notification”标志，然后转到其 Targeting 页面。

a. 创建一个自定义的“Targeting rule”：如果用户属于 QA Segment，则功能标志 featureStore.flags['notification'] 返回 true；否则返回 false。

b. 您可以直接在 Individual targeting 选项卡中将 Beta 用户添加到 true 值列表中。如果用户属于此列表，featureStore.flags['notification'] 返回 true；否则返回 false。

4.3 完成设置并保存。以下是视频演示：

点击链接观看 视频 1 | 视频 2

引用

⚠️ 您可以查看 FeatBit 官方开源仓库以获取有关如何使用 https://github.com/featbit/featbit 的更多信息。

第 5 步 - 渐进式将“通知模块”交付给一个 HKC

渐进式地将“通知模块”功能发布给用户非常容易。您可以将默认规则更改为 serve: Rollout percentage，然后输入收到 true 值的用户百分比。如下图所示，我们将该功能发布给 10% 的用户。

5.1 单个租户中的渐进式发布

但是在此场景中，我们不会渐进式地将“通知模块”发布给所有最终用户，因为我们只想将新功能交付给要求该功能的业务客户（家政服务公司（HKC））。

因此，我们需要创建一个规则，只有 sho.saas-housekeeper.chouldbu 域下的用户才能看到“通知模块”。要渐进式地发布该功能，我们需要将规则配置为 serve: Rollout percentage。如下所示，“通知模块”已仅渐进式地交付给 sho.saas-housekeeper.chouldbu 域下的用户。

5.2 按自定义属性渐进式发布

家政公司的服务人员可以按小区域（例如，一条街道）进行组织/分组。我称之为区域团队。同一区域团队内的员工用户应具有相同的功能。如果我们按 userKey 发布功能，团队成员将难以协作。

因此，而不是按 userKey 识别的百分比发布，我可以使用自定义属性作为发布密钥。在此场景中，我使用 team-region 作为发布密钥。

现在，同一区域团队内的服务人员将获得相同的功能。

结论

对于认真为客户提供服务的团队来说，最大程度地减少交付风险始终至关重要。结合流量路由和功能标志解决方案有助于团队显着降低交付风险。

实际上，这种组合解决方案还将帮助您更快地发布新功能。因为您无所畏惧地发布新功能，风险得到了控制。这使您能够显着加快创新速度并增加业务收入。

为了最大限度地减少交付风险，我们还有很多工作要做。我将尝试写更多关于这个主题的文章。

希望这篇文章在您的实践中有所帮助。

历史

• 2023 年 1 月 27 日：初始版本