DevOps 发布策略简介
发布时间：2022-06-30 10:40:38 所属栏目：安全 来源：互联网
导读：前言 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 实现作为功能的最终版本。  （编辑：岳阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
