云效发布策略指南｜滚动、分批、灰度怎么选？

无论从开发运维还是产品运营的角度来看，任何一次上线都是有风险的。从最基本的应用停止导致流量丢失、服务不可用、服务QPS水位下降，到步骤的遗漏、流程的不规范、开发过程中引入的bug，以及新产品/新功能上线导致用户体验的变化，都会导致线上风险。在日常和用户交流过程中，我们也经常会被用户问到关于发布的问题，比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。今天我们就来聊聊常见应用发布方式的选择，以及每种发布模式适合什么样的场景。

平滑升级：滚动发布

分批发布通常指取出一例或多例应用实例，将其停止服务、升级到新版本；周而复始地重复这一过程，直到所有实例都升级到新版本。使用滚动发布，可以最大程度地避免因发布导致的流量丢失和服务不可用问题；这一模式也是Kubernetes应用部署使用的缺省模式。

针对部署规模较小、领域边界较清晰，同时面临业务快速发展变化的微服务应用，滚动发布流程简易且可靠性较高。不过由于通常情况下缺乏强干预手段，发布的可逆程度较差；一旦在发布过程中觉察到问题，往往需要进行全量回滚。

一般来说，滚动发布适用于符合如下条件的场景：

• 应用部署规模较小、启动和回滚的速度较快；

• 应用所关注的业务领域范围相对小、边界较清晰，且易于进行线上回归验证；

• 发布人员充分理解、掌握平台所提供的滚动发布策略；

• 新版本引入的变更，具有向下兼容性。

下面我们分别以ECS和Kubernetes为例，展示如何在云效平台上进行滚动发布。

面向ECS的滚动发布

在云效中，我们可以使用主机部署任务进行滚动发布。如图所示，假设需要对以下由2台ECS构成的主机组进行滚动发布，每次滚动更新1台主机：

在流水线中，配置主机部署任务：

设置“暂停方式”为“不暂停”、“分批数量”为2，即可实现滚动发布。

在进行ECS滚动发布时需要注意一点：通常情况下，滚动发布中的主机无法对外提供服务，这意味着集群整体服务水位（如可承接的QPS）会降低——例如在上面2台主机分2批发布的过程中，集群始终只有1台主机可以