26 灰度发布：新功能上线如何有效控风险？

你好，我是徐逸。

通过前面课程的学习，相信你已经从编码和架构层面，熟练掌握了提升服务稳定性的多种方法。然而，即便我们再小心谨慎，在快速迭代的开发环境中，也难以完全避免忙中出错的情况。因此，为了防止有缺陷的代码或配置直接上线，对大量用户造成不良影响，我们还需要一些能够在小范围内发布新版本，并且能快速回滚的部署策略。

今天这节课，我们就来聊一聊业界常见的几种部署策略。

部署策略

当服务新版本准备上线时，为了确保新旧版本能够顺利切换，业界有下面几种常用的部署方式。

首先是停机部署。在这种部署方式下，在发布新版本时，我们需要先停止服务的运行，待新版本的代码和配置准备好之后，再重新启动服务。

停机部署过程相对简单，不需要复杂的流量切换和分批更新过程。但是系统在部署期间完全不可用，而且一旦出现问题，就需要重新停机部署旧版本，不能快速回滚。因此，停机部署常见于对系统可用性要求不高的系统，在业务低峰期进行版本升级。比如一些政府网站、小型企业或内部系统的更新，在发布版本前会提前发出停机部署公告，类似下图。

接下来，我们来看下蓝绿部署。在实施蓝绿部署时，除了正在运行稳定版本代码的线上蓝环境外，我们还需要搭建一套全新的绿环境，并且将绿环境中的代码更新为即将发布的新版本。当在绿环境中的各项测试与验证都确认无误后，再通过流量调度，逐步将线上流量从蓝环境切换到绿环境。

这样一来，在整个切换过程中，用户几乎察觉不到任何服务中断，有力保障了业务的连续性。而且如果新版本上线后出现问题，我们能够立刻将流量重新切回蓝环境，快速恢复到旧版本，最大限度降低对业务的影响。

尽管蓝绿部署具备零停机时间和快速回滚的显著优势，但它需要同时维护两套完整的运行环境，这就导致它的资源成本相对较高。所以，它更适合于那些对系统可用性有着超高要求，且一旦出现问题必须立即快速回滚的极为严苛的应用场景，比如像蚂蚁金服这类金融公司，或者其它公司一些交易链路上的服务。

了解了蓝绿部署，我们再来看下滚动部署。滚动部署是一种按比例分批将新版本部署到各个服务器的策略，它的操作流程如下。

首先，根据预设的滚动比例，将部分服务器从 Consul等服务注册系统中暂时移除，以此中断线上流量对这些服务器的调用。

随后，对这些已移除的服务器进行升级操作，待升级完成后，再将它们重新注册回 Consul 等系统中。

最后，上游服务能够借助 Consul 等再次发现这些服务器，并把流量引导至这些已经部署了新版本代码的服务器上。当然，如果在滚动更新过程中发现任何问题，我们可以暂停后续更新并执行回滚；如果一切顺利，就可以继续下一轮滚动更新。

相较于蓝绿部署，滚动部署具有独特优势，它无需额外搭建环境资源，直接在原有的服务器集群上进行更新，资源利用效率高。

然而，滚动部署需要按照一定比例分批次逐步推进更新流程，这样一来，无论是进行部署还是回滚操作，所耗费的时间都相对较长。不过由于滚动部署具有节约资源的优势，因此在大型互联网公司中应用较为普遍。

最后，让我们来看下灰度部署。灰度部署借鉴了煤矿工人使用金丝雀检测有害气体的做法，先将新版本代码部署到一小部分特定的服务器，通过观察他们的使用情况来判断新版本是否存在问题。因此，这些特定的服务器被称为“金丝雀服务器（canary）”，而灰度部署又被称为金丝雀发布。

对于这些金丝雀服务器，我们通常会单独配置监控。通过这些监控，我们就可以观察到金丝雀服务器的运行状况，确保新版本在实际运行环境中表现稳定。一旦确认这些服务器上新版本运行无误，我们就可以通过其它方式逐步扩大新版本的部署范围，直到最终全面替换旧版本，实现新版本的平稳上线。

