关于devops:GitOps-实践之渐进式发布

** 本文作者：陈钧桐
腾讯云 CODING DevOps 高级解决方案架构师 **，从事多年技术布道工作，对于云原生时代下企业数字化转型、IT 与 DevOps 建设、价值流体系搭建等有丰盛的教训，曾为多家大型企业提供征询、解决方案以及内训服务。既关注工程师视角的云原生开发建设与最佳实际落地，也关注管理者视角的过程治理与研发效力晋升。

本文基于陈钧桐老师在 2023 年中国 DevOps 社区峰会·武汉站上的演讲内容进行创作，其在此次峰会中被评为“十佳讲师”，并被社区认可为优良的常识分享者。

导语

随着云计算和微服务架构的遍及，软件开发和运维的环境变得越来越简单，在咱们谋求开发和交付的最佳实际时，GitOps 的概念应运而生，并迅速取得了宽泛的认可。在许多无效的 GitOps 实际中，渐进式公布作为一种危险管理策略，扮演着重要的角色。它容许咱们逐渐公布新的服务版本，可能在保证系统稳固的同时，尽快地将新性能或修复带到生产环境。具体实现的策略有多种，包含滚动降级、蓝绿部署、灰度部署、金丝雀公布，以及 A/B 测试等。

在这篇文章中，咱们将探讨如何将 GitOps 和渐进式公布联合起来，以实现在云原生环境中的 高效、牢靠和平安的服务部署。咱们将会比拟剖析不同的渐进式公布策略，介绍支流的云原生工具，以及应用 CODING 自研的云原生利用治理平台 Orbit 进行优雅实现。咱们心愿这篇文章能为那些心愿在本人的软件开发流程中引入 GitOps 和渐进式公布的读者提供有价值的信息和启发。

注释

GitOps 是由 Alexis Richardson 在 2017 年首次提出的，该模型主张将 Git 作为 ” 繁多事实起源 ”（Single Source of Truth）来治理和同步开发和生产环境，而不是应用传统的基础设施治理和部署形式。这个思维提出后，引发了一场对云原生部署和运维模式的探讨和反思。

GitOps 的概念在 2018 年开始被更多的组织和云服务提供商承受和利用，它们都开始摸索如何将 GitOps 集成到本人的产品和服务中。例如，亚马逊、谷歌和微软等云服务提供商都在他们的 Kubernetes 服务中集成了 GitOps 工具。

到了 2020 年，为了进一步推广 GitOps 理念和实际，云原生计算基金会（CNCF）发表成立了 GitOps 工作组。这个工作组由多家云服务提供商和软件公司组成，他们一起制订了一套标准化的 GitOps 最佳实际和准则。

2021 年，GitOps 成熟度模型诞生，这是 GitOps 工作组和社区共同努力的后果。该模型提供了一种量化和评估 GitOps 施行的办法，从而帮忙组织更好地了解和施行 GitOps。

GitOps 能够简练地概括为以下三个准则：

• 代码仓库是整个零碎的惟一实在起源（Single Source of Truth）。
• 所有的变更流动，包含创立、批改和销毁等，都以代码仓库为外围来进行。
• 所有的变更都必须是可察看和可验证的。

当然，GitOps 除了上述的三个根本准则之外，实际中通常还须要遵循一些前提条件和最佳实际，这包含但不限于：

1. 代码和配置拆散：在传统的利用部署中，代码和配置往往混在一起，这使得环境间的切换变得艰难。在 GitOps 的实际中，咱们举荐将代码和配置拆散。这意味着利用的代码和其运行配置（例如环境变量，数据库连贯等）应该在不同的仓库或者至多在不同的分支中。这样的做法不仅可能使得代码和配置的变更更加清晰，同时也可能防止因为配置谬误导致的代码谬误。
2. 继续交付：继续交付是 GitOps 的一个重要局部。这意味着每一次提交都会通过自动化的构建、测试和部署流程，以便更快、更频繁地向生产环境部署新的更改。
3. 清晰的审计轨迹：因为所有的变更都通过代码仓库进行，因而在 GitOps 中，咱们有一条清晰的审计轨迹。这能够帮忙咱们更好地追踪变更的起源，更好地了解每一次更改背地的起因。
4. 自动化和自愈：在 GitOps 中，咱们尽可能地自动化所有操作，并在零碎产生偏离预期状态时尽快进行修复。这通常通过申明式的基础设施治理和 Kubernetes 的自愈能力来实现。
5. 权限治理和拆散职责：为了防止单点故障和进步安全性，GitOps 推崇权限的最小化准则和职责拆散。这意味着每个角色只应具备实现其工作所需的最小权限，并且应该将不同的职责调配给不同的角色或团队。
6. 可察看性和反馈：GitOps 不仅须要对变更有清晰的可察看性，同时也须要有反馈机制，让开发者和运维人员晓得他们的更改是否胜利利用，以及零碎的理论运行状态。这通常能够通过日志、监控和告警零碎来实现。

