灰度发布
灰度发布是在金丝雀发布基础上进行延伸,不是将发布分成两批,而是将发布分成不同的阶段/批次发布,每个阶段/批次的用户数量逐级增加。如果新版本在当前阶段没有发现问题,就再扩展用户数量进入下一个阶段,直至扩展到全部用户。
灰度发布,可以结合滚动部署一起使用,通过分批部署,部署即发布,来让部分客群可见。结合特性开关、流量切换等技术,可以做到更复杂灵活的灰度设置。
以华为云DevCloud灰度发布的实践为例,整个DevCloud的产品中采取的灰度发布特点主要有三个方面:
-
根据用户画像,精准分层用户,灰度逐步递进,全部保证能够检测到所有的用户分群。
-
结合了多种灰度策略,如特性开关、AB测试、在线验收测试、友好用户测试等模式。
-
精准把控灰度批次比例,借助SLB服务,严格按照1%、9%、45%、45%,谨慎比例逐步放大灰度群体。
功能开关
功能开关利用代码中的开关(FeatureFlag/Toggle/Switch)来控制发布逻辑,一般不需要复杂的发布工具和智能LB 配合,是一种相对比较低成本和简单的发布方式。这种方式也是支持现代DevOps 理念,研发人员可以灵活定制和自助完成的发布方式。应用上线后开关先不打开,然后运维、研发或业务人员通过开关中心打开新功能,经过流量验证新功能没有问题后,则发布完成,如果有问题,随时可以通过开关中心切回老功能逻辑。
采用功能开关方式的优势是升级切换和回退速度非常快,相对于复杂的发布工具,实施比较简单,成本相对低廉,研发能够灵活定制发布逻辑,支持DevOps 自助发布。而劣势是切换是全量的,如果V2 版本有问题,则对用户体验有直接影响;另外对代码有侵入,代码逻辑会变复杂,需要定期清理老版本逻辑,维护成本变高。
功能开关的适用场合包括:对用户体验有一定容忍度的场景;已有配置中心或开关中心服务;暂不具备研发复杂发布工具能力等。
从实现角度,功能开关方式需要一个配置中心或者开关中心这样的一个服务支持,通过配置中心运维或研发人员可以在运行期间动态配置功能开关的值。功能开关发布只是配置中心的一种使用场景,配置中心还能支持其他动态配置场景,功能开关服务一般提供客户端的SDK方便开发人员集成,在运行期客户的SDK会同步最新的开关值。技术实现有推方式也有拉方式或者推拉结合方式,新功能和老功能住在同一代码中,新功能隐藏在开关后面,如果开关没有打开,则走老代码逻辑,如果开关打开则走新代码逻辑,技术实践上可以理解为一个简单的if else逻辑。
功能开关允许你持续地交付新发布,这些版本可以包含未完成的新功能——但这些不会影响应用程序,因为这些新功能还处于关闭状态。只有当这些功能可以发布并且成功地通过了所有所需的测试后,生产环境中的开关才会打开(即打开这个功能)。
功能开关是DevOps实践中非常重要的实践之一,我们将单起章节专门进行介绍。
A/B测试
简单来说,A/B测试是针对用户的需要,提供两个版本的功能,一部分用户能看到版本A,一部分用户能看到版本B,经过对比实验,得出哪个版本更优的测试过程。
A/B测试是用来测试应用功能表现的方法,例如可用性、受欢迎程度、可见性等等。A/B测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论,并确信该结论在推广到全部流量可信。
A/B测试的优势是用户体验影响小,可以使用生产流量测试,可以做到针对某类特定目标用户进行测试。但A/B测试搭建复杂度相对高,有一定技术门槛,需要具备一定的A/B 测试平台研发能力
A/B测试示例如图所示,假设原来的PC 端和手机端都访问老版本V1 服务(也称A 组或控制组),当V2 新版本(也称B 组或实验组)发布以后,为了验证V2 的功能正确性,同时也为了避免V2 有问题时影响所有用户,先通过LB 将手机端的流量切换到V2 版本,经过一段时间的A/B 比对测试和观察(主要通过用户和监控反馈),确保V2 正常,则通过LB 将全部流量切换到V2。
基于LB 方式实现 A/B测试,LB 需要能够通过某种条件做流量路由,例如通过Client IP,设备类型,浏览器类型,甚至是定制的HTTP Header 或查询字符串。
通过功能开关的方式和AB测试有点相似,但功能开关一般是无状态和全量的,无法做到针对某类特定用户进行测试。而AB测试一般是有状态的,能够根据事物和用户级别的状态,可以实现针对某类特定用户进行测试。
虽然 A/B 测试名字中只包含 A、B ,但并不是说它只能用于比较两个版本的好坏,事实上,完全可以设计两个以上版本进行测试,即A/B/n测试。
暗启动 Dark Launch
暗启动原意是指将新版本部署到生产环境后,对用户无感。所以暗启动意味着暗部署。当然,暗启动终极目的还是为了发布,对原有暗启动含义扩展之后,就会先让小部分用户感知新功能,再逐渐扩大感知到新功能的用户范围,那么暗启动就代表发布。
马丁·福勒(Martin Fowler)提到,暗启动针对的是后端行为,后端系统部署在生产环境之后,现有用户使用前端界面的时候,新部署的后端功能被调用,但是用户并没有感知,可以对新功能的性能进行监控。也就是说用户和系统的交互逻辑保持不变,用户在界面上没有地方选择新部署的功能,也就是对用户不可见。
暗启动的暗(Dark)代表用户无感知,也就是新版本的功能已经被部署到生产环境,但是用户无感知。例如百度的搜索框输入提升推荐,可以在客户界面不发送改变的情况下,对算法进行数据采集和训练,再与客户实际点击的链接结果集进行比对,便于更好的优化,在未来才正式推出输入时推荐的功能。
暗启动将部署与发布解耦,功能部署之后,对用户而言无感,这样可以获得部分真实用户的反馈,测试缺陷,评估基础设施性能、系统的额外负载和性能影响等。暗启动还可以启用重新实现的功能的并行运行。旧代码和新代码都可以调用并检查它们的结果以查看新算法是否有变化,但只有一个答案返回到界面。暗启动也可以选定公司内部员工作为用户,这样内部员工可以先吃自己的狗粮,对新功能进行测试,而真实用户并未真正使用新功能。这一场景事实上与灰度发布类似。
参考资料
-
https://martinfowler.com/bliki/ Martin Fowler的博客
-
一文看懂持续部署按需发布!DevOps部署和发布方法大全 —— 赵卫
-
《DevOps实践指南》