和滚动部署相比，灰度部署的优势在于能够先把新版本部署到某些特定的灰度机器上，并且会提前为这些灰度机器配置单独的监控。通过这种方式，我们更加容易发现新版本可能潜藏的问题，进而有效降低发布风险。

当然，在实际操作过程中，很多公司会采用灰度部署和滚动部署相结合的发布策略。首先将新版本部署到灰度机器上，对它们的运行情况进行一段时间的观察，确认没有问题之后，再按照一定的比例，采用滚动部署的方式对其他机器进行更新，最终实现全量发布。

业务维度灰度

当然，在灰度部署的实践中，除了上面提到的预先选择部分机器进行灰度发布之外，我们还可以从业务维度出发，根据用户的特定特征来进行灰度操作。下面是几种常见的灰度方式。

第一种是基于用户 ID的灰度方案。这种方案通过将用户ID进行分组，使得一部分用户能够体验新功能逻辑，而另一部分用户则继续使用旧功能逻辑。例如，我们可以依据用户ID对某一特定数值进行取模运算，并根据取模的结果来决定用户所适用的功能逻辑。随后，通过持续观察，逐步扩大体验新功能逻辑的用户比例。基于用户ID的灰度方案在进行大规模功能改造时较为常见，它能够有效控制新功能的推广节奏，确保平稳过渡。

第二种是基于用户角色的灰度方案。比如，我们可以先让 VIP、SVIP 用户优先体验新版本，对这些用户的使用情况进行监控，根据反馈和使用情况，及时或优化新功能，确保上线之后的新版本能较好地满足核心用户的需求。

第三种是基于地理位置的灰度。这种方案将用户按照地理位置进行分组，先在某个城市或地区灰度新功能，根据监控结果和业务需求，逐步扩大灰度地区的范围，直到全面上线新功能。例如，如果新功能在北京市运行稳定，用户反馈良好，再逐步扩展到其他一线城市，如上海、广州等。这种方案适用于一些需要根据地区差异进行功能测试或市场推广的场景，能够提前发现地区特有的问题，优化地区特定的功能。

第四种是基于用户行为的灰度。这种方案根据用户在系统中的行为特征来进行灰度划分。例如，将经常使用搜索功能的用户先分配到新版本，以便测试搜索功能的新特性。

第五种是基于设备类型的灰度。这种方案按设备类型对用户进行分组灰度测试。比如先在安卓设备上推出新版本，观察不同安卓设备的兼容性和性能表现，因为安卓设备种类繁多，不同的硬件和系统版本可能对软件的运行有不同影响；或者先在桌面端推出，再逐步推广到移动端，根据不同设备类型的特点和用户群体，有针对性地开展灰度测试。

小结

今天这节课，我们从发布流程入手，学习了不同的部署策略以及从业务维度进行灰度的几种常用方式。现在，让我们一起回顾其中的重点内容。

首先，我们了解了几种常见的部署策略，包括停机部署、蓝绿部署、滚动部署以及灰度部署。实践中，灰度部署和滚动部署会结合起来使用。

其次，就灰度部署而言，除了在机器层面进行灰度操作外，我们常常还会从业务视角出发，依据用户的特定属性实施灰度处理。常见的方式包括基于用户 ID、基于用户角色、基于地理位置、基于用户行为以及基于设备类型的灰度。这些基于业务维度的灰度方式，能够帮助我们更精准地控制和优化发布过程。

希望你能深入体会这些部署策略以及业务维度的灰度方式。在实际发布过程中，务必记得根据具体情况选用恰当的部署策略和灰度方式，以此保障新功能上线的稳定、可靠。

思考题

在服务发布的过程中，你用的是哪种部署策略呢？

欢迎你把你的答案分享在评论区，也欢迎你把这节课的内容分享给需要的朋友，我们下节课再见！