保持稳定迭代的秘密：基于 Spinnaker 的全自动渐进式交付

如果让你主导一款千万级，甚至亿级用户产品的功能迭代，你会怎么做？

你需要面对的挑战可能来自商业战略的变化带来的新的产品诉求，而产品的任何改动，哪怕只是界面调整，都将接受无数存量用户的“检阅”。

这时候，作为产品负责人，你会选择稳定压倒一切，还是自我革新以追求用户和市场价值呢？

笔者通过对 Facebook、Twitter 等互联网巨头的调研，试图窥探他们在瞬息万变的市场中仍然保持“稳定”迭代的秘密——渐进式交付，并进一步探索如何使用 Spinnaker 实现全自动渐进式交付。

通过本篇文章，你将了解：

1. 什么是渐进式交付。

2. 为什么渐进式交付能赋予大规模组织下的产品持续交付及稳定迭代的能力。

3. 既适用于小项目，又适用于大项目的实践经验。

01

什么是渐进式交付

移动互联网时代诞生了一大批巨型互联网企业和项目，部分大型项目的技术复杂度和组织复杂度甚至不亚于传统工业项目，为了实现对这些项目的管理和迭代，我们试图将目光投向已经完成工业革命的传统工业领域去寻找答案。

“渐进式交付”一词最早起源于大型、复杂的工业化项目，它试图将复杂的项目进行分阶段拆解，通过持续进行小型闭环迭代降低交付成本和时间。

资料显示，“渐进式交付”一词流行于互联网领域是在 Kubernetes 及云原生理念被普及之后。尤其是在持续部署流水线出现后，渐进式交付为互联网应用提供了基础设施和实现方法。

在产品的迭代过程中，可以将渐进式交付的具体行为附着在流水线中，将整条交付流水线看作产品迭代的一个过程和一次渐进式交付周期。渐进式交付在实践中是以 A/B 测试、金丝雀/灰度发布等技术手段落地的。

以 Facebook 为例，其每次发布重大功能，都会经历一次典型的渐进式交付过程：

1. 迭代发布

2. 公司全员进行 A/B 测试

3. 特定用户进行 A/B 测试

4. 灰度发布

5. 全量发布

在渐进式交付的过程中，A/B 测试环节及灰度发布环节都可以根据用户数据和市场反馈决定是否全量发布，这种方式既能够保证迭代敏捷，又能够保证市场安全性。

（1）A/B 测试

可通过对用户画像中地理位置和性别组合条件进行 A/B 测试，使其访问新版本，而其他的用户则继续访问旧版本。一段时间后，研究用户行为数据和用户体验报告，决定是否继续进入下一个发布环节。

（2）金丝雀/灰度发布

可使用特定的分流技术使流量由新、老版本共同承担，例如典型的 MurmurHash 算法。

02

技术和商业价值

从原理上来看，这些技术并不是多么新的技术，比如 A/B 测试，我们采用最原始的方式（业务代码增加逻辑判断条件）也可以实现，但为什么没有大规模运用呢？

原因很简单：纯业务代码的实现依赖于技术，需求方无法自主控制 A/B 测试的环境和条件，这种过度依赖于技术的开发方式并不能规模化运用。

我们需要的是一种完全脱离业务代码的实现方式，最好能以自动化/半自动化方式实现，并且尽量能把这个动作加入已有的内部流程内。

现在，有了云原生持续部署工具 Spinnaker ，自动化的渐进式交付便成为可能。我们参考 Facebook 的发布方式，设计了 Spinnaker Pipeline。

它主要实现了以下功能：

• 流水线被触发后，自动执行 K8S Job Migrate 数据库，并部署新版到预发布环境；

• 人工确认，发布生产环境前是否进行 A/B 测试；

• A/B 测试通过后，设置灰度发布的比例，执行自动灰度发布；

• 人工确认，是否全量发布到生产环境；

• 自动配置限流和熔断策略，保证生产稳定。

