如何设计实现开发自助重启工具-01-设计篇

自助重启系列

如何设计实现开发自助重启工具-01-设计篇

应用部署作业-02-流程

如何实现自助重启-03-实现篇

开发自助重启

说明：有时候研发产线需要重启，为了保证安全、或者说提升效率，最好有一个统一的研发自助重启页面。

这个功能可应用的发布有一些类似之处。

流程设计

1. 下流量

保障下掉服务对应的 dubbo/http 等流量

调用对应的接口，可以查看对应的状态。

或者有对应的流量监控：cat + 日志 等等。最好是等待一段时间，保障流量已经下掉。

2. 服务重启

kvm 服务重启，其实可以细化为两个部分：

a. 服务停止

b. 服务启动

但是对于 k8s，可能存在一些不同。

a. 旧的 pod 流量下线

b. 创建新的 pod

c. 等待新 pod ready，上流量

d. 删除旧的 pod

这个是否一体化，取决于 PE 的脚本实现。

3. 上流量

保障服务对应的 dubbo/http 等流量已正确上线。

调用对应的接口，可以查看对应的状态。

或者有对应的流量监控：cat + 日志 等等。最好是等待一段时间，保障流量已经上线。

注意点

cmdb 支撑

需要 cmdb 的底层支撑，不然这么多的机器信息无法维护，不够正确。

podIp 的变化

pod 重启之后，如何获取最新的 ip，再查询一遍吗？

页面设计

业务域：
应用名：
机房：
环境：
分组：
机器分类：
机器列表：
操作：【提交】【查询】

下方有对应的操作记录+操作明细。

# 流量下线(总数)                       处理状态 | 2025-6-21 00:05:08操作时间：${startTime} ~ ${endTime}
操作信息：是否存在异常？
操作人：admin
xxx| id | 机器类型 | 机器标识 | 开始时间 | 结束时间 | 处理状态 | 处理信息 |
| 1 | kvm | 127.0.0.1 | 2025-6-21 00:06:40 | 2025-6-21 00:07:43 | 成功 | 已完成 | 
| 2 | k8s | podName | 2025-6-21 00:06:40 | 2025-6-21 00:07:43 | 成功 | 已完成 |

表记录

需要有一个主从表，存储对应的操作信息+操作明细。

分组

所有的发布，应用都应该分组。

pre-prod 准生产

gray 灰度 这个未必要这么设计，要看灰度是如何设计的。

组1/组2之类的。

分组用户自己定义即可，没有必要严格的设置。

小结

类似的，也可以实现一下 jstack jdump，前提是先下流量，然后操作。

文件存储到对应的位置，方便用户下载+分析。

甚至可以提供对应的分析。