个人中台 - 前期 - 1

需求分析

要解决什么问题：

1. 每个项目都有登录、注册、权限模块，希望建立一个可复用的系统

复用形式：

1. 微服务
2. OAuth授权
3. 技术框架，前后端可复用的模块

难点：

1. 如果使用微服务的形式，相当于建立一个大而全的数据库，各项目数据字段不统一，并且后续会不断扩展，上新项目会涉及中台系统的改动
2. 如果使用OAuth的形式，内部的服务将等同于外部服务
3. 技术框架前端不好复用，后端在授权上Spring Security和Apache Shiro都是做权限控制的，不过他们是针对资源，类似过滤器

数据共用

个人中心的数据分两大部分：

1. 用户数据：登录、注册等需要的基础信息，以及用户登记的详细信息
2. 权限数据：用户的群组、角色、权限等信息

能共享的数据：

1. 基本的用户数据：用户名、密码、手机、邮箱
2. 基本的权限数据：用户的角色、群组

不能共享的数据：

1. 用户数据：除登录所需的数据
2. 权限数据：具体的权限列表

为什么不能共享：

1. 用户数据

2. 各项目的详细信息不同，有的系统需要身份证号等认证信息，有的系统完全不需要，如果全部集中到中台，一是很难包容所有项目的多样化字段，二是中台应该把公用的部分抽出来复用，而不是包容全部

3. 对于性别、姓名、年龄等可以部分共用的数据，可以建立单独的数据共享中心

4. 权限数据

5. 每个项目权限的粒度很容易不同，中台无法统一模型

6. 权限的表现形式和页面关联，比如按钮级别的权限不足，是不显示按钮还是点的时候提示权限不足，这个和具体的项目耦合，中台不好参与

流程概述

OAuth形式

权限认证参考OAuth，但是不使用OAuth的API规范；权限模型基于RBAC

用户登录和注册都通过前台服务的中转请求中台，注册或登录成功会获得有时效的token和guid，token保存在客户端用于鉴权

用户访问受限资源时，用token传到中台做校验，通过后前台服务获取用户的guid和角色，根据guid储存用户的其他信息，根据角色判断用户是否有权限

存在问题：

1. 每次访问受限资源，都需要判断token是否有效
2. 每次判断token是否有效，都需要多一次前台服务到中台的往返请求，消耗资源

优化：

1. 前台服务可以缓存token和角色等信息，token失效时再去中台取

解决的问题：

1. 用户基本信息共享（用户名、密码）
2. 基本信息共享后，实现SSO