咱们还能够用一条简洁的公式来解释 GitOps：基础设施即代码（Infrastructure as Code，IaC）+ 合并申请（Merge Request）+ 继续集成 / 继续部署（Continuous Integration/Continuous Deployment，CI/CD）。

以 CODING 平台举例，在这个流程中，开发人员首先会将代码提交到 CODING 代码仓库。而后，代码评审人员会审查这些代码。只有在代码评审通过后，提交的代码能力被合并到主分支。一旦新代码被合并到主分支，就会触发相应的 CODING 继续集成流水线，主动构建和推送 Docker 镜像到 CODING 制品仓库。随后，当 CODING 的继续部署模块检测到新的 Docker 镜像被推送到制品仓库，就会主动触发相应的继续部署流水线，将新的 Docker 镜像公布到 Kubernetes 集群。

对于运维人员，他们无奈像以前那样间接应用 kubectl apply 命令来操作 Kubernetes 集群。他们须要通过在 CODING 代码仓库中提交更新的配置文件来批改配置。当这些配置文件通过审查并被合并到主分支后，CODING 的继续部署模块会检测到这些配置文件的变动，并触发相应的继续部署流水线，将新的配置公布到 Kubernetes 集群。

这种模式的长处在于，所有的权限管制都能够通过代码仓库进行集中管理，不再须要为所有的运维人员凋谢 Kubernetes 集群的拜访权限，从而大大 进步了集群的安全性。此外，因为所有的操作都围绕着代码仓库进行，因而每一次操作都会留下提交记录，便于咱们追溯问题源头。

总的来说，GitOps 是古代 DevOps 的要害实际，它强调以 代码为外围 进行所有操作，并确保所有变更的 可观测和可验证性 ，晋升了零碎的 透明度、可管理性和安全性。

在这篇分享里，咱们探讨的主题聚焦在 GitOps 实际交付的最初一公里，即如何将应用服务公布部署到对应环境上，以满足业务场景的需要。对于这个话题，社区里曾经积淀了不少优良的实际，接下来，让咱们梳理下常见的部署策略。

滚动公布

✅ 无需停服，用户体验好。
❌ 版本升级和回退用时较长。

“ 滚动公布 ” 是一种常见的部署策略，它个别波及以下步骤：逐渐取出一个或多个服务器进行服务，执行更新，而后更新实现后，再从新投入使用。这一过程循环进行，直到集群中所有的实例都被更新至新版本。

滚动更新的劣势在于，整个更新过程不会中断服务，因而可能提供良好的用户体验。同时，滚动更新还能够在放弃服务连续性的同时，逐渐替换旧版本实例，这能够无效地升高因更新带来的危险。

然而，滚动更新也有其毛病。因为它是一一降级实例，因而整个更新过程可能耗时较长，特地是在集群规模较大时。此外，如果新版本呈现问题，执行回滚操作也须要破费较长的工夫能力实现，这可能导致系统在此期间处于不稳固状态。

蓝绿公布

✅ 降级切换和回退速度十分快。
❌ 如果新集群出问题，影响面较大，须要两套机器资源，老本较高。

“ 蓝绿公布 ” 是一种部署策略，它依赖于线上的两套完全相同的集群环境。这两套环境被标记为蓝色和绿色，通常在初始状态下，所有的流量都会被路由到绿色集群。当咱们筹备公布新版本时，咱们会在蓝色集群上部署新的利用版本。一旦新版本在蓝色集群上部署结束并通过测试，咱们就将所有流量一次性切换到蓝色集群，以实现零碎的降级切换。

蓝绿公布的劣势在于，因为咱们有两套独立的集群，并且流量能够一次性切换，因而零碎的降级和回退操作都能够疾速实现。这种策略也使得咱们有短缺的工夫在蓝色集群上验证新版本的稳定性和性能，升高了公布新版本带来的危险。

然而，蓝绿公布也有其毛病。首先，因为流量的切换是一次性实现的，如果新集群呈现问题，那么所有用户都会受到影响，影响面较大。其次，因为蓝绿公布须要保护两套齐全一样的环境，因而这会带来更高的老本，包含硬件资源、保护工作以及复杂性等方面的老本。

金丝雀公布

✅ 平滑降级，危险小，用户无感知。
❌ 流量无差别地导向新版本，可能会影响重要用户的体验。

