@stonezhou 2019-01-16T12:16:26.000000Z 字数 4514 阅读 1406

Gearbest多账号体系方案

环球易购

需求背景

基于业务发展需求，G网需要将原有单email账号体系改为多账号体系。初步规划需要部分国家（灰度阶段：土耳其、巴西、德国、葡萄牙、西班牙）支持手机作为账号进行注册登录，后续会增加更多的国家，也会增加更多的注册登录方式，如：手机指纹、用户昵称等。
受制于红包裂变需求的需要，需要快速解决用户在参与红包裂变等拉新活动时，需要进行手机验证，业务提出的上线时间预期在2018年10月16日。

业务流转

待补充

方案说明

单邮箱账号体系升级为多账号体系中，需要将表结构进行优化，支持使用不同的注册登录形式。通过结构化的调整，不仅能满足红包裂变业务中需要手机短信校验的需求，同时也可以支持快速扩容，满足不同国家不同注册登录方式的个性化需求
基于userid唯一的账号维度下，支持通过不同的注册方式和登录方式。这其中userid和注册登录方式是分离的，可以根据业务需求随时增加支线流程，只需要补足配套的处理即可，支持快速扩张。而第三方授权作为业务约定俗称的注册登录方式之一，支持不断的横向扩展，支持接入各种第三方平台

注册方式：邮箱+密码、手机+验证码（手机+验证码+密码）、用户名+密码、第三方授权
登录方式：邮箱+密码、手机+密码、手机+验证码、用户名+密码、第三方授权、指纹登录、手势登录等
第三方授权：facebook、google、vk等

会员模块改动点

注册

注册形式包含：邮箱+密码、手机号+验证码（手机+验证码+密码）、登录名称（数字+字母形式，避免出现和电话、手机号相同的情况）+密码、第三方授权

注册流程中需要增加注册type判断，邮箱、手机号、登录名称均要做唯一性校验
第三方授权需要调整优化，当前第三方授权流程中实质上是基于邮箱账号体系下的关联绑定
- 仅通过第三方授权即可创建账号，无需在进行额外的邮箱或者手机号码关联绑定
- 从第三方获取的邮箱和手机号码需要进行判断，通过开关控制，第三方注册绑定已注册邮箱、电话，是否需要进行登录校验（为防止异常盗号，建议低信誉第三方开启）
  - 当出现邮箱或者电话单一重复的时候，需要提示已注册，让用户选择绑定登陆还是创建一个新账号
  - 当出现邮箱和电话均注册且为同一个账号的时候，需要提示已注册，让用户选择绑定登陆还是创建一个新账号
  - 当出现邮箱和电话均注册且不为同一个账号的时候，需要提示已注册，让用户选择绑定哪一个账号登录还是创建一个新账号
注册流程中需要在原有IP、设备号基础上，增加手机号码的禁止登录校验
配合前端传值，需要增加机器人注册的校验判断
手机短信防刷分为三层需要做校验
- 前端控制每隔60秒请求一次
- PHP层防控机器刷短信
- java增加根据设备、IP防刷限制，根据配置选择开启验证码等机器人校验流程，或者时间段禁止注册限制
根据登录账号类型需要分别进行欢迎新用户推送触发
- 邮箱注册需要推送欢迎邮件的发送
- 手机注册需要推送欢迎短信的发送（主要指针对仅用手机+验证码，系统初始化密码形式的注册）
- 第三方注册需要根据关联类型，分别进行邮件或者短信的欢迎推送（后续考虑增加对应第三方形式的推送，比如微信公众号这种）
不同类型注册行为涉及到的用户其它权益的配置
- 积分赠送
- 成长值赠送
- 新人礼包（不属于账号体系范畴）
区分国家进行个性化配置
- 注册类型入口开放国家配置
- 不同注册形式基于不同国家的校验方式配置
- 基于国家维度配置的前置流程，如：欧盟法案同意
- 基于国家维度配置的其它处理，如：自动订阅营销邮件

