56- 人人账号拆分

技术部 kim

Why 账号合并？

• 公司并购的惯用手段

Why 账号拆分？

• 账号重合度不高

• 56 不适合实名制

• 增加了人人同事的工作量

• 人人对账号安全的要求较高

账号拆分难点？

• 合并时特别复杂

• 程序 bug 和问题账号

• 入口多、 QA 覆盖难

• 持续时间长、人员流动

• 保证切换期间平滑过渡

拆分旧方案

• DB 、 Server 整套复制

• 程序搬到 user.56.com/2013/ 目录

• 人人回导数据和增量

• 线上应用灰度切换至新 Server

优点• 切换平滑，步骤清晰

• 影响较小、可控

• 新旧 2 套互为备份，又互不影响

缺点• 战线拖太长• 两套代码维护困难• 过于区分数据，会导致很多问题账号• 修改太多，沟通成本高（人人方面）• 两个数据库，问题账号处理困难• 移动端实际上无法灰度

拆分新方案

• DB 、 Server 沿用当前

• 沿用当前代码，在程序中做兼容

• 人人数据回导时，不区分，拆表存储

• 整体切换上线

优点• 战线短• 占用资源少• 有问题会立刻浮现• 数据全、兼容性极高• 不需要增量同步，大大降低沟通成本• 解决大表问题• 解决频繁更新登录状态的问题

缺点

方案制定和选择

• KISS 原则

六个关键性问题

• 1 、新 56 注册到新 56 登录

• 2 、新 56 注册到旧 56 登录

• 3 、旧 56 注册到新 56 登录

• 4 、旧 56 注册到旧 56 登录

• 同 #3

• 5 、老用户到新 56 登录

• 拆分前后，将人人的数据导入 56 的现有用户库，保证导数据完整就可以解决

• 6 、老用户到旧 56 登录

• 人人登录注册接口必须保持在线，只到 56所有登录注册接口都切回 56 自己

拆分前的准备

一、安全中心

二、人人登录状态

• 去掉全站对人人登录状态的检查，即不会再跳出类似“检测到您已经登录人人了”的弹层

三、后台密码管理

四、人人 connect 登录

五、登出接口

• 登出接口纳入 user• http://user.56.com/logout

拆分开始

• 1 、人人导出数据，比如 rr_account.dat ，进行初始化的简单过滤

• 2 、把 rr_account.dat 原封不动导入分表中

• 3 、根据 用户 id 创建用户登录状态记录分表

• 4 、前端页面和 Javascript 做好兼容后先上线

• 5 、人人 connect 登录上线

• 6 、所有经过人人的登录注册回调，都经过新表

• 7 、最重要的兼容程序上线， bug 修复。

• 8 、人人再次导数据，修复从第一次初始化到兼容上线之间，所缺失或者错误的数据

• PS：真的需要增量吗？

• 9 、新版登录注册页面上线，安全中心上线

• 10 、疑难账号处理，随机应变

• 11 、人人最后一次导全量数据

遇到的坑

• 1 、账号小写的问题

• 2 、依赖 56 账号的站外应用，需要独立的安全中心（比如我秀）

• 3 、有账号重复的情况，通过密码不同来区分。

• 4 、 邮箱绑定 56字符串账号的问题

• 5 、用邮箱注册的时候，账号其实是应该作为默认安全邮箱使用的

总结

• 抓重点矛盾

• 以旁观者的身份看问题

• 充分了解业务是补锅的前提

后续• 修改我秀、群歌、游戏登录注册• 修改 app客户端 登录注册• 修改 ican2 、 ican3 登录注册• 修改 m.56.com 登陆注册• 完善登录注册统计

FAQ

谢谢！