关于统一认证鉴权服务的用户信息数据管理问题

Question

不想重复做注册登录，想要整合成一个微服务，于是我开始查找、思考、设计，但是走着走着就遇到一个关键问题：

用户数据应该放在哪里管？

之所以有这个疑惑是考虑了下面几个东西：

1.用户的类型（假设）：管理员，商户，普通用户...用户的种类存在变化，而且这是由应用业务决定的，多种多样的用户类型，该怎么去设计数据结构？

2.用户信息，比如手机号码，电子邮箱...这些可能在每个应用都会存在，但是很可能不同的应用业务所需求构成的用户信息是存在一些异同的，一下子也很难想到该怎么去设计数据结构？

3.特别的业务需要联接相关用户表查询，这个查询是否存在难度或者副作用？

4.如果多个应用的用户数据量很大，并且以后还会有应用增加，这么大的数据量统一管理是否会造成一些难度和问题？

我不是要问怎么去统一认证做鉴权，我想更加深入的了解，具体到服务的架构设计，特别是数据结构设计的时候是怎么做的？
比如：阿里的服务（淘宝、天猫、支付宝...）他们的用户数据结构是怎么设计的？

就结果而言，应该只有2种导向吧：用户信息管理要么放在统一认证鉴权服务这边管理；要么分散到每个应用系统各自管理。

Answer 1

1. 统一认证鉴权服务为什么要管用户类型是什么，这是调用方需要考虑的事情
2. 用户信息只存关键的、用于唯一区分的信息，比如阿里淘宝用身份证、手机号，登录帐号和密码属于账户属性
3. 调用方只需要知道现在这个人到底存不存在即可，确定存在了再通过中心下发的 uid 去自己的业务表里查询
4. 先遇到瓶颈再说，能靠机器硬件堆的就用硬件堆

举个栗子：

1. 用户在任意业务方注册，业务方向中心询问（手机号、身份证号，下面通常 身份ID）是否已经有注册过账户

   1 注册过，告知用户换个 身份ID 或者直接用 身份ID 绑定的帐号进行登录或继续用该 身份ID 注册（这个取决于业务）

   2 未注册过，走一下注册流程，中心登记 身份ID 与绑定的帐号属性（帐号名称、密码等）然后下发一个中心用户id（下称 cuid）

2. 在业务方登记业务所需信息字段，将 cuid 与这些信息字段关联绑定成业务方自己的一个用户 (下称 buser)，然后提交部分如姓名、性别等公共字段至中心，这样下次用同个 身份ID 注册别的业务账户时就可以直接下发部分信息（这有点隐私滥用的味道，因此需要业务允许加上技术上做个身份核查，即给手机号发个验证码/给绑定的银行卡转个1分钱来确认的确是同个自然人在注册）
3. 用户在任意业务方登录，业务方向中心询问，这个帐号名称和密码是否存在于匹配，中心验证通过后推送 cuid，业务方拿到 cuid 就看看自己有没有哪个 buser 与其关联，没有就告知用户进行注册，有就登录然后就开始用 buser 进行业务流程。