开发自助重启
说明：有时候研发产线需要重启，为了保证安全、或者说提升效率，最好有一个统一的研发自助重启页面。
这个功能可应用的发布有一些类似之处。那么这个功能具体应该如何实现呢？
整体设计
页面
可以让用户针对条件，来进行筛选过滤。
应用
机房
环境
分区
机器类别
机器标识
操作类型
详情
下方对应的操作列表，可以查看对应的详情信息。
可以附加一些状态的查询，保障用户相信平台，降低使用成本。
后端实现
前端点击之后，后端进行基本的属性校验之后，直接返回操作结果。
具体的执行，需要后端异步执行。避免前端过长时间的等待。
注意控制好对应的并发之类的，结合具体业务即可，越简单越好。
流程设计
1. 上下流量
保障下掉服务对应的 dubbo/http 等流量
1) dubbo 这种服务就需要调用对应的 dubbo 的 online/offline 操作。
2) http 可以调用 nginx 对应的配置，然后通过 reload 实现
3) mq 之类的如果想摘掉流量，就需要提供中间件层架的支持，可以指定 ip，下线对应的 consumer 信息，这个一般比较困难。
第三个相对而言还是比较困难的，但是可以同步补偿+幂等，来保证可以重复消费来解决这个问题。
注意点：
A. 最好相关的操作都有对应的 status 查询接口。不然不太好判断状态
B. 操作最好支持重复操作，这样失败了重试起来比较方便。
下流量前置
A. 保障一个分区的流量不能过低，比如不能低于 30%
B. 下流量之后，最好等待一段时间，或者用户验证完成流量不再进入才继续后续操作。
上流量前置
A. 必须保障服务的可用性，比如健康检查、readiness URL、无异常日志。
2. 服务重启
kvm 服务重启，其实可以细化为两个部分：
a. 服务停止
b. 服务启动
但是对于 k8s，可能存在一些不同。
a. 旧的 pod 流量下线
b. 创建新的 pod
c. 等待新 pod ready，上流量
d. 删除旧的 pod
这个是否一体化，取决于 PE 的脚本实现。
停服务前置
A. 停服务之前，流量必须下掉。避免请求依然进来。
启动服务检查项
A. 对应的包必须为指定的 md5sum
B. 项目的运行进程之类的，必须已经正常存在，且唯一。且是最新的。
C. 服务接入后处理正常
小结
尽可能的让流程自动化，降低用户的使用成本。
当然，背后需要很多团队的共同努力。