“ 金丝雀公布 ” 是对“蓝绿公布”的一种优化策略，它借鉴了矿工应用金丝雀作为煤矿安全监测的办法。这种公布策略先将一小部分流量从以后版本的集群（咱们称之为绿色集群，或者 V1）切换到新版本的集群（咱们称之为蓝色集群，或者 V2）。这样咱们就能在生产环境中对新版本进行测试。

金丝雀测试的复杂程度可大可小。简略的金丝雀测试可能只波及手动验证，而简单的金丝雀测试可能须要装备欠缺的监控基础设施，通过监控指标反馈，察看金丝雀环境的健康状况，作为后续公布或回退的根据。

如果金丝雀测试胜利，咱们会将残余的流量全副切换到蓝色集群（V2）。如果金丝雀测试失败，咱们将进行流量切换，将新版本申明为公布失败，并进行相应的故障排查和修复。

与蓝绿公布相比，金丝雀公布的劣势在于它在生产环境中减少了一个验证过程，能够升高新版本呈现问题的危险和影响面。因为存在两套集群，咱们能够在不进行服务的状况下平滑降级，使整个公布过程对用户无感知。

然而，金丝雀公布也有毛病。在新版本公布过程中，流量会被无差别地路由到新版本，如果新版本存在问题，可能会影响那些被路由到新版本的重要客户的体验。

A/B 测试

✅ 能够对特定的用户群体提供新版本的服务，如果呈现故障影响范畴小。
❌ 公布周期绝对较长。

“A/B 测试 ” 是一种同时运行多个程序版本的在线测试策略，它依据用户申请的元信息将流量动静路由到不同的版本。换句话说，咱们能够依据申请的内容来决定将流量路由到哪个版本。以一个具体的例子来阐明，咱们能够设定规定，将 User-Agent 值为 Android 的申请（即来自安卓零碎的手机申请）路由到新版本，而将来自其余零碎（例如 iOS）或其余设施（例如电脑端）的申请持续路由到旧版本。

这样做的劣势在于，咱们能够比照两个版本的体现，从而确定哪个版本更受用户欢送，哪个版本的用户反馈更好。

AB 测试的次要长处是咱们能够依据申请信息进行动静路由，针对特定的用户群体提供新版本的服务。这样如果新版本呈现故障，其影响的范畴也会绝对较小。

然而，AB 测试也有其毛病：因为须要同时部署并保护多个版本，并且须要破费一段时间来察看不同版本的运行状况并收集用户反馈，因而整个公布周期可能会比拟长。

当初让咱们对这些常见的部署策略做简要的比照剖析。

1. 停机重建（Recreate）：这种办法不反对新旧版本并行运行，不能进行实在流量验证，公布效率低，但在一些特定的状况下可能比拟牢靠。
2. 滚动降级（Rolling Updates）：这种办法能够在不停机的状况下进行部署，但须要管制好滚动降级的速度以防止资源过载。它容许新旧版本并行运行一段时间，流量管制粒度较低，能够进行实在流量验证，公布效率和公布可靠性中等。
3. 蓝绿部署（Blue-Green Deployment）：它容许新旧版本并行运行，流量管制粒度较高，能够进行实在流量验证，公布效率和公布可靠性较高。
4. 灰度部署（Canary Deployment）：这种策略容许新旧版本并行运行，流量管制粒度较高，能够进行实在流量验证，公布效率和公布可靠性较高。
5. A/B 测试（A/B Testing）：它能够在新旧版本并行运行的状况下进行，流量管制粒度较高，能够进行实在流量验证，公布效率和公布可靠性取决于测试的具体实施。
6. 主动渐进式（Automatic Progressive）：这种策略联合了多种部署策略的长处，通过自动化的工具和流程，逐渐推出新版本的利用，以缩小危险。它容许新旧版本并行运行，流量管制粒度较高，能够进行实在流量验证，公布效率和公布可靠性较高。

在云原生环境中，应用程序的更新和部署是常见且要害的操作，因而 Kubernetes 作为容器编排零碎，内置了一些根底的公布策略以满足大多数常见的部署需要，其次要是通过 Deployment 和 StatefulSets 资源来实现的：

1. 停机重建 (Recreate)：在这种策略中，Kubernetes 会首先进行所有旧的 Pod，而后启动新的 Pod。这种策略会导致应用程序在部署过程中呈现一段时间的停机。
2. 滚动更新 (Rolling Update): 这是默认的部署策略。在这种策略中，Kubernetes 会逐步将新的 Pod 替换旧的 Pod。这种策略能够确保在部署过程中应用程序始终保持运行，不会呈现停机工夫。咱们能够通过设置 maxUnavailable 和 maxSurge 来管制滚动更新的速度。

滚动更新包含一系列明确定义的检查和操作，用于降级由 Deployment 治理的任意数量的正本。Deployment 资源编排 ReplicaSets 以实现滚动更新，下图显示了这种机制的工作原理：

