首页 运维干货部署发布的几种思路:运维司机们,您都理解对了吗

部署发布的几种思路:运维司机们,您都理解对了吗

运维派隶属马哥教育旗下专业运维社区,是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai
领取学习更多免费Linux云计算、Python、Docker、K8s教程关注公众号:马哥linux运维

文章背景

  1. 滚动部署、蓝绿部署、灰度发布/金丝雀发布、A/B测试等名词在讲述“微服务”、“DevOps”,甚至更抽象的“Cloud-native”的交付时可能会有所涉及,学习这几个名词作为基础打底;
  2. 有几篇网络上浏览量较高的文章在这几者的所谓“对比说明”中,槽点太多,故而有了本文作为概念层面的纠正。

我们先明确一个概念,这些名词为两类:部署 VS 分布

部署,针对环境而言;发布则是一种策略,需要在业务层面理解,包含如何发布、如何回滚、发布那些功能、哪些用户可以使用等等。

好了,先聊聊部署。

Blue/Green Deployment(蓝绿部署)

从过去到现在,蓝绿部署模式因为安全、可靠的实用特征,在很多大企业中落了地。

步骤:

  1. 准备蓝、绿两个相同环境,蓝色跑旧版。
  2. 部署v1(蓝),此时v1成为外部请求流量的靶子。
  3. 部署v2(绿),此时v2状态为“备用”(负载均衡的池里把这些地址去掉),待v2启动成功,则自动测试备用集群的部署情况。
  4. v2(绿)状态改成存货,蓝绿连接相同数据库,进入了存活负载均衡池,随后v1(蓝)同样操作。最终v2代码完成部署。
  5. 视情况进行数据库迁移。

看似步骤麻烦,理解了还好。蓝绿部署无需停机,风险相对较小。

不过蓝绿部署在考虑到两个环境的在线服务随版本切换的特征,版本一致性和数据的一致性保证非常重要

另外,在非隔离基础架构(VM、Docker等)上蓝绿部署有一定毁灭性风险,不是高手要慎用。

滚动部署

滚动发布,相对小众的市场,一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用。周而复始,直到集群中所有的实例都更新成新版本。

之所以小众,看缺点:

  1. 没有一个环境确定ok,因为直接改了现有环境;
  2. 既然没有环境确定ok,如果滚动发布到了第90个实例,需要回滚……程序猿可能会摔键盘;
  3. 万一部署期间系统自动做了动态伸缩,不好判断哪个节点用了哪个代码。此时一款强大的自动化运维工具就派上用场了,but,有些运维部门没有呢;

灰度发布/金丝雀发布

灰度发布指版本在黑白之间平滑过渡,最传神写意的就是金丝雀部署。

“金丝雀部署”,在业界有两种策略形式:

  1. 一种是部分服务器升级到新的版本。这种形式的重点在于,接入网关要精确的匹配某个特征的用户(灰度)流量导入到这批新版本集群中;
  2. 另外一种是所有服务器升级新的版本。这种形式的重点在于,接入网关要精确的匹配某个特征的用户(灰度)流量使用到新接口;

A/B Testing(AB测试)

A/B测试和蓝绿部署是两码事,
A/B测试和蓝绿部署是两码事,
A/B测试和蓝绿部署是两码事,
重要的事情说三遍~

很多行业都有A/B测试的概念,A/B测试更像是用户侧的新旧版本机制,通过灰度一部分试验客户,使用A/B不同的效果,达到验证不同版本在可用性、受欢迎程度、可见性等等实际表现上的对比。

A/B测试是推广到全部流量可信新版前的科学验证方式,facebook改版就用过这个方式;蓝绿部署是直接发布到可信新版。

A/B测试和蓝绿部署可以同时使用,就像嵌套if,最后选定最受欢迎最靠谱的可信版本。

运维司机们,您看明白了吗?

原文来自微信公众号:DevOps研究院

本文链接:http://www.yunweipai.com/11991.html

网友评论comments

发表评论

邮箱地址不会被公开。

暂无评论

Copyright © 2012-2021 YUNWEIPAI.COM - 运维派 京ICP备16064699号-6
扫二维码
扫二维码
返回顶部