业务中台建设 - C 端用户中心
业务场景
互联网公司，自主开发内部系统
多条业务线产品，涉及到 toC/toB、交易/SaaS 等领域
名词解释
用户
app 的使用者，操作的主体对象。
对于面向 C 端的产品来说，“用户”比较明确，例如 你是淘宝的用户，用手机号注册使用，你就是淘宝的用户。
对于面向 B 端的产品来说，有员工有企业，企业下有多个员工，不同员工有不同的权限。“用户”指代的是 B 端产品的操作主体，指的是员工用户，用户根据其拥有的权限，代替企业进行行为操作。
登陆账号
用户要登陆 app，而登陆的方式有很多，用户名/密码登陆、手机号短信验证码登陆、第三方授权登陆...
不同的登陆方式对应的是不同的账号，用户账号、手机号账号、微信授权账号等等
一个用户可以有 1 个或多个登陆账号，通过同一个用户的不同登陆账号登陆后，是以用户为主体进行操作。
客户
在现实世界中，客户是为产品或服务买单的人。
对于面向 C 端的产品来说，客户就是用户。
对于面向 B 端的产品来说，客户是企业。
线索
会员
账号
自然人
认证
划定边界
toC 端的用户
用户注册、登录、认证三大功能
对于上述的业务场景，涉及到很多的实体，简化的业务流程可能是这样的：
某自然人 A 对企业的产品含兴趣，留了自己的手机号，成为一条线索
企业 B 的员工 C 收到了 A 的线索，并打电话给 A 介绍了公司的产品
A 下载 app 并用手机号注册，成为了一个用户，然后绑定了微信登陆
用户看中了 app 上的某个产品，在 app 的引导下完成了实名认证，成为会员，下单并支付
企业员工登陆商家端系统，看到了订单，并确认然后发货。
很复杂，基于此可以得出一个模型图
本文重点考虑 C 端用户域的设计方案，原因是 C 端用户方面可复用度较高，核心是 C 端用户的身份识别、登陆账号以及实名认证后得到的自然人模型。
设计要点
生命周期
作为主要模型，C 端用户要有自己的状态，有自己的生命周期
未注册
通过线索或者其他渠道获得的用户信息也会加入到系统中，原因是需要做统一的 ID 打通，未注册和已注册的用户使用同一个 ID，其他业务系统只要关注一个对象即可。
这部分用户是没有主动注册的，因此需要通过状态特殊标识出来。
已注册
用户主动发起注册后，即为此状态
已认证
用户注册后，经过了实名认证，可信度很高。
这里可以有另一种做法，独立出一个字段来表示是否认证
已注销
用户可以选择主动注销
业务隔离
C 用户用户要支持多条业务线，不同 app。同一个手机号在不同的 app 中，是否同一条用户记录；业务表现上即是否互相影响，修改了手机号 137xxxxxxxx 在 app A 中的信息，在 app B 中信息是否会变更；在 app A 中注销了手机号 137xxxxxxxx 对应的用户，app B 中是否会注销。
方案 1: 统一用户
代表：阿里巴巴、美团
该方案需要在 app 的产品功能设计上，告知用户采用统一用户方案
方案 2: 各 app 业务隔离
用户在不同的 app 上感知到的两个 app 没有关系。
具体选用哪个方案需要公司产品研发决策层达成一致意见，从上层统一规划。
注销用户
根据国家标准 GBT+35273-2020《信息安全技术+个人信息安全规范》中对于注销用户的要求
8.5 个人信息主体注销账户
对个人信息控制者的要求包括:
通过注册账户提供产品或服务的个人信息控制者，应向个人信息主体提供注销账户的方法，且方法简便易操作;
受理注销账户请求后，需要人工处理的，应在承诺时限内(不超过 15 个工作日)完成核查和处理;
注销过程如需进行身份核验，要求个人信息主体再次提供的个人信息类型不应多于注册、使用等服务环节收集的个人信息类型;
注销过程不应设置不合理的条件或提出额外要求增加个人信息主体义务，如注销单个账户视同注销多个产品或服务，要求个人信息主体填写精确的历史操作记录作为注销的必要条件等;
注 1:多个产品或服务之间存在必要业务关联关系的，例如，一旦注销某个产品或服务的账户，将会导致其他产品或服务的必要业务功能无法实现或者服务质量明显下降的，需向个人信息主体进行详细说明。
注 2:产品或服务没有独立的账户体系的，可采取对该产品或服务账号以外其他个人信息进行删除，并切断账户体系与产品或服务的关联等措施实现注销。
注销账户的过程需收集个人敏感信息核验身份时，应明确对收集个人敏感信息后的处理措施，如达成目的后立即删除或匿名化处理等;
个人信息主体注销账户后，应及时删除其个人信息或匿名化处理。因法律规规定需要留存个人信息的，不能再次将其用于日常业务活动中。
匿名化：通过对个人信息的技术处理，使得个人信息主体无法被识别或者关联，且处理后的信息不能被复原的过程。
注:个人信息经匿名化处理后所得的信息不属于个人信息。
整理出几个关键点
app 需要给用户提供注销的功能
注销后，应该删除个人信息或者进行匿名化处理。
一般在系统建设中不会直接删除数据，尤其是这种底层的 ID，被各个系统落库使用，删除后容易造成数据不一致。因此匿名化是更好的选择，需要对用户手机号、名称和认证信息等关键字段进行混淆处理，比如 通过 MD5 算法修改为不可逆的字符串。
注销用户的流程为：
验证当前用户的身份。注销用户属于高危操作，一般可以通过手机号验证码。
检查当前用户是否可注销。例如 有一些在途订单需要完成
对用户信息进行匿名化处理。
修改用户状态为已注销。
广播通知，其他系统可能有需要处理的事情
强制退出登陆。
用户身份识别
通过业务主键能唯一识别一个用户， 常见的业务主键有手机号、微信号、邮箱、用户名等，对于一个用户可以有多个业务主键。如下图为例
用户 ID 手机号微信号 100113700000001wx00a100213700000002wx00b
对于第一个用户来说，通过手机号(13700000001) 或 微信号(wx00a) 找到的是同一个用户。
实际场景中为了降低用户使用产品的门槛，手机号不是必须的，用户只用微信登陆也是可以的；
用户现用手机号注册登录，然后使用微信注册登录，就会出现 1001 和 1003 两个用户，每个用户都关联了很多业务数据；
用户使用手机号登录，使用的是 1001 用户，然后期望绑定微信 wx00a 登录，此时系统发现 wx00a 已被使用。
用户 ID 手机号微信号 100113700000001100213700000002wx00b1003wx00a
手机号修改
用户会有修改手机号的诉求，系统涉及之初就需要支持用户修改手机号，以用户 ID 做关联键，其他系统不冗余手机号，不然容易造成数据不一致。
手机号不作为用户表结构的物理主键，作为业务主键，保证唯一
系统之间交互以用户 ID 进行，不冗余手机号
关联业务系统需要使用手机号，分为以下 3 种情况
需要展示手机号时，用户 ID 到用户中心查询手机号
单独通过手机号查询时，先用手机号到用户中心查询用户 ID，继而通过用户 ID 进行查询
列表查询通过搜索引擎，搜索引擎聚合业务表和用户中心的表
其他系统无法满足 2、3 条件时，修改手机号时需要同步修改自身数据
修改手机号的业务流程如下：
填写新手机号码，进行短信验证
检查新手机号是否已被占用
当前用户身份验证，防止盗号之类的安全问题
拥有旧手机号时，可通过短信验证码
旧手机号已丢失，通过其他方式辅助验证，例如 手势、指纹、邮箱等。
修改手机号
通知其他系统，做数据同步订正
手机号回收（二次放号）
A 持有手机号手机号 13700000001，在系统中注册成为用户(ID：u001)，该用户可能会将手机号 13700000001 注销，运营商在一段时间(例如 3 个月)后会将手机号 13700000001 重新放给 B 使用，B 用手机号 13700000001 登录后，发现系统中是 A 的信息，因为登录的是 u001 用户，会对 B 造成一定困扰，甚至可以使用 u001 的身份进行一些危险的操作，例如 资金账户方面的功能。
在系统设计时如何处理这个问题，有下面 2 个可选的方案
根据运营商信息判断是否为二次放号
如果能拿到运营商的信息，或者通过第三方的渠道拿到类似的信息也是可以的。
长期未登录后，重新登录时，可以调用第三方接口查询是否是回收的手机号，可以注销原账户信息，这样用户即可以通过新手机号注册全新的用户。
2. 拿不到运营商信息如何处理？
手机号是系统识别用户的主要方式，在系统感知不到手机号已被回收的情况下，可以将选择权交给用户。
手机号长期未登录后，再次登录时，根据不同的安全级别，采用不同方式
高风险：可以对用户进行身份验证，人脸、指纹、安全问题等，通过后可以认为没有换号
低风险：主动提示用户当前账户是否本人，用户确认后可以选择重新注册新用户
版权声明: 本文为 InfoQ 作者【孝鹏】的原创文章。
原文链接:【http://xie.infoq.cn/article/d5ba88ee734bb12b36a6fbd33】。文章转载请联系作者。
还未添加个人签名 2018.10.26 加入
还未添加个人简介
评论