基于K8S和注册中心的一种版本快速回退方案

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版本微服务的回退流程

1. 删除老版前的回退：上线老版 => 下线新版 => 删除新版；
2. 删除老版后的回退：和发布步骤相同。

3.2.回退耗时较长的原因

多个服务或全部服务发布完成后才发现的bug，如果要回退所有服务，耗时会比较长。

1. 每个服务需要按照上述4步处理，且下线、删除需要手动执行；
2. 下线操纵后需要访问注册中心WEB，确认下线成功；
3. 删除操作风险大（误删在线的服务后果很严重），因此删除时要仔细确认；
4. 不同服务的版本号不一致，回退要根据checklist仔细核对；

4.快速回退方案思考

快速回退甚至"秒级"回退，有以下要求：

1. 操作简单直观、交互清晰，不易导致人为误操作；
2. 保留所有发布的老版本，通过版本在注册中心的上下线实现回退，这是秒级回退必须用的方式，此外这种方式也要求提前准备足够的资源，空间换时间。

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，不允许执行任何修改

==完==