每当更新 Deployment 资源时，默认状况下会启动滚动更新机制。其将创立一个新的 ReplicaSet 来解决应用在 spec.template 中定义的新更新配置创立的 Pod。这个新的 ReplicaSet 不会立刻启动所有三个正本，因为这会导致资源耗费激增。因而，它会创立一个独自的正本，验证其是否就绪，将其连贯到服务池，最初才终止具备旧配置的正本。

3. 蓝绿部署 (Blue/Green Deployments): 尽管 Kubernetes 自身并不间接反对蓝绿部署，然而咱们能够通过应用 Service 和两个不同的 Deployment 来实现相似的性能。咱们能够创立一个新的 Deployment（绿色）来部署新版本的应用程序，并将 Service 切换到新的 Deployment，而后删除旧的 Deployment（蓝色）。

4. 金丝雀部署 (Canary Deployments): Kubernetes 自身也不间接反对金丝雀部署，然而咱们能够通过手动治理多个 Deployment 和 Service 来实现。咱们能够创立一个新的 Deployment 来部署新版本的应用程序，并将一部分用户的流量路由到新的 Deployment，而后逐步减少流量比例，最初将所有流量都路由到新的 Deployment。

尽管 Kubernetes 提供了这些根本的公布策略，但在理论的生产环境中，咱们可能须要更高级和灵便的公布策略。比方 主动回滚、度量剖析和简单的流量路由 规定，从而可能更好地管制和管理应用程序的公布过程。因而社区里诞生了许多工具，其中比拟风行的有 Argo 提供的 Rollouts，以及 Flux 提供的 Flagger。

Argo Rollouts 由 Argo 我的项目开发和保护的，Argo 我的项目是一个开源我的项目，专一于 Kubernetes 的工作流、CI/CD、以及利用部署。Argo 我的项目在云原生计算基金会（CNCF）的孵化阶段，背地的次要公司是 Intuit。Argo Rollouts 的产品理念是利用 Kubernetes 的原生个性，提供灵便、可配置的渐进式部署形式。通过引入新的自定义资源定义（CRDs），Argo Rollouts 扩大了 Kubernetes 的部署性能，使得用户可能在 Kubernetes 环境中实现更简单的部署策略。实现原理上，Argo Rollouts 引入了新的资源类型 Rollout，用户能够应用 Rollout 资源定义部署策略和配置。当 Rollout 资源发生变化时，Argo Rollouts 控制器会依据定义的策略主动执行部署。

Flux 也是一个开源的 GitOps 工具，专一于在 Kubernetes 上实现继续交付。Flux 我的项目也是 CNCF 的孵化我的项目，背地的次要公司是 Weaveworks。Flagger 的产品理念是通过自动化实现渐进式交付，并最小化人为干涉。Flagger 的指标是提供一种主动、平安且可察看的形式来推出新的应用程序版本，以便在不影响用户体验的状况下进行继续交付。实现原理上，Flagger 通过主动更改 Kubernetes 服务对象的流量权重，逐渐将流量转移到新版本的服务，从而实现渐进式交付。在此过程中，Flagger 会继续监控应用程序的性能指标，如果发现任何异样，它将主动回滚到之前的版本。

如图所示的表格，是对 Argo Rollouts 和 Flux Flagger 做的简要比照剖析。比方在负载侵入的角度上，Rollouts 属于齐全侵入，而 Flagger 中的原对象将被视作灰度验证对象，而真正对外裸露服务是其复制。比方对于部署过程中是否能够反复验证新版本，Argo 反对得十分好，而 Flux 尽管也反对，不过实质上是进行了一次新的部署。两者在其余层面上的能力也各有不同。

开展来说，两者都反对负载治理和简单部署，它们都提供像金丝雀和蓝绿这样的部署策略，并且反对运行时的流量宰割和切换性能。这些工具都能够整合开源服务网格软件，如 Istio, Linkered, AWS App Mesh 等，以及入口控制器，如 Envoy API 网关，NGINX，Traefik 等。它们还反对从监控或 APM 工具收集的度量的 CRD 剖析，如 Prometheus, Datadog, Stack driver, Graphite, 和 New Relic 等。

在平安和策略集成方面，Argo CD 和 Flux CD 都提供了身份验证、受权和机密治理来加强平台的安全性。然而，Flux 次要依赖于 Kubernetes 的根底 RBAC，Argo 则反对利用权限更细粒度，并反对对没有 Kubernetes 资源拜访权的生产零碎的只读模式。在治理方面，Flux 没有提供将平安和合规查看作为软件交付策略的局部。Argo CD 提供了最小的能力，确保所有的应用程序都通过了查看才被部署到指标集群。在易用性方面，Flux 没有提供开箱即用的 UI，而 Argo 则提供了杰出的 UI。对于复杂性，Argo Rollouts 提供了大量的选项和配置来适应各种部署需要，包含流量路由，试验，剖析，抗亲和性配置，以及灰度部署中的提早设置等，然而这些配置可能减少了其应用的复杂性。

