如何设计实现开发自助重启工具-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，前提是先下流量，然后操作。
文件存储到对应的位置，方便用户下载+分析。
甚至可以提供对应的分析。