可绑定可扩展的帐号系统设计原理及其实现(一)

转载：http://blog.cocosdever.com/2016/03/08/The-design-principle-and-implementation-of-extensible-account-system-1/

前言

　　在2016年春节前两个星期,我负责公司的新项目一元夺宝的个人中心的设计.主要的需求包括用户注册,登录,用户订单聚合,中奖数据查询等等.里面的用户注册和登录部分比较特殊,因为公司另一个产品要求夺宝项目的帐号系统能与其打通,实现另一个项目(下文简称B项目)的用户可以直接登录到夺宝项目上.B项目主要是依赖手机号码作为用户的帐号,而夺宝项目则允许用户通过手机号码注册,微信自动登录注册,QQ自动登录注册等等(下文统称第三方登录).同时要求已经使用手机号码注册的用户可以绑定自己的多个第三方帐号;只使用第三方帐号登录的用户也可以随时绑定自己的手机号,而新绑定的手机号也可以是B项目的手机号或者夺宝项目存在的帐号或者全新的号码,如果手机号已经注册的则将数据与手机号所在帐号合并.通过上述约束来实现所有帐号都互相打通,当然数据也要求互相打通.经过详细探讨,最终解决了这个特殊的需求.
　　现在春节过去了,我也在此总结分析一下这次的可扩展帐号系统的设计原理,而在下一篇文章中,我将介绍具体实现的技术细节.

需求场景

1. 每个用户都存在多个不同的注册登录方式,比如微信,QQ,微博.
2. 登录方式在未来可能增加或者减少.
3. 用户在使用不同的途径注册登录之后就成为独立帐号,每一个独立帐号又可以互相绑定.
4. 绑定之后的帐号视为一体,但是仍然可以使用不同途径登录.
5. 相互绑定之后的帐号,可能在系统留存大量数据,不适合数据迁移.
6. 用户的主要帐号(例如手机号)可以被多次绑定到不同的第三方帐号上,拥有相同主帐号的帐号视为同一帐号,数据互通.
   本文教程实现一个能满足以上描述的帐号系统,至于大家在实际项目中可以根据自己需求,在逻辑业务中禁止或允许用户相关行为.

难点分析

1. 随着时间推移,后期可能增加更多登录的途径,所以系统需要使用可扩展的方式实现
2. 假设用户已经用手机号码注册过(这里称为老帐号),此时如果使用微信登录并且完成了相关购买等,再绑定到老帐号上,这时候需要实现用户新旧数据合并,以确保前端展示的数据和用户的真实查询一致;如果再加入QQ登录并且绑定同个手机号,同样需要把QQ操作的数据绑定到老帐号上,拥有相同老帐号的帐号数据互通.此处也为一难点,需要灵活处理.
3. 用户绑定数据之后,其实就相当于只有一个主帐号被使用了.其他第三方帐号比如微信,在微信登录的时候,仍然需要通过微信特征(openid)进行用户登录验证.因此需要保留第三方帐号的关键数据,如果直接把这个关键数据所有字段放入帐号表,则以后多增加一种方式都需要去修改一下数据表字段,这显然是不可取.此处的设计也是一要点难点.

设计原理

　　难点分析一节已经描述了潜在的设计难点,接下来分别从数据库设计,程序逻辑设计两大部分阐述设计的原理

数据库设计

可扩展帐号系统的设计

Users表设计

　　相信大部分同学一开始想到的就是在users表中增加第三方登录的唯一表示字段.比如在users表的用户名,密码,基础上增加一个wx_openid,用来表示微信唯一标识,qq_openid用来表示QQ唯一标识.然后表的主要字段看起来就像这样:

id	phone(主帐号)	balance	nickname	wx_openid	qq_openid	weibo_openid	…
6	10086	1000(币)	啊C	aaa	bbb	ccc	…