用户uesrid唯一，无论哪种方式均是登录在这个userid所属的账号
- 指纹登录和手势登录是基于已登录账号情况下，进行的绑定设置，需要服务端和设备端进行匹配校验（后续补充详细逻辑）
- 第三方授权登录沿用之前的流程，授权通过后，通过openid找到userid进行登录
- 支持在已登录情况下，用户补全其它形式的登录方式，限制每种登录形式唯一且仅有一个（其中第三方中每个类型仅限制一个）
登录流程中需要在原有IP、设备号基础上，增加手机号码的禁止登录校验
配合前端传值，需要增加机器人登录的校验判断
手机短信防刷分为三层需要做校验
- 前端控制每隔60秒请求一次
- PHP层防控机器刷短信
- java增加根据设备、IP防刷限制，根据配置选择开启验证码等机器人校验流程，或者时间段禁止注册限制
根据登录账号类型需要分别进行欢迎新用户推送触发
- 邮箱注册需要推送欢迎邮件的发送
- 手机注册需要推送欢迎短信的发送（主要指针对仅用手机+验证码，系统初始化密码形式的注册）
- 第三方注册需要根据关联类型，分别进行邮件或者短信的欢迎推送（后续考虑增加对应第三方形式的推送，比如微信公众号这种）
- 若均无，则不作推送，在首次绑定可推送登录方式后进行推送，支持后台可配置
不同类型注册行为涉及到的用户其它权益的配置
- 积分赠送
- 成长值赠送
区分国家进行个性化配置
- 登录类型入口开放国家配置
- 不同登录形式基于不同国家的校验方式配置

账号激活

验证账号的有效性后，才能进行核心业务流的操作，如：下单、个人中心查看等，在多账号体系中，虽然有多种注册和登录方式，但是能作为电商网站账号激活判断的（建议）为：邮箱验证、手机验证、第三方授权验证，因此在账号激活判断中，需要校验并提供多种激活方式

非邮箱、手机、第三方授权注册登录形式，需要进行账号校验，同时走其他登录方式绑定流程（校验userid唯一性，不做账号合并）
邮箱注册登录形式，需要进行邮箱是否激活判断，也可以选用手机号码或者第三方授权形式进行账号激活，需要走其他登录方式绑定流程（校验userid唯一性，不做账号合并）
手机号码+验证码、第三方授权形式，默认账号为已激活

其它登录方式绑定流程

已注册账号可以在原有登录方式基础上，增加其它登录方式的绑定。

账号归属校验：登录校验、第三方授权校验、手机+验证码校验、邮箱+验证码校验
绑定登录方式唯一性校验
userid唯一，不做账号合并

解绑流程

多账号体系中，账号解绑支持解除绑定

账号归属校验：登录校验、第三方授权校验、手机+验证码校验、邮箱+验证码校验
user_id下限制至少存在一种登录方式，支持后台可配置

找回密码

在用户无法登录情况下，支持找回密码

邮箱验证
手机+验证码
安全问题+账号资料（如：买过的商品、常用登录国家等）

修改密码

为增加账号安全性，会由系统主动触发或者用户主动操作，进行密码修改。通常在用户登录IP频繁、登录设备频繁或者账号进行高风险操作后，系统触发让用户修改密码后才能进行核心操作。

登录账号
输入旧密码进行校验（用户自主行为下）

访客模式

访客模式不需要默认邮箱处理，支持邮箱为空，相关节点进行优化

会员风控

账号服务核心指标有两个：一是系统的高可用性（稳定、快速），另外一个就是安全。坏人常用的攻击手段包括，机器模拟进行垃圾注册，通过暴力破解、刷库钓鱼等多种方式。一旦账号被攻破，所有用户数据都将会被泄露。所以一个完整的账号体系建设，要包含账号的安全攻防。
除在上述业务中提及的在流程本身需要处理的机器人防刷机制外，还需要在会员风控中额外增加其它维度的风险防控数据