总的来说，Argo Rollouts 和 Flux Flagger 都是弱小的 GitOps 工具，然而它们的要害长处和应用场景有所不同。Argo 可能更适宜须要更高级平安和策略集成，以及更全面可察看性的环境。而 Flux 可能更适宜那些心愿简化部署和治理过程的团队。在抉择哪一款工具时，须要思考到具体的需要和应用场景。

腾讯云 CODING 是面向企业的一站式研发治理解决方案，许多客户依赖咱们的平台进行研发流程治理。因为服务始终处于应用中，咱们须要确保任何公布流动都简直无需停机，并且对用户简直无感知。

咱们的公布策略是每个月推出一个大版本，这些版本通常蕴含了新的个性。在正式公布之前，咱们会邀请局部用户进行试用和测试。在这个过程中，必须确保老用户的体验不会受到任何影响。因而，咱们须要反对按用户进行精细化的流量管制。当验证新版本没有问题后，咱们才会分批公布给付费用户。如果在公布过程中呈现任何问题，咱们须要有能力疾速进行回滚。

除了每月的大版本之外，咱们每天都会公布数次的轻量级补丁（Livepatch）。这些补丁通常不会经验灰度公布，但须要保障如果公布失败，可能疾速进行回滚。对于局部服务，有时候会抉择跳过灰度公布，因而咱们的零碎须要可能反对疏忽指定服务的公布。

此外，每个月公布的版本个性须要散发到不同的渠道，因而咱们的公布零碎须要具备自动化收集这些个性并造成公布阐明（Release Notes）的能力。

这些要求不仅确保了咱们的服务具备高可用性，也保障了咱们可能在放弃高效公布的同时，最大水平地升高任何可能的危险。

依据以上业务诉求，主动渐进式公布显然成为了最适宜的部署策略，它能够为进一步优化公布过程提供可能性，实现真正的自动化、无感知的公布，最大水平地晋升用户体验。

尽管 Argo Rollouts 和 Flux Flagger 曾经提供了大量反对渐进式公布的性能，然而依据现有的需要，这两个工具仍存在一些无奈满足的中央。

1. 负载侵入问题：在 Argo 和 Flux 中，进行灰度公布或者 A/B 测试时，咱们须要在服务层面退出相应的逻辑来反对流量切分，这在肯定水平上减少了利用的复杂度和开发累赘。
2. 流量平滑问题：Argo 和 Flux 在进行版本升级时，流量切换的过程并非齐全平滑。有可能导致在切换过程中呈现流量抖动，影响服务的稳定性。
3. 配置复杂度：Argo 和 Flux 的配置绝对较简单，这对于开发和运维人员来说，须要破费更多的工夫去了解和把握，减少了应用门槛。
4. 全链路灰度缺失：Argo 和 Flux 对于全链路灰度的反对并不欠缺，难以满足简单的灰度公布需要，如依据用户个性进行精细化的流量路由。
5. 版本治理问题：在应用 Argo 和 Flux 进行公布时，存在反复验证新版本的问题，而且版本管理机制绝对较弱，对于频繁的版本公布可能会带来肯定的困扰。
6. 交付复杂度：Argo 和 Flux 的设计初衷是针对软件工程中的服务利用交付，它们次要解决的是技术层面的问题。然而，交付不仅仅是软件工程中的服务利用交付，也是业务层面的用户价值交付。这波及到如何将新版本的个性精确地、无效地传递给指标用户，如何在保障用户体验的前提下，依据项目管理中的产品需要来进行灵便的版本控制和公布策略制订。这是一种对业务了解和业务需要的深刻开掘，须要咱们在技术实现之外，更多地去关注业务价值的实现和优化。这种复杂度和轻微之处的解决，是两者以后的设计和实现所无奈笼罩和反对的。

基于前述起因，常见的开源工具比方 Argo 和 Flux 的以后设计和实现均未能满足咱们的业务需要。因而，咱们构建了本人的主动渐进式公布解决方案。它的流程能够简要地概述如下：

整个流程形成一个继续和谐（Reconcile）循环。首先，进行筹备阶段，对准备上线的金丝雀工作负载（pre canary workload）进行配置和部署。随后，灰度负载的比例逐步进步（pre canary traffic）。接着，咱们减少导向金丝雀版本的流量比例，即 post canary traffic 阶段。

