跳到主要内容
版本：V6.0

全链路灰度发布

灰度发布是一种软件发布策略，通过在生产环境中逐步引入新版本的应用程序，以降低风险并获得更可控的发布过程。它允许在一小部分用户或服务器上进行新功能或更新的试验，然后根据反馈和性能指标逐渐扩大发布范围。灰度发布可以帮助组织更好地管理和控制软件发布过程，减少潜在的影响和故障风险。

与传统的灰度发布相比，全链路灰度发布更进一步，它不仅考虑到应用程序层面的灰度发布，还包括了整个系统链路中的所有组件和服务。全链路灰度发布可以跨越多个环境和系统层次，包括前端、后端、数据库等，确保新版本的应用程序在整个系统链路中都得到逐步验证和部署。这种方式可以更全面地评估新版本与现有系统的兼容性和稳定性，并在各个环节上发现和解决潜在问题。

本文档将详细介绍分批次发布、基于 Header 的匹配规则、全链路灰度以及监控和回滚等全链路灰度发布的核心功能。您将了解如何准备环境、创建发布版本、制定灰度发布策略以及监控发布结果。我们还会提供一些最佳实践和建议，帮助您优化全链路灰度发布的配置和操作，以实现更高效、可靠的发布流程。

主要功能​

分批次发布​

gray-status

全链路灰度发布支持将新版本应用程序分批次引入生产环境，通过将新版本应用程序运行起来，逐渐将流量切到新版本应用中的方式使您能够在控制范围内评估新版本的稳定性和性能，并及时处理可能出现的问题。

  • 定义批次和流量比例：在进行分批次发布时，您可以根据需求和资源的可用性定义需要发布的批次和每批次的流量比例。较多的批次规模有助于平滑升级，控制发布过程中的风险，使您能够更好地监控新版本的性能和稳定性。

  • 监控和评估：在每个批次的发布过程中，您应该密切监控关键指标，如响应时间、错误率和新旧版本流量比例等。这将帮助您及时发现潜在问题并采取必要的措施。同时，还应该了解用户反馈，以了解新版本的体验和满意度。这些监控和评估数据将为后续批次的发布和决策提供重要依据。

  • 问题处理和回滚：在进行分批次发布时，可能会出现一些问题或异常情况。在这种情况下，您应该有一个明确的问题处理和回滚计划。如果在某个批次中发现了重大问题，您需要及时停止该批次的发布，并迅速回滚到之前的版本。这将帮助您最小化潜在的影响，并确保系统的稳定性和可用性。

基于 Header 的匹配规则​

您可以根据请求的 Header 信息，如用户标识、设备类型等，将特定请求路由到新版本或旧版本的应用程序。这种灵活的匹配规则使您能够针对不同用户或条件进行细粒度的灰度控制，确保只有特定用户或请求满足条件才能访问新版本。以下是关于基于 Header 的匹配规则的详细说明：

  • 定义匹配规则：在使用基于 Header 的匹配规则时，需要定义一组要匹配的 Header 键和相应的值。这些匹配规则可以基于业务需求来定制，例如特定的用户群体、设备类型、地理位置等。目前支持精准匹配和正则匹配。您可以指定一个或多个 Header 键和相应的值进行匹配，以便将请求路由到符合条件的新版本应用程序。

  • 灵活性和精确性：基于 Header 的匹配规则支持多个 Header 同时满足条件路由新版本，或满足其中之一即可路由到新版本。您可以实际需求，定义特定的 Header 。使请求精确地路由到不同的版本应用程序，实现细粒度的灰度发布控制。

全链路灰度​

全链路灰度发布涵盖了整个系统链路中的所有组件和服务，确保新版本应用程序在整个系统中的各个环节都得到逐步验证和部署。它可以跨越前端、后端、数据库等多个层次，确保新版本与现有系统的兼容性和稳定性。全链路灰度发布通过逐步替换和验证每个组件，确保新版本的应用程序在整个系统链路中无缝运行。以下是全链路灰度的示意图：

如上图所示，一个应用中有 A->B->C->D->E 五个服务组件，灰度流量从 A 进入时，由于只有 B 和 C 有灰度版本，所以灰度流量会在 B 和 C 的灰度版本中路由，而对于组件 D 和 E ，由于没有灰度版本，所以灰度流量路由到基础版本中去。这样就建立了两条逻辑上隔离的流量链路。这样在微服务数量较多时，可以直接减少服务的部署数量，降低部署成本。并且由于流量隔离，可以更好的控制新版本的风险和影响范围。

监控和回滚​

gray-metrics

