如果事情可能出错，就一定会出错。
一刀切迁移？
旧client 旧Server 有BUG会导致 数据丢失、 支撑不了压 力 一刀切 新DB 数据库缺少 必要数据 新系统 新client 新Server
旧DB
旧系统
结果是…
回滚 新系统无法上线测试
失败案例 (2)
某美国软件开发商给日本网络运营商开发了新的邮件系统，需要用新 的系统替换旧的系统 方案：将所有用户数据及邮件倒入新系统，结果… 用户数据开始迁移顺利，新系统运行正常了几天
物理搬迁，容易做成物理损坏 任一台机器物理损坏都会导致迁移失败
总结广研的方案
物理搬迁，风险大，而且劳民伤财。
在线系统平滑升级
在线系统升级要求
尽量保持7×24小时服务
用户不受任何影响或影响很小
DB平滑扩容
QQGame的DB分裂，不需停止用户的游戏过程
Db11
db12
db12
S1
S2
请用5分钟设计一个平滑扩容的方案
Server v1.1 1.0逻辑 1.1逻辑
同时包括 v1.0和v1.1 的逻辑代码
“协议跑得比server快，server跑得比client快”
QQServer代码例子
int CheckPassword(CONFIG* pstConfig, char *sPasswdHash, char *sMd5Value) { …
没回退性，风险太大，绝对不可行
广研的搬迁方案
方案二： 在广州IDC机房架设基本满足QQMAIL系统运营和存所 有QQMAIL数据的设备 在新设备上架设QQMAIL应用 使用工具软件让深圳与枢纽的数据进行同步 保证两地数据一致和应用一致后，修改DNS指向 QQMAIL服务由广州设备接替
if (pstConfig->stCinfo.shVersion < 900) { if (OicqDecrypt3(…)) { … } else return 0; } else { if (OicqDecrypt3(…)) { … } else return 0; }
} return 1;
多版本支持
23台备用机器
请用15分钟设计一个系统搬迁方案
提纲
搬迁和割接的风险 广研的搬迁方案
在线系统平滑升级
小版本迭代升级
迁移割接的目标
用户体验更好 减低搬迁的费用及风险 不采用任何可能做成错误或损失的迁移方式
搬迁和割接的风险
设备迁移?
错综复杂 的机房
IDC1 物理设备搬迁
IDC2
多版本不兼容
RTX3.61和RTX2005 多版本兼容 QQServer QQGame
QQServer支持超 过100个Client版 本 QQGame支持超过 6个Client版本
RTX2005不 兼容 RTX3.61
灰度割接
旧client 90% 95% 100% 旧Server 5%
在线系统迁移与升级
练习题
QQMAIL系统提供 @ 域名的邮件服务，原来是的网站部维护， 后来转由广州研发中心维护 广州研发中心为了日常维护方便，建议将QQMail从深圳枢纽机房搬迁 到广州电信较场西机房
注册用户约6千万 开通用户数约4千万 邮件存储总使用空间约13T 64台在用机器 深圳电信枢纽机房 2M专线 广州电信较场西机房
Client v1.0 Server v1.0
Client v1.1
Server v1.1
请用5分钟设计一个多版本兼容方案
多版本支持
Client v1.0 1.0逻辑
Server拒 绝非v1.0 特性
Server v1.0 1.0逻辑
Client v1.1 1.0逻辑 1.1逻辑
Client屏 蔽v1.1特 性 Server假 装v1.0
运行一周后，出现造成用户全部邮件丢失的bug
开发商以最快的速度修复软件bug，但用户邮件已经丢失，找不 回来
运营商威胁不支付软件费用
开发商用一年时间才使运营商恢复信心(幸运的是数据是分批倒 入的)
新系统存在bug是搬迁方案
方案一： 搬迁前准备，QQMAIL数据与应用完成备份； QQMAIL系统停服务； 修改DNS指向； 设备停机、下架、装车、由深圳搬运至广州、上架、 开机； QQMAIL在广州重新架设，重新提供服务；
DB平滑扩容
QQGame的DB分裂
只读不 改
DBSrv11/12 Proxy
修改路由 指到新的 DBSrv 作应用级 Cache
DBSrv12
Insert 到DB
Db11
db12
db12
S1
后台同步迁移(insert)
S2
主键 保证 唯一
多版本支持
QQGame软件版本升级，不需强制用户升级Client
系统在各省已建设完成，需要通过网络进行数据迁移操作。
方案：用10Mbit的网络带宽分批传输5Gbytes的数据，计划 数据传输需要时间1个多小时，共停止系统3个小时，结果…
网络质量抖动，传输用了3个多小时 数据倒入数据库，完成倒入接近85%时，数据库崩溃 数据库修复用了3个多小时 继续倒入直到完成为止(幸运的是当时设备及数据库都没有大的损坏)
结果可能是…
拨错线（电线、网线） 整柜跳线 搬错设备 运输过程摔坏
数据迁移？
有限的专 线网络带 宽
IDC1 海量的数 据
IDC2
结果是…
全套的设备投入
漫长的等待
复杂的增量同步 不可遇见的风险
失败案例 (1)
某运营商原来的用户数据是集中式处理，需要按省处理，新
一次迁移所有用户数据，操作时间长，风险不可控， 没长期需要而临时扩充带宽浪费资源
广研的搬迁方案
方案三： 同样需要架设一套基本与现有QQMAIL相同的系统：在 广州架设服务器，安装QQMAIL应用模块(WEBMAIL、 SMTP/POP3等)； 在深圳枢纽架设服务器，安装QQMAIL后台存储； 利用枢纽带宽，把旧系统数据同步到枢纽新存储上； 搬迁安装后台存储的服务器到广州，修改广州新系统 的配置，让应用与后台存储完成接合 再使用工具软件进行深广新旧系统数据增量同步； DNS切换，新系统提供服务；