应用发布

1.概述

生产发布通常指的是将软件、应用程序或系统从开发环境部署到实际的生产环境中，以供实际用户使用。这个过程涉及到多个步骤和团队的协作，其中包括测试、部署、监控和反馈等环节。

在进行生产发布之前，需要确保开发团队已经完成了必要的测试和验证工作，包括单元测试、功能测试、集成测试和验收测试等。同时，还需要确保系统已经完成了必要的安全和性能测试，以确保它能够在生产环境下正常运行。

一般来说，生产发布的过程应该是自动化的，以确保每个步骤都能够得到正确的执行，同时减少人为错误的风险。在生产发布之后，还需要进行持续的监控和反馈，以确保系统能够稳定地运行，并及时处理可能出现的问题。

常见的发布类型有：蓝绿发布、滚动发布、灰度发布等。

2.传统发布

传统发布发布方式简单粗暴，先是将老版本v1全部下掉，然后将新版本v2发布到机器上去。这种发布方式会导致服务中断停机，一般在开发测试环境中使用，但是在生产环节发布，如果已经有用户正在使用应用的话，会直接影响到用户，因此这种方式不建议使用。

发布前：

发布后：

• 优点：操作简单，成本低

• 缺点：服务中断用户会受影响，出了问题回退也慢。

• 适用场景：

  • 开发测试环境；
  • 非关键应用，如用户影响面小或者未对外开放，试运行阶段；
  • 初创公司什么都缺，找个夜深人静用户访问量小的时间发布。

3.蓝绿发布

蓝绿发布的目的是减少发布时的生产中断时间，能够快速撤回发布。

在蓝绿部署中，生产环境一般需要两套配置：一套是正在提供服务，标记为“蓝色”，运行旧版本的V1；另一套是准备发布的服务器，标记为“绿色”，运行准备发布的版本V2。

当我们想要升级到V2时，在绿色环境中进行操作，部署新版本应用，并进行测试。如果测试没问题，就可以把负载均衡器/反向代理/路由指向绿色环境了，随后对V2进行监测，如果运行出现了问题，就可以通过负载均衡器快速回滚到蓝色环境，如果未出现问题，可以回收蓝色环境机器。

发布前：

发布后

• 优点：

  • 在绿色环境进行测试验证，验证通过后，可以一次性将流量从蓝组切换到绿组；
  • 停服务时间几乎可以忽略，用户无感知，平滑过渡；
  • 升级切换和回退速度非常快。

• 缺点：

  • 需要两倍服务器资源；
  • 切换是全量的，如果V2版本有问题，则会影响用户体验；

• 适用场景：

  • 机器资源富余；
  • 对用户体验有一定容忍度的场景；
  • 暂不具备复杂滚动发布工具研发能力。

4.滚动发布

滚动发布主要是解决蓝绿发布设备硬件倍增的问题。新服务和老服务是混在一起的。就是在升级部署过程中，并不是启动所有新版本服务，而是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了

发布前：

第一轮：

第二轮：

第三轮：

关于滚动发布我在工作中踩过一次坑，当时是第一次接触滚动发布，要上线的应用新申请了Apollo，主要是把调其他服务的地址配置在Apollo上，当时由于并行项目太多，忘记记录在上线文档上了，生产环境没有配置Apollo就发布了。

后来就把这件事忘记了，当时上线过程中，第一轮发布应用发布失败，当时看了日志没有问题，服务也是正常的，后来看到公司群里有人提了相同的问题，以为是容器平台的问题。

然后看到第一轮发布失败后面有个跳过的按钮，当时我并不清楚功能，于是我就跳过了这个AZ进入了下一个AZ，结果第一个AZ流量恢复了，而应用因为发布失败重启了。当时公司监控的同事直接电话打了过来，幸亏组长力挽狂澜，没有造成损失。

• 优点：

  • 用户无感知，平滑过渡；
  • 服务器成本低

• 缺点：

  • 回滚困难，尤其是微服务，互相调用关系复杂的情况将是灾难性的。需要将新版本流量从LB上摘除，清楚新版本，发老版本，再将LB流量接入老版本，和发布过程一样；
  • 部署时间很慢，取决于每一个阶段的时间；
  • 发布策略较复杂。

• 适用场景：

  • 生产环境用户体验不能中断的网站业务场景；
  • 机器资源富余；
  • 有一定的发布工具研发能力。

5.灰度发布

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。 在其上可以进行A/B 测试，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。比如说华为小米系统的抢先测试等。

从上述可以看出，灰度发布的作用有以下几点：

1. 降低发布带来的影响，虽然功能都在测试环境测过，但毕竟没有发布到生产环境，如果让少部分用户先使用新版本，提前发现bug，或者性能问题，提前做好修复，就可以降低新版本带来的影响；
2. 通过新老版本的对比，观察新版本带来的效果。

灰度发布的操作过程：

灰度发布需要做到同一个用户始终访问的是同一个版本的代码，如果同一个用户上个请求是访问A版本，下一个请求访问B版本，就可能会出现问题。

区分用户规则，就是让哪些用户走哪些服务。可以流量权重、权限、用户id、白名单等来区分控制；

预制规则代码，在网关中写好。

• 优点：

  • 用户无感知，平滑过度；
  • 初始灰度的时候就可以发现、调整问题，影响范围可控；
  • 相对节省服务器成本；

• 缺点：

  • 时间成本高，整个灰度从前期的灰度策略直到最后完全上线需要耗费很大的时间同时维护新旧两套代码、两套配置，以及版本之间的耦合问题；
  • 自动化要求高，如果发布自动化要求不够，发布期间可能引起服务中断；

• 适用场景：

  • 用户体验要求较高的网站业务场景

6.各种发布策略对比

策略	服务零中断	回退间隔	对用户负面影响
传统发布	❌	慢	高
蓝绿发布	✅	快	中
滚动发布	✅	慢	低
灰度发布	✅	快	低

总结：

• 传统发布一般是不建议采用的，除非是开发测试环境，用户体验不敏感的非关键应用，或者是创业期什么都缺时候的无奈之举。
• 灰度发布通过少量新版本服务器接收生产流量的方式去验证新版本，可以显著降低风险。灰度发布适用于大部分场景。
• 滚动发布一般和灰度发布配合，先发一台灰度去验证流量，再按批次增量发布。

微信公众号：星言heart

参考：zhuanlan.zhihu.com/p/440317719