基于K8S和注册中心的一种版本快速回退方案
1.线上环境现状基于K8S容器化,spring cloud架构,eureka注册中心;通过jenkins发布;后端微服务使用AB版本发布(类似通常的蓝绿发布,我司内部俗称AB版本);2.引入AB版本的原因分步验证(个人觉得这个作用有限,类似实现了50%的灰度);服务未配置重试机制,为了防止发布过程中删除老版后调用方继续调用老服务导致报错,需要手动在注册中心下线老版服务,然后再删除;AB版本可以在删
1.线上环境现状
- 基于K8S容器化,spring cloud架构,eureka注册中心;
- 通过jenkins发布;
- 后端微服务使用AB版本发布(类似通常的蓝绿发布,我司内部俗称AB版本);
2.引入AB版本的原因
- 分步验证(个人觉得这个作用有限,类似实现了50%的灰度);
- 服务未配置重试机制,为了防止发布过程中删除老版后调用方继续调用老服务导致报错,需要手动在注册中心下线老版服务,然后再删除;
- AB版本可以在删除老版前快速回退
3.AB版本发布流程
因jenkins对上述步骤的界面化操作没有直接的插件支持,目前第3、4步都需要手动执 :
- 下线老版:jenkins发布新版后控制台输出curl命令,拷贝curl命令到任意一台linux服务器执行;
- 删除老版:在阿里云K8S控制台删除。
3.1.AB版本微服务的回退流程
- 删除老版前的回退:上线老版 => 下线新版 => 删除新版;
- 删除老版后的回退:和发布步骤相同。
3.2.回退耗时较长的原因
多个服务或全部服务发布完成后才发现的bug,如果要回退所有服务,耗时会比较长。
- 每个服务需要按照上述4步处理,且下线、删除需要手动执行;
- 下线操纵后需要访问注册中心WEB,确认下线成功;
- 删除操作风险大(误删在线的服务后果很严重),因此删除时要仔细确认;
- 不同服务的版本号不一致,回退要根据checklist仔细核对;
4.快速回退方案思考
快速回退甚至"秒级"回退,有以下要求:
- 操作简单直观、交互清晰,不易导致人为误操作;
- 保留所有发布的老版本,通过版本在注册中心的上下线实现回退,这是秒级回退必须用的方式,此外这种方式也要求提前准备足够的资源,空间换时间。
4.1.自研
封装所有需要手动的操作,服务发布彻底白屏化,能够在WEB页面直观显示服务名称、版本、容器状态、注册中心状态等信息,每个版本后都有上下线、删除按钮;
优点:AB版本发布的最理想状态,直观,简单,非运维也可以操作。
缺点:要完全自研,投入人力较大,周期长,不确定性较大。
4.2.jenkins
通过jenkins实现自研方案的目标;
目前jenkins没有能直接实现上述目标的功能和插件,考虑通过一二级单选按钮插件实现该功能。
优点:比自研方案实现难度低,周期短,主要通过插件调脚本实现。
缺点:没有自研方案直观,界面不够友好。
4.3.纯脚本
通过脚本实现自研方案的展示和交互效果,封装老版上线,新版下线功能,实现执行较少的几个步骤完成所有服务回退。
优点:实现较快,预计1个月内可以编写、测试、试运行完成。
缺点:比WEB方式体验要差,必须由运维操作。
5.脚本介绍
5.1.脚本说明
[root@iZ23omixdoyZ py_script]# tree -L 1
.
├── config.py – 配置文件
├── index.py – 入口,列表查询逻辑
├── ops.py – 操作逻辑(上下线、删除)
└── tools.py – 工具方法
5.2.配置config.py
发布前,修改配置文件config.py:
发布涉及的服务,将0修改为1、2、3……,按发布顺序指定。
5.3.脚本功能说明
5.4.脚本功能演示
1)发布时查看状态
2)下线服务
3)删除服务
4)快速回退
5.5.脚本错误控制
之前的发布\回退方式,除了操作不直观、繁琐(要在阿里云K8S控制台、Eureka注册中心、Linux服务器环境来回切换),还有一个重要的问题是无法控制误操作。
在阿里云控制台删除老版本,误操作风险较大:
多个服务要一起回退时,来回手动执行curl命令上下线、删除服务,更容易误操作。
脚本做了以下错误控制:
1)只有1个版本时不能下线
2)一个版本时下线状态时,不能下线另一个版本
3)上线状态的服务不能删除
4)IP出现重复,说明有bug,不允许执行任何修改
==完==
更多推荐
所有评论(0)