如果你领导一个拥有数百万甚至数十亿用户的产品的功能迭代，你会怎么做？

你需要面对的挑战可能来自于经营策略的改变带来的新产品需求，任何产品的改变，哪怕只是界面的调整，都会被无数现有用户“审核”。

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

作者通过对脸书、推特等互联网巨头的调查，试图窥探他们在瞬息万变的市场中依然保持“稳定”迭代的秘密——渐进式投放，并进一步探索如何利用Spinnaker实现自动渐进式投放。

通过本文，您将了解：

什么是1.?渐进式配送

为什么2. 's渐进式交付能够在大型组织中赋予产品持续交付和稳定迭代的能力？

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

01

010年到1010年的移动互联网时代诞生了一大批互联网巨头企业和项目。一些大型项目的技术复杂性和组织复杂性甚至低于传统工业项目。为了实现这些项目的管理和迭代，我们试着把目光投向已经完成工业革命的传统工业领域，寻找答案。

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

数据显示，在Kubernetes和云原生概念普及后，“渐进式交付”一词在互联网领域开始流行。尤其是在连续部署管道出现之后，渐进式交付为互联网应用提供了基础设施和实现方法。

在产品迭代的过程中，渐进交付的具体行为可以附加到管道上，整个交付管道可以看作是一个产品迭代的过程和一个渐进的交付周期。在实践中，渐进式交付是通过A/B测试、加那利/灰度发布等技术手段实现的。

以脸书为例。每次发布主要功能，都会经历一个典型的渐进式交付过程：

在逐步交付的过程中，无论是A/B测试还是灰度发布，都可以根据用户数据和市场反馈决定是否全额发布，既能保证迭代的敏捷性，又能保证市场的安全性。

（1）A/B 测试

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

（2）金丝雀/灰度发布

通过使用特定的分流技术，例如典型的murHash算法，新版本和旧版本可以共享流量。

02

什么是渐进式交付

从原理上看，这些技术并没有那么新，比如A/B测试，可以通过最原始的方式(在业务代码中加入逻辑判断条件)来实现，但是为什么没有大规.

模运用呢？

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

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

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

它主要实现了以下功能：

对于开发人员，这种渐进式交付经过多轮的灰度发布、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实战：云原生多云环境的持续部署方案》。

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

王炜，王振威 著

• 开创了云原生多元环境持续部署工具Spinnaker的先例，讲解深入
• 案例基于大厂一线工程师的实际工作，具有非常好的指导性和实践性
• 提供丰富的图片资源和实践源码，帮助读者快速上手

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

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