# 传统方式:直接重启

直接备份老版本的包,上传新的包,然后停掉当前服务,重启新的服务。

这种发布方式操作步骤繁琐,而且中间存在无法提供服务的时间段,相当于停服更新,在当前流量较大的互联网公司是不能容忍的。

# 借助 nginx 重启

重启应用的时间通常比重启 nginx 的时间来的长,通过 ngxin 来减少重启的时间。

先在同一台或者另一台机器中重启新的服务,然后更改 nginx 配置,将流量切换到信息的应用上,然后重启 nginx 。

这样可以减少服务重启过程中导致的无法访问时长。但是仍然无法做到用户无感知的系统迭代和发布上线。

# 蓝绿发布(Blue && Green Deployment)

蓝绿发布的过程如下图:

其原理很简单,通过 “蓝” 和 “绿” 来区分两套版本不一样的环境。 “绿” 表示旧版本,此时线上的全部流量由其承担,“蓝”表示新的版本。

比如:app 可以打特定的包进行 “蓝” 环境的线上测试。当测试通过后,将线上的流量全部由“绿”切换到“蓝” ,完成一次几乎无感知的上线。

# 滚动发布(Rolling Update Deployment)

滚动发布的过程如下图:

其原理,针对集群里的少量节点一点一点进行更新上线,每次进行少量更新,直到全部更新完毕,整个系统变为新版本。

# 灰度发布(Gray Deployment)

灰度发布的原理,就是在线上环境中部署一个新版本应用,然后引入一小部分流量进入其中,当没有问题时,就切换上线。

灰度发布分为两种:

  • A/B 测试

  • 金丝雀部署

# A/B 测试(A/B Testing)

存在两个版本的服务,A 版本是线上稳定版本,B 版本是迭代版本。

现部署一个 B 版本环境,分流一部分流量过来,收集用户反馈然后逐步改进 B 版本,直到用户可以接受 B 版本时,直接将 A 版本全部替换为 B 版本。

A / B 测试蓝绿发布 有点像,不过两者存在区别,蓝绿发布关注的是新版本的发布,而 A/B 测试 关注的是测试过程。

# 金丝雀部署(Canary Deployment)

在集群中部署一台实例作为“金丝雀”(相当于小白鼠) ,引入一小部分流量,收集问题,及时调整,达到上线标准时,将集群中的其他实例也替换成新的服务实例。

金丝雀部署滚动发布 也有点像,不过两者也存在区别。金丝雀部署 关注的时测试过程,而 滚动发布 关注的是系统发布。

# 各种发布方式粗略对比

发布方式 优势 劣势
传统停机发布 如果说简单可以作为优点的话,那确实是又优点 存在停服时间段,版本如果出现回滚,停服时间会更长
nginx 转发方式发布 相比较于传统停机发布 ,耗时更短。 相比较于 传统停机发布 更繁琐,系统资源需要double。
蓝绿发布 升级回滚速度快。
无需停服
资源消耗是普通应用的两倍
需要考虑回滚的边界问题
滚动发布 用户感知较小 发布过程较长
对发布工具有要求
A / B 测试 用户感知较小 搭建复杂度高
金丝雀部署 用户体验影响小,灰度发布过程出现问题只影响少量用户 自动化不好做
精彩内容推送,请关注公众号!
最近更新时间: 6/1/2020, 8:55:56 AM