在这一步后，零碎会验证灰度公布是否胜利。如果检测到问题或失败，零碎将退回到 pre canary workload 阶段，否则，流程将继续进行。

接下来是 pre promote 阶段，筹备降职新版本到正式环境。而后，在降职（promote）阶段，新版本将在正式环境中部署。紧接着是 pre route traffic 阶段，筹备将全副流量切换到新版本。正式流量切换（route traffic）阶段开始后，所有流量将指向新版本。

在 pre finalize 阶段，咱们筹备实现所有流程并进行清理。当整个 Reconcile Loop 完结后，如果须要回滚，那么 pre rollback 阶段将开始，并随后进行 post rollback，以复原到初始状态。

总的来说，咱们对灰度公布流程进行了深度定制和优化，让其更合乎咱们的业务场景。

针对上述流程，能够从资源的视角进行解析。整个部署过程能够拆分为以下几个环节：

1. 预部署阶段：创立新的 “ 金丝雀 ” 命名空间（canary namespace），此时，其外部的 pod 工作负载比例为 0%。
2. 第一阶段灰度部署：逐渐减少 canary namespace 的工作负载比例，例如将 pod 数量进步到 15%。同时，调整流量权重，让一部分流量路由到 canary namespace，以便在此环境中验证新版本的性能和稳定性。
3. 第二阶段灰度部署：如果第一阶段的验证没有问题，咱们将持续进步 canary namespace 的工作负载比例和流量权重，以进行更大范畴的验证。
4. 正式部署：在两轮灰度测试都胜利通过后，咱们将在原生产环境的 “production” 命名空间内部署新版本的利用，这一过程称为升级。在升级之后，所有的流量都将被切换到 production namespace，这意味着用户将开始应用新版本的服务。
5. 清理阶段：实现新版本的部署后，咱们将对 canary namespace 进行清理。

不同于传统的蓝绿部署形式，这一过程并不是一次性切换所有流量，而是在两轮灰度验证胜利之后，再对原生产环境进行升级。这种设计的理念在于，传统的蓝绿部署形式在屡次切换之后，因为每次生产环境都被切换到新的命名空间，可能会导致混同，使咱们难以确定用于生产环境的命名空间是哪一个。而通过固定对 “production” 命名空间进行继续升级，咱们能够确保这个命名空间始终被用于生产环境，而其余命名空间被专用于进行灰度测试，防止了混同带来的潜在危险。

基于上述设计的解决方案，咱们参考优良开源计划，实现了自主研发的利用公布引擎——Orbit。Orbit 以产品化的模式，提供了一系列先进而灵便的公布策略，比方分批进行蓝绿部署和灰度部署等。此外，它还有能力反对对指定服务履行“疏忽灰度”的操作。这些性能的设计和实现，使得 Orbit 在满足简单公布需要方面体现出显著的劣势。

Orbit 的设计理念重视实际和翻新，它有着一套健全的变更审核机制，确保公布的准确性和可靠性。公布流程在满足自动化的同时，保留了足够的可控性，用户能够依据理论须要灵便地治理和调整公布流程。

在公布过程中，Orbit 反对对变更进行预执行，确保公布过程的 准确性和可靠性。在整个部署过程中，每一个变更都会被具体记录并在须要时进行审核。

在自动化的流程中，Orbit 特地增设了人工确认环节，以人工审核的形式升高公布危险，防止因自动化过程中的未预期事件导致的问题。这样既保留了自动化带来的效率，又兼顾了人工审核在危险管制上的劣势。

Orbit 也具备疾速回滚的性能，一旦在公布过程中或新版本上线后发现问题，能够迅速回滚到旧版本，最大水平减小问题带来的影响。

此外，Orbit 还 主动治理和清理灰度环境。在新版本胜利公布并稳固运行后，Orbit 能主动清理无需再用的灰度环境。这意味着团队无需手动进行清理工作，加重了保护累赘，同时确保了资源的正当利用和环境的整洁。

总的来说，Orbit 以其全面且灵便的设计，为利用公布提供了一站式的解决方案，从变更执行到环境清理，每个环节都体现出其 高效、稳固和牢靠 的个性。

此外，Orbit 进一步深入了对业务价值交付的了解，它不仅仅是一个工具，而更像是一个桥梁，将技术层面的软件版本治理与业务层面的价值发明严密地联合起来。在 Orbit 的治理下，每一个公布版本都不再仅仅是代码的改变和镜像的更新，而是间接反映了特定的用户故事和业务价值的交付。这种形式将技术与业务融为一体，提供了一种全新的视角来对待利用的公布治理。

