Dubbo 注册中心的发布上线有段时间常常出问题,发布注册中心就是一次冒险.
# 期间也因此吃了些故障.
为了解决这个问题, Dubbo Team 专门讨论过一次,梳理发布流程,给出问题的解决方法.
虽然针对的是 Dubbo 注册中心,其中的最佳实践是通用的.
关键字
角色 vs. 操作
操作者 & 检查者 (发布过程要 2 个人一起参与)
冷操作 vs. 热操作
读操作 vs. 写操作
原子操作 vs. 回滚操作
说明:
冷操作:在发布之前可以做好的操作,如机器确认,发布通知邮件.
热操作:线上发布操作过程的操作.
一定要充分考虑 "回滚操作".
原子操作的步骤的执行不能被中断.
有几次操作出错,都是的发布过程中被打断去做其它的事,导致步骤遗漏.上下文切换难免要出错.
Dubbo 注册中心发布的冷操作
发布前三天,通知网站应用升级时间,尽量避开核心应用发布
发布前一天,
DBA 升级数据库表结构
机器环境 & 软件 检查,如 Jetty,JDK6u25 的安装
打印好 Check List(即指发布操作过程的 Action Items,热操作)
Dubbo 注册中心发布的热操作
人员的状态保证
操作者
交出手机给检查者(人工防火墙),避免操作被打断
检查 Check List
按流程图来操作
操作者被打断时检查者需要接手,操作者需要先保证原子操作结束以及还原操作完成
检查者
检查 Check List
接收外部输入
执行操作
整个执行操作是一个原子操作.
通知相关发布群
记录注册中心上的数据
服务 (尤其是没有提供者服务)
机器
连接
开启 warm-up 状态
OPS 上传新版本包,重启升级应用
检查数据(遗漏则联系应用)
检查注册中心状态
没有 Active Task
查看 Error 日志
查看未知连接
DB 地址 Check
连接数已经稳定
关闭 warm-up 状态
还原静态数据为动态
检查数据(遗漏则联系应用)
检查注册中心状态
等待应用验证
上面的操作如有问题,执行回滚操作
回滚操作
记录静态的提供者,所有动态的转成静态
开启 warm-up 状态
OPS 回滚发布包
关闭 warm-up 状态
还原静态数据为动态
检查数据(遗漏则联系应用)
检查注册中心状态
后记
下层操作简单 是流程会有好结果的前提!对于复杂的操作,那再好流程也不会有好的结果的!!
# 关于如何去发现简化操作参见我的博文: 发布及其检查的自动化实践
最后放上,Dubbo 注册中心流程讨论时,大家一起看的视频: 一位 744 的老机长最后一次飞行
这个视频由 Ludvik_淘宝伯昊 找出来给大家看的.
希望发布能像这个老机长指挥下的飞行一样,一步一步沉着可靠,考虑了各种异常情况和对应的回滚措施,确保不会处于一个不可控的状态.
嗯,"让我们一起加入这万米云端的历险!!"
个人博客的博文地址: 准备一个安全可靠的发布流程
来源: http://it.taocms.org/03/51.htm