最近遇到了一个多系统统一账号和权限的需求，折腾了一番，总结复盘一下和大家分享。
首先介绍下业务场景：
我们有多个对外的系统，称为：系统1、系统2、系统3、系统4。
这几个系统的账号和权限由于之前是多个团队独立开发的，所以账号和权限都是分开管理的。这是典型的烟囱式开发。
系统比较少的时候还没什么，当超过5个以上的时候就会发现非常麻烦。
上述结构的主要问题有以下三个：
1、对用户不友好。当客户A购买了多个系统，例如系统1和系统2时，他们需要到各个系统去分别创建用户并分配权限。这对于用户来说是非常不友好的，不仅要配置多次账号和权限，而且使用的用户需要记住多个账号密码；
2、浪费开发资源且维护困难。另外，对于我们来说，每新开发一个系统就需要做一套账号权限体系，既浪费开发资源又会导致维护困难；
3、不利于统一进行数据收集与分析。由于各个系统账号是独立存储的，不利于后续收集这些用户的使用数据，不便于对数据进行统计处理和分析。
综上，于是上层大佬提出了统一账号中台的概念，将账号和权限部分抽离出来做成中台服务，统一给各个系统提供账号和权限服务。
那么具体是怎么实现的呢？
先看一下整体的服务架构。
- 中台提供统一账号和统一权限服务，用户为公司内部运营人员
- 统一账号管理平台，调用中台的服务来创建账号并分配角色，用户为客户的系统管理员
- 接入系统，各个接入系统就不需要额外开发账号和权限管理界面，同时可以实现一个账号可以登录多个系统。
1、统一账号
首先来看统一账号服务模块。
创建账号，用户名称、手机号码和邮箱等基本信息是必不可少的。
那么，如何实现一个账号能登录多个系统呢？这个要分成两部分：
第一是将系统当做一个权限赋予账号；
第二是要在中台做一套统一的认证登录体系。
所以，我们在创建账号的时候，除了账号密码、手机邮箱等基本信息，就还需要给账号分配系统权限。
并且考虑到用户对每个系统的有效期可能都是不一样的，所以需要再勾选系统权限时，给每个系统配置有效期。
那系统的资源选项又是从哪来的呢？那就必须得有一个系统管理模块，专门管理后续要与中台进行对接的系统。
这样，用户一套账号密码就可以同时登录多个系统，只要用户有这个系统的权限。
统一账号这一块比较简单，复杂的是在统一权限管理部分。
2、统一权限管理
权限管理，一般包括两种：功能权限和数据权限。
功能权限一般都是用的RBAC模型。我们也是用的这个，通过将权限赋予角色，然后将角色与用户关联进行授权。
不过如果将角色权限统一放在中台进行管理的话，就会出现一些问题。
场景是这样的：一般我们开发系统的时候，如果系统新增了一个模块或者一个页面，对于这些新增的模块或页面的权限管理都是需要开发的时候顺带加上的。
那么问题来了：如果现在系统1-系统4的系统权限都统一放在中台管理，那当系统1和系统4的角色功能模块更新后，我们是不是也需要修改中台的角色权限模块呢？
这样做的话，不是不可以，但是不经济。中台要跟着接入系统的脚步走，有点浪费开发量。
有没有什么办法能解决呢？
一般权限的控制可以简单分为两种：
第一是纯前端控制，即前端隐藏掉入口即可，但是这样的话，安全性不高，因为其他人知道页面的url就还是可以访问；
第二种是从接口层面做限制，这种就是对系统访问资源进行控制。相对于前端控制，后台控制更安全，一般我们采用的也是第二种。
后台对功能权限的控制，其实就是对系统资源，对应模块、页面和按钮，包括：菜单、API和按钮等访问资源进行授权控制。
按照这个思路，我们其实可以在中台加一个资源配置模块，将各个系统的资源配置好，然后通过将这些资源赋予角色来进行授权。
当我们在【系统管理】模块创建好接入系统后，就可以在【资源管理】模块给这个系统配置菜单、页面、按钮和API资源了。
配置信息包括该资源的路径、资源的url和资源类型等信息。
如此，不管是新的接入系统，或者原有接入系统有任何模块、页面或按钮的增删改查等，中台只需要在资源模块进行配置即可，不需要重复开发。
最后，我们只需要在创建角色时，给角色勾选这些资源即可。
3、数据权限
说完功能权限，我们再来说一下数据权限。
首先，数据权限是怎么控制的？
功能权限是控制用户能不能进入某个模块、页面或者按钮，但是这个用户进入这个模块或页面能看到哪些数据，就是数据权限来控制的。
印象中，数据权限的常见做法是通过组织来实现的。上级组织可以看下级组织的数据，而下级组织只能看本组织的数据。
举个例子，之前做过的一个视频大数据平台，主要是面向政府部门采集摄像头视频数据的，当时我们就是采用的组织来做的数据权限分配。
但是前提是，摄像头也需要划分组织，也就是说当用户和摄像头属于一个组织时，或摄像头所属的组织从属于用户所属的组织时，用户才能看到该摄像头采集的数据。
后面接触到了一种新的方法（其实上面的例子也属于这个方法，只是之前没想更透彻）。
我们先来看一个问题：
假设我们系统的数据看板模块中，有这样一张三季度销售额表格，销售人员A和B负责这四个区域的不同客户。
要实现的效果是，A和B都是看这张图表，但是A看到是自己在这四个区域负责的客户销售数据，B看到也是自己在这四个区域负责的客户销售数据。
这样的情况下，通过组织是没办法进行区分的，因为A和B都是属于一个组织机构。通过区域也没办法划分，因为A和B在四个区域都有客户，是客户不同而已。
针对这个问题，我们用的是标签匹配的方式。
如图所示，客户销售数据表中有一个字段【客户名称】，我们在用户的身上同样创建一个【客户名称】的标签。
然后，根据销售A和B负责的客户的不同，赋予不同的标签值。
这样，当销售A查看销售报表时，我们就可以通过将【客户名称】的标签与销售表中的【客户名称】字段进行匹配。
将【华为、苹果、小米】的标签值与销售表【客户名称】字段的字段值【华为、苹果、小米】进行匹配，图表就只展示这些匹配上的数据，而不展示【兰蔻】这些没有匹配上的数据。
这样就实现了同一张报表，不同的用户可以查看不同的数据。
其实，上面的视频大数据的例子，本质上也是用的标签匹配的方法，用户身上的组织标签和摄像头上的组织标签进行匹配来进行数据权限控制的。
这种标签匹配的方式，我们称为：行级权限控制。
而相对的，其实还有列级权限控制。列级权限权限控制也是通过用户的标签和数据表字段进行匹配。
与行级权限不同的是，列级权限只需要匹配标签和数据表字段，不需要继续匹配标签值和数据字段值。
明白数据权限的控制机制，这些数据权限是怎么赋予用户的呢？
其实和功能权限类似，大致流程如下：
一种也是通过赋予角色，角色与用户关联；另一种是直接关联用户。两种都差不多，大家可以随意选择一种。
其中的数据资源模型指的是什么呢？其实就是配置数据表的行级或列级权限，然后将这些权限赋予用户后，用户就能看这些数据表的相应数据了。
像上面的原型设计，我们首先要在数据连接中选择一个数据库，比如我们存放销售数据的mysql库。然后在权限字段中选择行级权限或列级权限。
以行级权限为例，我们需要先在【选择表单】先选择一张数据表（例如销售表），然后选择销售表中的字段（例如客户名称），在【请输入内容】中输入【华为】。
这样，当我们把这一数据权限模型赋予用户A时，用户A就有了销售数据表中客户名称为华为这一行的数据，就可以看到华为的销售数据了。但是因为没有小米，所以就看不到小米的数据。
统一账号、功能和数据权限是非常基础的模块，很多系统都能用到。
通过这次复盘，总结出一些通用的方法论，希望能帮到大家。如果大家有什么更好的方法也欢迎大家在留言区留言~
