在线系统迁移与升级方案
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
如果事情可能出错，就一定会出错。
一刀切迁移？
旧client 旧Server
旧DB
有BUG会导致 数据丢失、 支撑不了压
力
一刀切
旧系统
➢结果是…
➢回滚 ➢新系统无法上线测试
数据库缺少 必要数据
新client 新Server
新DB 新系统
失败案例 (2)
➢ 某美国软件开发商给日本网络运营商开发了新的邮件系统，需要用新 的系统替换旧的系统
谢谢
Server Client
10个1.0 9个1.0 7个1.0 10个1.1 …
1个1.1 3个1.1
100万1.0 100万1.0 90万1.0 …
…
n个1.1 10万1.1
Dayn
10个1.1 100万1.1
小版本迭代升级
单机软件发布
时间 W1 W2 W3 W4 W5 W6 W7 W8 W9 … Wn 单机 α1 α2 α3 α4 α5 α6 α7 α8 α9 … αn
盒装软件 发行软件
β1 一旦出错，β2付出
的成本非常高
build50 次 固定时间 出β版
制作光盘， RTM
“千里走钢丝”
β3 Goldenβ
代码越多，出 错的机会越大
网络软件快速验证
时间 W1 W2 W3 W4 W5 W6 W7 W8 W9 … Wn α版本 α1 α2 α3 α4 α5 α6 α7 α8 α9 … αn
➢ 方案：将所有用户数据及邮件倒入新系统，结果… 用户数据开始迁移顺利，新系统运行正常了几天 运行一周后，出现造成用户全部邮件丢失的bug 开发商以最快的速度修复软件bug，但用户邮件已经丢失，找不 回来 运营商威胁不支付软件费用 开发商用一年时间才使运营商恢复信心(幸运的是数据是分批倒 入的)
➢多版本不兼容 ➢RTX3.61和RTX2005
➢多版本兼容 ➢QQServer ➢QQGame
RTX2005不 兼容 RTX3.61
✓ QQServer支持超 过100个Client版 本
✓ QQGame支持超过 6个Client版本
灰度割接
旧client
5%
19050%%
旧Server
先割一少部 分用户
旧系统
➢好处是…
再用少部分 用户压力， 方便测试新
系统
➢用户体验影响最小 ➢设备投入少
➢不存在大风险，随时可以回滚
➢容易对新系统的测试及问题定位
新client 5%
新Server
新系统
灰度割接
➢分时间的逐步升级步骤
➢有10台server ➢有100万个client
Day1 Day2 Day3 Day4 …
Client屏 蔽v1.1特
性
Server假 装v1.0
同时包括 v1.0和v1.1 的逻辑代码
“协议跑得比server快，server跑得比client快”
QQServer代码例子
int CheckPassword(CONFIG* pstConfig, char *sPasswdHash, char *sMd5Value) {
➢ 方案：用10Mbit的网络带宽分批传输5Gbytes的数据，计划 数据传输需要时间1个多小时，共停止系统3个小时，结果…
网络质量抖动，传输用了3个多小时 数据倒入数据库，完成倒入接近85%时，数据库崩溃 数据库修复用了3个多小时 继续倒入直到完成为止(幸运的是当时设备及数据库都没有大的损坏)
DB平滑扩容
➢QQGame的DB分裂
只读不 改
Proxy
修改路由 指到新的 DBSrv
作应用级 Cache
DBSrv11/12
DBSrv12
Insert 到DB
Db11 db12
db12
后台同步迁移(insert)
S1
S2
主键 保证 唯一
多版本支持
➢QQGame软件版本升级，不需强制用户升级Client
IDC1
IDC2
➢结果可能是…
拨错线（电线、网线） 整柜跳线 搬错设备 运输过程摔坏
物理设备搬迁
数据迁移？
有限的专 线网络带
宽
IDC1
海量的数 据
IDC2
➢结果是…
全套的设备投入
漫长的等待
复杂的增量同步
不可遇见的风险
失败案例 (1)
➢ 某运营商原来的用户数据是集中式处理，需要按省处理，新 系统在各省已建设完成，需要通过网络进行数据迁移操作。
物理搬迁，容易做成物理损坏 任一台机器物理损坏都会导致迁移失败
总结广研的方案
物理搬迁，风险大，而且劳民伤财。
在线系统平滑升级
在线系统升级要求
➢尽量保持7×24小时服务 ➢用户不受任何影响或影响很小
DB平滑扩容
➢QQGame的DB分裂，不需停止用户的游戏过程
Db11 db12
db12
S1
S2
➢请用5分钟设计一个平滑扩容的方案
在线系统迁移与升级
练习题
➢ QQMAIL系统提供 @qq.com 域名的邮件服务，原来是的网站部维护， 后来转由广州研发中心维护
➢ 广州研发中心为了日常维护方便，建议将QQMail从深圳枢纽机房搬迁 到广州电信较场西机房
➢注册用户约6千万 ➢开通用户数约4千万 ➢邮件存储总使用空间约13T ➢64台在用机器
β版本
系统测试
β1
时间跨度大，bug多
β2
Full Testing
β3
时间窗
R
快速验证
R1
R2
时间短，bug少
Day1(1%-10%) Day2(10%-20%)
Dayn(20%-100%)
“时间剪载功能”
灰度割 接
总结
➢迁移 避免物理搬迁 减少物理复制 由应用做平滑扩容
➢升级 多版本兼容 灰度割接 小版本迭代
新系统存在bug是难以避免。
广研的搬迁方案
广研的搬迁方案
方案一： ✓ 搬迁前准备，QQMAIL数据与应用完成备份； ✓ QQMAIL系统停服务； ✓ 修改DNS指向； ✓ 设备停机、下架、装车、由深圳搬运至广州、上架、
开机； ✓ QQMAIL在广州重新架设，重新提供服务；
没回退性，风险太大，绝对不可行
广研的搬迁方案
方案三： ✓ 同样需要架设一套基本与现有QQMAIL相同的系统：在
广州架设服务器，安装QQMAIL应用模块(WEBMAIL、 SMTP/POP3等)； 在深圳枢纽架设服务器，安装QQMAIL后台存储； ✓ 利用枢纽带宽，把旧系统数据同步到枢纽新存储上； ✓ 搬迁安装后台存储的服务器到广州，修改广州新系统 的配置，让应用与后台存储完成接合 ✓ 再使用工具软件进行深广新旧系统数据增量同步； ✓ DNS切换，新系统提供服务；
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逻辑
Server v1.1 1.0逻辑 1.1逻辑
…
if (pstConfig->stCinfo.shVersion < 900) {
if (OicqDecrypt3(…)) {
… } else return 0; } else { if (OicqDecrypt3(…)) {
… } else return 0; }
return 1; }
多版本支持
广研的搬迁方案
方案二： ✓ 在广州IDC机房架设基本满足QQMAIL系统运营和存所
有QQMAIL数据的设备 ✓ 在新设备上架设QQMAIL应用 ✓ 使用工具软件让深圳与枢纽的数据进行同步 ✓ 保证两地数据一致和应用一致后，修改DNS指向 ✓ QQMAIL服务由广州设备接替
一次迁移所有用户数据，操作时间Βιβλιοθήκη Baidu，风险不可控， 没长期需要而临时扩充带宽浪费资源
深圳电信枢纽机房
2M专线
➢23台备用机器 广州电信较场西机房
➢ 请用15分钟设计一个系统搬迁方案
提纲
搬迁和割接的风险 广研的搬迁方案 在线系统平滑升级 小版本迭代升级
迁移割接的目标
➢用户体验更好 ➢减低搬迁的费用及风险 ➢不采用任何可能做成错误或损失的迁移方式
搬迁和割接的风险
设备迁移?
错综复杂 的机房
一刀切迁移？
旧client 旧Server
旧DB
有BUG会导致 数据丢失、 支撑不了压
力
一刀切
旧系统
➢结果是…
➢回滚 ➢新系统无法上线测试
数据库缺少 必要数据
新client 新Server
新DB 新系统
失败案例 (2)
➢ 某美国软件开发商给日本网络运营商开发了新的邮件系统，需要用新 的系统替换旧的系统
谢谢
Server Client
10个1.0 9个1.0 7个1.0 10个1.1 …
1个1.1 3个1.1
100万1.0 100万1.0 90万1.0 …
…
n个1.1 10万1.1
Dayn
10个1.1 100万1.1
小版本迭代升级
单机软件发布
时间 W1 W2 W3 W4 W5 W6 W7 W8 W9 … Wn 单机 α1 α2 α3 α4 α5 α6 α7 α8 α9 … αn
盒装软件 发行软件
β1 一旦出错，β2付出
的成本非常高
build50 次 固定时间 出β版
制作光盘， RTM
“千里走钢丝”
β3 Goldenβ
代码越多，出 错的机会越大
网络软件快速验证
时间 W1 W2 W3 W4 W5 W6 W7 W8 W9 … Wn α版本 α1 α2 α3 α4 α5 α6 α7 α8 α9 … αn
➢ 方案：将所有用户数据及邮件倒入新系统，结果… 用户数据开始迁移顺利，新系统运行正常了几天 运行一周后，出现造成用户全部邮件丢失的bug 开发商以最快的速度修复软件bug，但用户邮件已经丢失，找不 回来 运营商威胁不支付软件费用 开发商用一年时间才使运营商恢复信心(幸运的是数据是分批倒 入的)
➢多版本不兼容 ➢RTX3.61和RTX2005
➢多版本兼容 ➢QQServer ➢QQGame
RTX2005不 兼容 RTX3.61
✓ QQServer支持超 过100个Client版 本
✓ QQGame支持超过 6个Client版本
灰度割接
旧client
5%
19050%%
旧Server
先割一少部 分用户
旧系统
➢好处是…
再用少部分 用户压力， 方便测试新
系统
➢用户体验影响最小 ➢设备投入少
➢不存在大风险，随时可以回滚
➢容易对新系统的测试及问题定位
新client 5%
新Server
新系统
灰度割接
➢分时间的逐步升级步骤
➢有10台server ➢有100万个client
Day1 Day2 Day3 Day4 …
Client屏 蔽v1.1特
性
Server假 装v1.0
同时包括 v1.0和v1.1 的逻辑代码
“协议跑得比server快，server跑得比client快”
QQServer代码例子
int CheckPassword(CONFIG* pstConfig, char *sPasswdHash, char *sMd5Value) {
➢ 方案：用10Mbit的网络带宽分批传输5Gbytes的数据，计划 数据传输需要时间1个多小时，共停止系统3个小时，结果…
网络质量抖动，传输用了3个多小时 数据倒入数据库，完成倒入接近85%时，数据库崩溃 数据库修复用了3个多小时 继续倒入直到完成为止(幸运的是当时设备及数据库都没有大的损坏)
DB平滑扩容
➢QQGame的DB分裂
只读不 改
Proxy
修改路由 指到新的 DBSrv
作应用级 Cache
DBSrv11/12
DBSrv12
Insert 到DB
Db11 db12
db12
后台同步迁移(insert)
S1
S2
主键 保证 唯一
多版本支持
➢QQGame软件版本升级，不需强制用户升级Client
IDC1
IDC2
➢结果可能是…
拨错线（电线、网线） 整柜跳线 搬错设备 运输过程摔坏
物理设备搬迁
数据迁移？
有限的专 线网络带
宽
IDC1
海量的数 据
IDC2
➢结果是…
全套的设备投入
漫长的等待
复杂的增量同步
不可遇见的风险
失败案例 (1)
➢ 某运营商原来的用户数据是集中式处理，需要按省处理，新 系统在各省已建设完成，需要通过网络进行数据迁移操作。
物理搬迁，容易做成物理损坏 任一台机器物理损坏都会导致迁移失败
总结广研的方案
物理搬迁，风险大，而且劳民伤财。
在线系统平滑升级
在线系统升级要求
➢尽量保持7×24小时服务 ➢用户不受任何影响或影响很小
DB平滑扩容
➢QQGame的DB分裂，不需停止用户的游戏过程
Db11 db12
db12
S1
S2
➢请用5分钟设计一个平滑扩容的方案
在线系统迁移与升级
练习题
➢ QQMAIL系统提供 @qq.com 域名的邮件服务，原来是的网站部维护， 后来转由广州研发中心维护
➢ 广州研发中心为了日常维护方便，建议将QQMail从深圳枢纽机房搬迁 到广州电信较场西机房
➢注册用户约6千万 ➢开通用户数约4千万 ➢邮件存储总使用空间约13T ➢64台在用机器
β版本
系统测试
β1
时间跨度大，bug多
β2
Full Testing
β3
时间窗
R
快速验证
R1
R2
时间短，bug少
Day1(1%-10%) Day2(10%-20%)
Dayn(20%-100%)
“时间剪载功能”
灰度割 接
总结
➢迁移 避免物理搬迁 减少物理复制 由应用做平滑扩容
➢升级 多版本兼容 灰度割接 小版本迭代
新系统存在bug是难以避免。
广研的搬迁方案
广研的搬迁方案
方案一： ✓ 搬迁前准备，QQMAIL数据与应用完成备份； ✓ QQMAIL系统停服务； ✓ 修改DNS指向； ✓ 设备停机、下架、装车、由深圳搬运至广州、上架、
开机； ✓ QQMAIL在广州重新架设，重新提供服务；
没回退性，风险太大，绝对不可行
广研的搬迁方案
方案三： ✓ 同样需要架设一套基本与现有QQMAIL相同的系统：在
广州架设服务器，安装QQMAIL应用模块(WEBMAIL、 SMTP/POP3等)； 在深圳枢纽架设服务器，安装QQMAIL后台存储； ✓ 利用枢纽带宽，把旧系统数据同步到枢纽新存储上； ✓ 搬迁安装后台存储的服务器到广州，修改广州新系统 的配置，让应用与后台存储完成接合 ✓ 再使用工具软件进行深广新旧系统数据增量同步； ✓ DNS切换，新系统提供服务；
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逻辑
Server v1.1 1.0逻辑 1.1逻辑
…
if (pstConfig->stCinfo.shVersion < 900) {
if (OicqDecrypt3(…)) {
… } else return 0; } else { if (OicqDecrypt3(…)) {
… } else return 0; }
return 1; }
多版本支持
广研的搬迁方案
方案二： ✓ 在广州IDC机房架设基本满足QQMAIL系统运营和存所
有QQMAIL数据的设备 ✓ 在新设备上架设QQMAIL应用 ✓ 使用工具软件让深圳与枢纽的数据进行同步 ✓ 保证两地数据一致和应用一致后，修改DNS指向 ✓ QQMAIL服务由广州设备接替
一次迁移所有用户数据，操作时间Βιβλιοθήκη Baidu，风险不可控， 没长期需要而临时扩充带宽浪费资源
深圳电信枢纽机房
2M专线
➢23台备用机器 广州电信较场西机房
➢ 请用15分钟设计一个系统搬迁方案
提纲
搬迁和割接的风险 广研的搬迁方案 在线系统平滑升级 小版本迭代升级
迁移割接的目标
➢用户体验更好 ➢减低搬迁的费用及风险 ➢不采用任何可能做成错误或损失的迁移方式
搬迁和割接的风险
设备迁移?
错综复杂 的机房