对于开发人员，这种渐进式交付经过多轮的灰度发布、A/B 测试，能最大程度减少代码 BUG 发布到生产环境。

对于运维人员，这种几乎全自动的交付方式改变了手动修改 yaml 文件、手动 apply 的传统，能大程度减少发布产生的人为错误，通过自动触发的方式降低了与开发的沟通成本。

对于产品经理和运营人员，产品迭代不再靠内部团队猜测，而是基于实际用户体验数据，了解新功能对于用户和市场的反馈，能最大程度降低新功能的市场风险。

03

核心原理

在上面的例子中，我们使用了 Traefik 作为集群网关，使用 Router 对 Host dev.coding 和 pro.coding 进行匹配，使流量按照不同发布阶段进行不同的分配。

（1）Dev 环境架构图

访问 dev.coding 时，Router 匹配到此 Host 规则，将流量转发到名为 k8s-flask-nodeport 的 Service（即 Dev 环境的 Service）。

Traefik Router 的核心配置代码如下：

（2）A/B 测试环境架构图

访问 pro.coding 时，Router 匹配到此 Host 规则，检查 Header 是否匹配，并将根据匹配结果决定将流量转发到 k8s-flask-canary 还是 k8s-flask 环境的 Services。

A/B 测试 Traefik Router 的核心配置代码如下：

（3）灰度发布架构图

访问 pro.coding 时，Router 匹配到此 Host 规则，并根据配置的 Weight 权重，将流量按比例转发到 k8s-flask-canary 或 k8s-flask Service。

（4）熔断和限流架构图

在生产环境中，我们一般使用限流和熔断技术来应对流量激增，牺牲部分用户的体验来保证生产环境的稳定。Traefik 内熔断和限流是通过配置 middlewares 来实现，对流量进行匹配后，再进行中间件二次流量确认。

Traefik Middlewares 限流核心配置代码如下：

Traefik Middlewares 熔断核心配置代码如下：

04

小结

Kubernetes 和 Service Mesh 的出现给持续部署带来了更多可能，渐进式交付只是一种借助其便利性而形成的比较典型的发布方式。

我们借助了 Traefik 作为集群网关，通过分流技术实现了 A/B 测试和灰度发布，并将这些声明式配置文件用 Spinnaker 进行编排，实现了渐进式交付过程。

Traefik 提供的熔断和限流能力，结合 Spinnaker Pipeline 的 Webhook 触发及监控系统（如 Prometheus），可以在业务系统压力较大时自动触发熔断和限流 Pipeline，改变限流策略，保证生产环境的稳定性。

当然，你也可以引入 Service Mesh，使用 Istio 管理集群流量，借助 Virtual Service 和 Destination Rule 实现同样的效果。

Spinnaker：云原生多云环境持续部署的未来！如果想了解更多关于 Spinnaker 的技术细节，欢迎阅读《Spinnaker 实战：云原生多云环境的持续部署方案》。

对象存储实战指南.jpg

▊《Spinnaker 实战：云原生多云环境的持续部署方案》

王炜，王振威 著

• 开创了云原生多元环境持续部署工具 Spinnaker 的先例，讲解深入

• 案例基于大厂一线工程师的实际工作，具有非常好的指导性和实践性

• 提供丰富的图片资源和实践源码，帮助读者快速上手

本书聚焦于云原生和多云环境的持续部署方案，共分 13 章，内容涉及声明式持续部署概述、Spinnaker 基础与实战、金丝雀发布与灰度发布、部署安全、混沌工程及生产化建议等，结构清晰，循序渐进，深入浅出。

在持续部署最佳实践方面，本书重点介绍了如何实施灰度发布、自动金丝雀分析和混沌工程，这些高级部署功能是 Netflix 公司实现快速而稳定迭代的核心技术。关于如何落地 Spinnaker，本书站在人和组织架构的视角，为迁移团队提供了指导性的意见，解决了新技术落地难的问题。