全链路灰度发布提供监控和回滚功能，以确保新版本的应用程序在灰度发布过程中的稳定性和性能。您可以实时监控发布的各个阶段，包括流量分发、响应时间、错误率等关键指标。如果出现问题，您可以及时回滚到旧版本，以最小化潜在影响。

  • 实时指标监测：全链路灰度发布提供实时的监测功能，用于监测新版本应用程序在灰度期间的性能指标和运行状态。这些指标包括响应时间、错误率、吞吐量等关键性能指标。

  • 可视化仪表板：以上关键性指标均通过可视化仪表板进行展示，以便您可以直观地查看新版本应用程序的性能趋势和指标变化。这样，您可以快速识别任何异常情况或性能下降，并及时采取措施解决问题。

  • 快速回滚：在发现问题或出现意外情况时，您可以迅速将流量切回到旧版本应用程序。这样可以最大程度地减少对用户的影响和业务的中断，并确保系统的稳定性。

使用手册​

环境准备和配置​

全链路灰度的关键是需要将灰度流量的标签在多个组件之间进行透传，所以为了让标签的传递对应用无感，以及让灰度流量按标签进行路由。您的应用程序需要满足以下条件：

  • 入口组件使用了 Gateway API：Gateway API 解决了 Ingress 可移植性问题，正在逐步成为下一代流量标准。目前全链路灰度发布的流量规则也是建立在这基础之上的。

  • 支持分布式链路追踪：在分布式链路追踪技术中，traceID 标识一个完整的调用链，链路上的每一个请求，都会携带上对应的 traceID。而标签透传就是建立在这个基础之上的。

  • 应用启用 Istio 治理模式：Istio 主要提供灰度流量按标路由以及服务之间的治理能力。

创建和管理发布版本​

通常情况下，为了保证有一个可靠的交付物，我们会使用 Rainbond 的应用模版来管理整个应用的版本，在 Rainbond 中应用模版通常包含以下几项：

  • 应用标识和命名：为应用模版提供了一个易于识别和管理的名称。可以实现企业数字化资产的积累复用。

  • 版本元数据：包含了每个发布版本的版本号、发布日期、作者、变更摘要等信息。这些元数据可以帮助追踪和识别每个版本的关键属性和历史信息。

  • 版本镜像：包含了发布版本中所有组件的镜像，这些不可变的基础镜像可以保证版本的一致性，避免混乱。

可以参考应用模版持续交付文档，发布新的应用模版。当应用有新版本后，可以在应用视图的 待升级 一栏，看到可升级版本。后续该版本将作为灰度发布的新版本。

制定和配置灰度发布策略​

当有了可升级的新版本之后，我们需要设置该应用的灰度发布策略。这一步主要是确定灰度发布的目标和范围，配置灰度发布的规则和条件，以控制发布版本在灰度环境中的分发和升级，确保发布版本仅在指定的灰度目标中可见和可访问。具体操作步骤如下：

  1. 在应用视图，点击左侧边栏的 灰度 按钮，可以进入灰度策略设置页面。

  2. 在灰度策略设置页面，首先选择入口组件，这里是灰度流量的来源。确认好入口组件和其对应的入口流量规则以后，可以选择设置一个或多个 Header 匹配规则，这里的匹配规则可以保证灰度流量只路由到灰度版本。

  3. 匹配规则设置完成后，在下方继续设置发布批次，默认最终流量比例为 100%，你可以在中间设置多个批次及不同的流量比例。请注意：如果设置了 Header 规则，那么携带 Header 的流量将会 100% 路由到新版本，只有未设置 Header 规则的流量才可以按流量比例路由到新版本。

进行灰度发布​

  1. 在灰度策略设置好以后，我们需要在应用视图的 待升级 一栏，找到可升级的版本，点击 升级，此时对于有变更的组件，将会重新构建并进入灰度状态。

  2. 确认 升级 之后，将会跳转回应用视图，此时在左上角应用状态，可以看到当前流量比例和批次信息，点击 查看详情 可以获取详细监控报表。

  3. 当处于灰度发布中后，我们可以尝试按照之前的匹配规则去请求服务，此时灰度流量应该只在灰度环境中传递，只有当某个服务不存在灰度版本时，才会请求到默认版本。

监控和分析发布结果​

监控和分析发布结果是确保全链路灰度发布成功的关键环节，只有对发布过程中收集到的数据进行分析和比较，发现潜在的问题、才能判断是否继续发布或回滚。

  1. 应用已经处于灰度中后，在应用视图，点击左侧边栏的 灰度 按钮，可以再次进入灰度策略设置页面。此时默认展示应用灰度状态，其中包含当前批次、新旧版本流量比例、请求错误率、吞吐率、请求总数等图表。

  2. 通过该图表信息，可以持续观察灰度状况，如果无问题，可以尝试增加流量比例，在右上角点击 下一批 即可。

  3. 如果发现指标异常，如请求错误率过高、响应时间过慢等情况，那么可以在右上角点击 回滚，快速恢复到之前状态。