必知必会 - 你可能想了解的上线部署策略
引用自原文:https://www.cnblogs.com/apanly/p/8784096.html最近由于需要开发测试环境管理工具,研究了下k8s的设计概念,过程中接触到了蓝绿部署、金丝雀部署、滚动部署等名词。好奇心的驱使就顺手查阅了下,而这篇博主的文章就写的比较的详细,所以把文章摘要出来了。有需要详解更多详情的朋友可以通过点击原文查看。文章目录传统发布金丝雀发布滚动更新蓝绿部署金丝...
最近由于需要开发测试环境管理工具,研究了下k8s的设计概念,过程中接触到了蓝绿部署、金丝雀部署、滚动部署等名词。
好奇心的驱使就顺手查阅了下,而这篇博主的文章就写的比较的详细,所以把文章摘要出来了。有需要详解更多详情的朋友可以通过点击原文查看。
传统发布
所谓的传统发布,就是那种在凌晨先停止全部服务,再进行全部服务升级,再启动全部服务的发布方式。
优点:简单成本低
缺点:服务会中断,发布/回退时间长
金丝雀发布
在传统发布流程的基础之上的一种改进发布方式。特点是先停止一台服务进行升级,上线后观察一段时间,
没有问题后再把剩余的服务全部一次性升级完成。那第一个升级的服务就是“金丝雀”。
优点:发布过程、发布异常对用户影响范围小
缺点:仍然会中断服务,发布/回退周期依然很长
“金丝雀”的由来是以前旷工开矿下矿洞前,先会放一只金丝雀进去探是否有有毒气体,看金丝雀能否活下来,金丝雀发布由此得名。
滚动更新
是在金丝雀部署模式上的一种改进,它的特点是持续滚动的进行单台服务更新,第一台服务更新的方式就是金丝雀部署。
优点:用户影响小,体验比较平滑
缺点:发布/回退时间长,需要发布工具支持。比如:k8s
蓝绿部署
一种适用于双服务器组发布的场景,它的特点是线上运行一组服务,线下再重新搭建一组升级的服务,最后通过一次性的流量切换到完成发布操作。
优点:升级切换/回退速度快
缺点:全量切换、用户影响范围大、需要双倍机器资源
由于是双服务器组,两组服务各不相同;一组为蓝组,则另一组为绿组,故称蓝绿部署。
金丝雀+蓝绿部署
一种结合金丝雀和蓝绿部署优点的部署方式。它的特点是先部署一台金丝雀,发布成功后,再通过蓝绿部署全量切换。
优点:降低全量发布风险、保障全量回退的速度
缺点:需要双倍机器资源
双倍资源 + 滚动部署
一种滚动部署的改进方式,它的特点是通过双倍资源来滚动部署,在保障发布过程平缓的情况下,保留全量回退的速度。
优点:发布平缓、回退快速
缺点:需要发布工具支持、需要双倍机器资源
其它发布模式
功能开关发布
这是一种在程序内部设置一个服务开关,通过外部配置中心的服务开关标识来打开和关闭服务。
优点:服务功能切换/回退快、实现方式简单
缺点:代码内容有冗余、全量切换升级失败影响大、对低版本不兼容
A/B测试发布
一种允许线上同时存在多个版本服务的发布方式。其目的是为了验证新版本服务的有效性,通过线上真实用户流量来评估新版本是否成功。
通常会应用在效果类、产品类的服务发布上。
优点:使用真实流量来验证、对用户影响小、可以进行特定人群测试
缺点:发布和数据收集平台复杂
影子测试发布
一种用于老版本服务重构的验收发布方式。它的特点是重构前后新老版本功能一致,希望通过模拟线上真实数据来验证新版本的正确性。
具体方式为:新老版本在线下各自部署相同的数据后台;再通过拉取线上日志进行回放,来模拟线上真实请求;最后对比新老版本的返回结果和数据库更新。
如果都保持一致,则表示新版功能上没有问题。
新书推荐
获取更多关于Python和自动化测试的文章,请扫描如下二维码!
更多推荐
所有评论(0)