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
谢谢!

人人-56 账号拆分项目总结