新乡网站开发的公司电话,家在深圳 歌曲,橱柜衣柜做网站,云瓣科技做网站简介#xff1a; DevOps追求更短的迭代周期、更高频的发布。但发布的次数越多#xff0c;引入故障的可能性就越大。更多的故障将会降低服务的可用性#xff0c;进而影响到客户体验。所以#xff0c;为了保证服务质量#xff0c;守好发布这个最后一道关#xff0c;阿里逐步…简介 DevOps追求更短的迭代周期、更高频的发布。但发布的次数越多引入故障的可能性就越大。更多的故障将会降低服务的可用性进而影响到客户体验。所以为了保证服务质量守好发布这个最后一道关阿里逐步发展出了适应DevOps要求的发布策略。 作者 | 沉银 来源 | 阿里技术公众号 前言 DevOps追求更短的迭代周期、更高频的发布。但发布的次数越多引入故障的可能性就越大。更多的故障将会降低服务的可用性进而影响到客户体验。所以为了保证服务质量守好发布这个最后一道关阿里逐步发展出了适应DevOps要求的发布策略。 在开始讲述阿里的实践之前我们先简单介绍下几种常见发布策略以及它们适用的场景和优缺点。 一 常见发布策略 1 停机发布 停机发布会在发布以前关闭服务停止用户访问然后一次性的升级所有服务。这种发布策略的发布频率往往比较低且需要在发布之前做好充足的测试。 停机发布的特点有 所有需要升级的组件被整合到一次发布中一个项目中的大部分应用都会被更新发布之前的研发流程和测试流程往往需要花很长的时间发布时如果出现问题, 修复和回滚的成本很高完成一次停机发布, 需要花费很久的时间, 且需要很多团队在一起才能完成往往需要客户端和服务器端同步升级 停机发布并不适合互联网公司因为两次发布的间隔很久从功能特性提出到进入市场的时间太长对市场反应不敏感会在充分竞争的市场里处于下风。每次发布因为要停机也会带来经济损失。 优势 简单不太需要考虑新旧版本共存时的兼容性问题 劣势 发布过程中服务不可用只能在业务低峰期 (往往是夜间)发布并且需要很多团队在一起工作出现故障后很难回滚 适合场景 开发测试环境非关键应用用户影响面小兼容性比较难管控的场景 2 金丝雀发布 金丝雀发布这个术语源自20世纪初期当时英国的煤矿工人在下井采矿之前会把笼养的金丝雀携带到矿井中如果矿井中一氧化碳等有毒气体的浓度过高在影响矿工之前金丝雀相比人类表现的更加敏感快速金丝雀中毒之后煤矿工人就知道该立刻撤离。金丝雀发布是在将整个软件的新版本发布给所有用户之前先发布给部分用户用真实的客户流量来测试以保证软件不会出现严重问题降低发布风险。 在实践中金丝雀发布一般会先发布到一个小比例的机器比如 2% 的服务器做流量验证然后从中快速获得反馈根据反馈决定是扩大发布还是回滚。金丝雀发布通常会结合监控系统通过监控指标观察金丝雀机器的健康状况。如果金丝雀测试通过则把剩余的机器全部升级成新版本否则回滚代码。 优势 对用户体验影响较小在金丝雀发布过程中只有少量用户会受影响发布安全能够得到保障 劣势 金丝雀的机器数量比较少, 有一些问题并不能够暴露出来 适用场景 监控比较完备且与发布系统集成 3 灰度/滚动发布 灰度发布是金丝雀发布的延伸是将发布分成不同的阶段/批次每个阶段/批次的用户数量逐级增加。如果新版本在当前阶段没有发现问题就再增加用户数量进入下一个阶段直至扩展到全部用户。 灰度发布可以减小发布风险是一种零宕机时间的发布策略。它通过切换线上并存版本之间的路由权重逐步从一个版本切换为另一个版本。整个发布过程会持续比较长的时间, 在这段时间内新旧代码共存所以在开发过程中需要考虑版本之间的兼容性新旧代码共存不能影响功能可用性和用户体验。当新版本代码出现问题时灰度发布能够比较快的回滚到老版本的代码上。 结合特性开关等技术灰度发布可以实现更复杂灵活的发布策略。 优势 用户体验影响比较小, 不需要停机发布能够控制发布风险 劣势 发布时间会比较长需要复杂的发布系统和负载均衡器需要考虑新旧版本共存时的兼容性 适用场景 适合可用性较高的生产环境发布 4 蓝绿发布 蓝绿部署是指有两个完全相同的、互相独立的生产环境一个叫做“蓝环境”一个叫做“绿环境”。其中绿环境是用户正在使用的生产环境。当要部署一个新版本的时候先把这个新版本部署到蓝环境中然后在蓝环境中运行冒烟测试以检查新版本是否正常工作。如果测试通过发布系统更新路由配置将用户流量从绿环境导向蓝环境蓝环境就变成了生产环境。这种切换通常在一秒钟之内就能搞定。如果出了问题把路由切回到绿环境上再在蓝环境中调试找到问题的原因。因此蓝绿部署可以做到仅仅一次切换立刻就向所有用户推出新版本新功能对所有用户立刻生效可见。 优势 升级切换和回退速度非常快零停机时间 不足 一次性的全量切换如果发布出现问题, 会对用户产生比较大的影响需要两倍的机器资源需要中间件和应用自身支持热备集群的流量切换 适用场景 机器资源比较富余或者按需分配 (背靠云厂商) 5 A/B 测试 A/B 测试和灰度发布非常像可以从发布的目的上进行区分。AB测试侧重的是根据A版本和B版本的差异进行决策最终选择一个版本进行部署。和灰度发布相比AB测试更倾向于去决策和金丝雀发布相比AB测试在权重和流量的切换上更灵活。 举个例子某功能有两个实现版本 A 和 B通过细粒度的流量控制把 50% 的用户总是引导到 A 实现上把剩下的 50% 用户总是引导到 B 实现上通过比较 A 实现和 B 实现的转化率最终选择转化率较高的 A 实现作为功能的最终版本。 优势 快速实验能力用户体验影响小可以使用生产环境流量做测试可以针对某些特定用户做测试 不足 需要较为复杂的业务流量识别和控制能力需要考虑较为复杂的新旧版本兼容性问题 适用场景 用来做业务探索和创新测试需要对多个方案进行决策 6 流量隔离环境发布 在上述的发布策略中发布的单位都是应用但是一个功能模块往往是由多个应用组合在一起提供的服务即使当前发布的应用出现了异常这个异常也未必体现在当前应用中在复杂的情况下异常会延迟到它的下游应用才体现出来如何发现此类问题并且不影响用户体验是非常重要的。此外我们有时候还希望新版本的代码上线以后只影响到一小部分用户。而传统的灰度发布因为无法识别业务流量所以即使某个应用只有一台机器出现了问题也可能会影响到所有的用户。 如下图左侧的灰度发布App1 的所有机器都有一定概率会路由到出现问题的红色 App2 机器上。而右侧的隔离环境发布中新版本的代码会先发布在全链路隔离环境中即使发布中出现问题也只会影响少量用户。 优势 能够发现一些复杂的, 涉及到多应用的问题出现故障时, 只会影响很小一部分用户 不足 需要对流量隔离环境进行独立监控系统设计复杂, 需要中间件和链路上的所有应用能够识别业务流量 适用场景 较为核心的生产业务场景 二 阿里巴巴发布最佳实践 我们将按照发布的过程来介绍阿里巴巴发布的最佳实践。 1 发布计划 发布前要对待发布功能模块做充分验证同时要思考假如本次发布引入故障该如何止血。所以在发布之前写出本次发布的计划清单是非常重要的一个典型的发布计划如下 本次发布参与人 开发人测试人代码 Review 人发布内容测试过程风险描述线上验证方案线上出现问题的止血方案 发布步骤 分 x 批发布前 x 批发布后暂停 x 小时 2 不同环境使用不同的发布策略 前面介绍的几种发布策略都有各自的优缺点要根据自己的场景特点和需求选择合适的发布策略。 一般来说测试环境是用来做初步功能测试所以会频繁的更新代码和发布如果采用灰度发布的方式且发布的批次设置的比较大则开发效率会大打折扣。这个时候单机或多机的单批次停机发布其实是一个不做的选择。 对于预发环境不仅要考虑自己测试的需要还要考虑上下游其他开发者的测试需求所以单批次停机发布就不再合适可以设置两批发布。 对于线上环境可以先发布隔离流量环境再多批次发布线上环境。 3 发布中关注监控报警 仅靠发布策略是无法避免故障的发生的在发布中和发布后仔细的观察应用的监控数据非常重要。应用的核心指标监控数据比如 QPS、RT、成功率和报错数能够帮助用户尽可能早的发现故障。此外在生产环境中如果批次数量设置的比较小每批发布机器数量比较少那么即使某些监控指标出现了问题因为数据量比较小可能会被淹没在整体的监控数据中所以配置已发布机器的独立监控也是非常重要的。 4 金丝雀发布和无人值守 阿里内部绝大部分应用会在多机房/单元部署可能存在一种场景同一份代码和配置在某些机房/单元正常在其他的的单元/机房下就会出现故障所以有必要在分批发布的时候把所有机房/单元的组合都在第一批发布时出现这样问题可以及早暴露。此外研发人员往往会重点关注前几批发布如果后面批次才出现问题研发人员可能无法快速响应。 单元化是为了解决容灾和扩展性问题上图是阿里巴巴的单元化部署架构。此外应用的监控项一般都很多在发布周期比较长的情况下不能要求研发人员时刻专注每一个监控项需要一定的智能化方案帮助研发找出那些需要重点关注的监控项。 为了解决上面两个问题阿里设计并实现了自己的金丝雀发布策略。金丝雀发布从应用的每个机房/单元下抽取 10% 的机器放到首批无人值守智能监控系统会对这部分机器设置独立的监控对于每个监控项无人值守会对比已发布和未发布机器的监控指标数据同时对比发布前和发布后的监控数据如果发现异常会推送给研发人员做进一步的判断。 这种金丝雀发布策略可以帮助研发尽可能早的发现问题, 并且减少研发人员的工作量提高研发效率。 5 持续集成和发布 合理的选择发布策略按照上面所述的最佳实践来发布发布的风险可以被控制在很小的范围内甚至比停机发布的风险还要小。实际上发布周期短每次发布仅包含少量代码是一个很好的发布实践。因为部署间隔时间长将会导致每次的部署包含更多的代码变更结果就是出现更多缺陷和宕机的风险。这种情况下人们为了降低发布风险会倾向于增加更多的评审事实上这除了大大增加部署时间外对降低发布风险的影响微乎其微。这是一个越来越差的增强回路我们需要通过高频的持续部署来颠覆这个恶性循环。 三 总结 敏捷开发能够缩短产品走向市场的时间让消费者更快地获得想要的功能也能让产品团队更快地拿到消费者的反馈并据此对产品做出迭代。为了解决敏捷开发下频繁发布带来的发布风险本文介绍了多种发布策略包括各个发布策略的优缺点、适用场景在不同场景下综合应用这些模式可以在更快速地交付高质量的产品。 原文链接 本文为阿里云原创内容未经允许不得转载。