Dubbo注册中心的发布上线有段时间常常出问题，发布注册中心就是一次冒险。
# 期间也因此吃了些故障。

为了解决这个问题， Dubbo Team专门讨论过一次，梳理发布流程，给出问题的解决方法。

虽然针对的是Dubbo注册中心，其中的最佳实践是通用的。

关键字

1. 角色 vs. 操作
   操作者 & 检查者 （发布过程要2个人一起参与）
2. 冷操作 vs. 热操作
3. 读操作 vs. 写操作
4. 原子操作 vs. 回滚操作

说明：

• 冷操作：在发布之前可以做好的操作，如机器确认，发布通知邮件。
• 热操作：线上发布操作过程的操作。
• 一定要充分考虑“回滚操作”。
• 原子操作的步骤的执行不能被中断。
  有几次操作出错，都是的发布过程中被打断去做其它的事，导致步骤遗漏。上下文切换难免要出错。

Dubbo注册中心发布的冷操作

1. 发布前三天，通知网站应用升级时间，尽量避开核心应用发布
2. 发布前一天，
   • DBA升级数据库表结构
   • 机器环境 & 软件 检查，如Jetty、JDK6u25的安装
3. 打印好Check List（即指发布操作过程的Action Items，热操作）

Dubbo注册中心发布的热操作

人员的状态保证

• 操作者
  1. 交出手机给检查者（人工防火墙），避免操作被打断
  2. 检查Check List
  3. 按流程图来操作
  4. 操作者被打断时检查者需要接手，操作者需要先保证原子操作结束以及还原操作完成
• 检查者
  1. 检查Check List
  2. 接收外部输入

执行操作

整个执行操作是一个原子操作。

1. 通知相关发布群
2. 记录注册中心上的 数据
   • 服务 (尤其是没有提供者服务)
   • 机器
   • 连接
3. 开启warm-up状态
4. OPS上传新版本包，重启升级应用
5. 检查 数据（遗漏则联系应用）
6. 检查注册中心状态
   • 没有Active Task
   • 查看 Error日志
   • 查看未知连接
   • DB地址Check
   • 连接数已经稳定
7. 关闭warm-up状态
8. 还原静态数据为动态
9. 检查数据（遗漏则联系应用）
10. 检查注册中心状态
11. 等待应用验证
12. 上面的操作如有问题，执行回滚操作

回滚操作

1. 记录静态的提供者，所有动态的转成静态
2. 开启warm-up状态
3. OPS回滚发布包
4. 关闭warm-up状态
5. 还原静态数据为动态
6. 检查数据（遗漏则联系应用）
7. 检查注册中心状态

后记

下层操作 简单 是流程会有好结果的前提！对于复杂的操作，那再好流程也不会有好的结果的！！
# 关于如何去发现简化操作参见我的博文： 发布及其检查的自动化实践

最后放上，Dubbo注册中心流程讨论时，大家一起看的视频： 一位744的老机长最后一次飞行
这个视频由 Ludvik_淘宝伯昊找出来给大家看的。

希望发布能像这个老机长指挥下的飞行一样，一步一步沉着可靠，考虑了各种异常情况和对应的回滚措施，确保不会处于一个不可控的状态。

嗯，“让我们一起加入这万米云端的历险！！”

个人博客的博文地址： 准备一个安全可靠的发布流程