自助重啟系列
如何設計實現開發自助重啟工具-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,前提是先下流量,然后操作。
文件存儲到對應的位置,方便用戶下載+分析。
甚至可以提供對應的分析。