通过这种形式，Orbit 可能帮忙企业更加精准地理解每一个版本变更背地所蕴含的业务价值，使得技术团队与业务团队之间的沟通和了解变得更为晦涩。此外，通过将业务价值映射到具体的版本变更中，也使得企业可能更加明确地理解和评估每次公布带来的实际效果，从而实现更为无效的产品迭代和继续优化。这种创新性的设计理念，使 Orbit 不仅在利用公布治理的全面性和深度上具备显著劣势，更在价值交付的成果上实现了显著的晋升。

不同的工具领有各自的长处和个性。这里，咱们将针对 Orbit、Argo Rollouts 和 Flux Flagger 这三款工具进行深刻的比照和剖析，尤其是聚焦于咱们自研的 Orbit：

1. 反对的负载类型：Orbit 反对任意类型的负载，包含但不限于 Rollout 和 Flagger。相比之下，Argo 和 Flux 的反对范畴更为无限。
2. 侵入性：Orbit 的设计齐全无侵入，能够无缝地与现有环境进行集成。而 Argo Rollouts 则具备齐全的侵入性，可能须要对现有环境进行较大的调整。
3. 灰度正本指定：Orbit 容许用户指定灰度正本部署到特定的 namespace，提供了更大的灵活性。
4. 流量平滑度：Orbit 的流量平滑度能够通过配置进行调整，以满足不同的业务需要。而 Flux Flagger 在降职过程中可能无奈提供齐全平滑的流量切换。
5. 全链路灰度反对：Orbit 反对全链路灰度公布，能够更好地协调工作负载。而 Argo Rollouts 和 Flux Flagger 次要以繁多工作负载为粒度，可能较难进行全链路的协调。
6. 配置复杂度：Orbit 的根底性能可通过 UI 界面进行操作，高级性能可通过 yaml 文件进行申明，用户体验更敌对。而 Argo Rollouts 的配置可能较为简单，Flux Flagger 则须要配置灰度用 Service、TrafficRef 等。
7. 产品观测性：Orbit 的观测性杰出，用户能够通过 UI 界面对整个环境进行全局性的观测。相比之下，Argo Rollouts 也提供了具体的观测信息，但须要通过命令行进行操作，Flux Flagger 则未提供相干性能。
8. 版本治理：Orbit 的版本治理基于 Open Application Model (OAM)，与业务模型相结合。而 Argo Rollouts 次要基于 revision 进行版本治理，Flux Flagger 则不反对版本治理。
9. 业务价值交付的整合：Orbit 在业务层面的价值交付方面具备显著劣势。它整合了版本变更治理，可能自动识别并关联变更事项，实现公布的版本不仅仅是镜像的版本号，也蕴含了用户故事与业务价值的交付。这一点超过了 Argo Rollouts 和 Flux Flagger 的性能范畴，让公布过程与业务价值更严密地联合在一起。

在基于 Orbit 实际 GitOps 渐进式交付的流程中，开发人员须要将他们负责的代码、配置和 SQL 脚本等变更提交到代码仓库。业务代码的提交会触发继续集成（CI）流程，该过程将构建新的利用镜像，并将其存储在镜像仓库中。

此时，Orbit 的 GitOps 主动拣配引擎开始发挥作用。它会 继续监听利用制品库和代码仓库，主动拣配镜像、配置和 SQL 变更。这些变更不仅被整合到同一个版本领域里，还以可视化的形式在版本中展现，使得开发者或公布人员可能在版本公布前对所有变更进行审核。

接着，这些变更将通过 Orbit 的 All In One 公布引擎进行公布。该引擎将利用的所有变更进行聚合，并原子化、版本化地公布到多个环境中。这一过程保障了公布的 一致性和可靠性 ，缩小了因环境不统一而引发的问题。同时，Orbit 也反对基于版本进行原子化的回滚，进一步 晋升了公布流程的可控性和安全性。

总体来说，Orbit 通过 GitOps 主动拣配引擎和 All In One 版本化公布，实现了高效、精确和灵便的利用公布流程。开发者只需关注他们负责的代码、配置和 SQL 脚本等，而公布的 一致性、可靠性和可追溯性由 Orbit 提供保障，大大简化了公布过程，进步了工作效率。

GitOps 的实际不仅仅局限于交付阶段，其理念和办法同样能够使用到利用的建模和运维等其余生命周期阶段。Orbit 作为云原生利用全生命周期管理工具，能更好地实现 GitOps 全流程。

Orbit 提出了云原生架构下利用的三层架构模型，业务层申明了利用的根底元素，蕴含服务、服务配置和数据库脚本，交付层申明了利用的交付流程，资源层则声明了利用运行时的环境和基础设施，基于 Application as Code 实践将利用模型存储在代码仓库中，实现对立演进，可审计、可回溯。