账号维度下登录密码次数的防控，按时间段内输入密码错误次数进行机器人校验，或者找回密码限制
基于IP维度下下用户暴力破解密码的防控，按登录不同账号数量及输入密码错误次数进行机器人校验（时间段内）
增加电话号码维度的风险等级及限制行为
基于IP下手机短信验证码的防刷限制（时间段内）
基于账号维度下手机短信验证码的防刷限制（时间段内）

日志数据

注册日志
登录日志
用户数据变更日志（包含地址、修改密码、找回密码、解绑登录方式等）

涉及模块/系统

EMP

推送给EMP系统的数据需要区分用户含有的登录方式，变更后及时更新推送。由于EMP后续会对接第三方短信平台，建立公司自己的短信服务，因此还需要对接短信触发

登录方式中含有邮箱数据的账号进行推送，解绑变更需要通知
登录方式中含有手机号码数据的账号需要进行推送，解绑变更需要通知

SMS系统

针对GB的注销数据，需要增加限制，userid为必填项

各模块

需要支持邮箱为空的设定，基于各模块的需求进行不同登录方式数据的展示，如：手机号码、登录名称、邮箱、第三方等。其中需要额外注意的模块有

订单模块：下游OMS需要兼容修改
营销模块：在用户数据选择或者导入中，需呀将邮箱改为其他方式，如：标签等

从库数据

涉及到决策系统等从库获取数据的系统，需要进行数据兼容，修改表结构

数据迁移

待补充

里程碑

多账号体系作为基础模块中的基础流程，改动直接影响到网站的基础。在改动的过程中，不仅需要保证网站的稳定性，同时还要兼顾各种业务流转所需的用户数据。随着注册登录账号形式的多样化，需要收集更多的用户数据作为用户画像构建的基础内容。因此多账号体系的优化势在必行，但也要平缓过渡，需要通过多个里程碑进行处理，逐步完成升级过程

里程碑v0.1

预期时间：
截止到10.16
里程碑目标：
裂变红包增加手机号码校验
需求点范围：
方案一：
在现有单账号体系中，指定国家增加参与红包裂变活动需要增加手机号码校验。不仅能提高用户参与红包裂变红包活动的门槛，同时也能作为后续手机号码作为登录方式的数据收集。但该方案的存在劣势在于会增加用户参与活动的步骤和门槛，会降低用户的漏斗转化
方案二：
暂不调整表接口，额外增加手机号码作为账号登录方式，和现有流程隔离开。该方案能实现裂变红包中手机校验的需求，且能使用手机作为登录方式。但劣势在于不与现有逻辑吻合，会出现较多节点上的数据不兼容，需要配套修改的内容较多
方案三：
将手机号码视为第三方授权中的一种类型，通过手机号码+验证码“第三方授权”登录，系统默认邮箱来实现快速注册的表象，需要支持手机号码+密码的登录方式。该方案能满足红包裂变中手机校验的需求，但劣势在于手机号码作为第三方不仅会增加后续数据迁移的内容，还会出现前台展示默认邮箱的用户体验异样的问题
方案四：
按照方案设计中的方式进行表结构的优化，优先实现手机号码作为注册登录方式来满足业务需求。方案劣势在于该方案耗时较长，无法快速支持红包裂变活动的需求

里程碑v0.2

预期时间：
待定
里程碑目标：
待定
需求点范围：
待定

风险评估

十一月属于G网高峰期，过多的改动基础模块的基础业务，风险隐患较大，可能会影响正常售卖业务
多账号体系的核心价值在于兼容性、数据收集和个性化业务，基于目前G网的情况稍显超前，性价比较低
多账号体系的改动不仅涉及到周边系统的改动，同时涉及到业务方资源的投入，现阶段很难推动

参考文献