微服务治理实践 | 金丝雀发布
前言 阿里巴巴集团内部有不少故障是因为发布直接或间接引起。因此提升发布的质量,减少错误的发生,是有效减少线上故障的一个关键环节。 为什么大部分的故障和发布相关?因为发布是整个功能更新到线上的最后一个环节,一些研发过程中累计的问题,在最后发布环节才会触发。同时发布本身也是一个复杂的过程,在发布过程中,往往容易出现一些错误操作或者遗漏关键操作。 日常发布中,我们常常会有如下一些错误的想法: 这次改动的内容比较小,而且上线要求比较急,就不需要测试直接发布上线好了 发布不需要走灰度流程,快速发布上线即可 灰度发布没有什么用,就是一个流程而已,发布完就直接发布线上,不用等待观察 虽然灰度发布很重要,但是灰度环境很难搭建,耗时耗力优先级并不高 这些想法都可能让我们进行一次错误的发布。 阿里巴巴内部有安全生产三板斧概念: 可灰度、可观测、可回滚。所有研发同学必须要掌握发布系统的灰度、观测和回滚功能如何使用。 今天我们来聊聊灰度发布。 灰度发布策略 灰度发布是发布整个过程中一个非常重要的环境。目前灰度发布策略有这几种: 蓝绿发布(Blue-Green Deployment) 通过部署两套环境来解决新老版本的发布问题。如果新版本(New Version)发生问题要进行回滚的时候,直接通过切流将流量全部切到老版本(Old Version)上。 优点:升级切换和回退比发布回滚迅速 缺点:成本较高