除此之外，咱们基于 OAM 标准提供了视角拆散的解决方案，企业内少部分云原生专家通过服务模板去封装 k8s 的标准，通过运维插件去封装 k8s 生态的扩大能力，比如说资源限度、探针等 k8s 原生能力，或者是监控、链路追踪等 k8s 生态能力，云原生专家能够依据理论状况，规定生产环境必须开启资源限度、探针、监控等运维插件，落地云原生标准 ，研发同学基于服务模板和运维插件以可视化表单的形式填写业务参数即可实现服务的创立， 大幅升高云原生复杂性左移对研发的影响。

面对利用公布效率和可靠性的挑战，Orbit 的解决办法是 GitOps 主动拣配引擎和 All In One 版本化公布，开发者只须要专一本人负责的代码、配置和 SQL 脚本，Orbit 的 GitOps 主动拣配引擎会继续监听利用制品库和代码仓库，主动拣配镜像、配置、SQL 变更。

随后这些利用的变更物料会被咱们的 All in One 公布引擎聚合，并以可视化的形式在版本中体现，开发者或者发版人员在版本公布前能够对所有变更进行审核，确认无误后执行利用发版流程，将利用以 原子化、版本化 地公布到多个环境中，保障了多环境公布的一致性和可靠性，同时 Orbit 也能够基于版本进行原子化的回滚。

利用公布效率和可靠性的问题解决后，面对利用运维呈现的工具孤岛、视角割裂和数据断层的问题，Orbit 推出了以利用为核心的混合云对立观测立体，Orbit 自研 adapter 服务，对立解决监控告警、日志和链路追踪数据，并对每一种类型提供了一套数据规范，实现了观测工具的可扩展性，用户可自由选择 Orbit 官网反对的观测工具，也能够自行扩大其余观测工具。

adapter 模式屏蔽了观测工具的复杂性，在此基础上，咱们从新设计观测界面，并全副内置到利用的环境内，再联合利用模型，最终为用户呈现出以利用为核心，以研发为视角的观测产品，无是开源和云混合应用的场景，还是多云多环境场景，对于研发来说，均是在同一个利用中浏览，无需再切来切去费时费力，解决工具孤岛问题，同时，观测产品所出现进去的数据是以利用为核心的，也就是说，在这个利用内，通常仅能够看到以后利用内的观测数据，解决视角割裂问题。

面对数据断层问题，咱们须要建设观测工具之间的关联性，OpenTelemetry 技术的衰亡，给了咱们一条很好的通路，微服务架构下，链路追踪记录了一次用户申请所通过的全副节点以及上下文信息，使零碎数据具备业务性质，将链路追踪的惟一标识 TraceID 记录到日志和监控零碎中，不仅能够解决观测工具间的数据断层问题，还能够让整个观测数据具备业务属性，建设业务相干的对立观测立体。

目前 Orbit 开源生态兼容上，反对 Prometheus、Loki、EFK、Skywalking、Jaeger 等 支流开源观测产品，同时，为了保障用户在生产环境上观测工具的可靠性，咱们也对接了腾讯云云监控、利用性能观测和日志服务产品，为生产环境保驾护航。

只管 GitOps 是 DevOps 的重要实际之一，但咱们明确 DevOps 的畛域远不止于此。因而，Orbit 只是 CODING 平台中一部分产品能力的体现。

权威机构 Gartner 认为，在云原生环境下，咱们须要建设面向服务的 DevOps 理念，通过平台级能力为服务团队提供 DevOps 的反对。这种模式被认为是最适宜微服务的 DevOps 服务模式，其外围价值主张就是“DevOps as a Service”。

在这个背景下，研发反对团队的工作就是为开发团队提供一个稳固而弱小的工程平台，帮忙他们屏蔽简单的底层基础设施。这个平台应蕴含开发者所需的各种工具、自助的开发者服务界面、以及可复用的模板，以满足开发团队的日常需要。

在这里，团队拓扑实践为咱们提供了一个了解和设计开发组织的框架。它强调依据组织的业务指标和沟通流动性来设计开发团队的构造，以达到最优的合作成果。团队拓扑帮忙咱们了解，不同类型的团队（例如，平台团队和开发团队）之间如何通过明确定义的交互模式（例如，合作或服务）进行无效的单干。

而平台工程的呈现，其实是团队拓扑倒退的必然结果。在古代软件开发中，因为技术复杂度和变动速度的放慢，以及微服务架构的宽泛应用，开发团队不再可能无效地关注所有的技术细节。平台工程就是将这些通用、底层的工作形象进去，由专门的平台团队来提供，从而让服务团队可能专一于他们的次要指标。

因而，CODING 平台的指标是作为平台工程的外围反对力量，通过实现优良的团队拓扑和提供弱小的平台工程能力，来帮忙各个团队更好高空向价值交付，实现工业化的软件生产线。