更改角色权限 在线生效_权限模型剖析优化实例（下）

回顾一下之前权限模型的总结：1、该IT系统的两套权限管理模式：用户——群组（项目X业务角色）——系统角色；用户——（系统角色X数据范围）2、现有模型问题：IT框架问题：多套业务角色模板很鸡肋且不可靠；运维问题：系统角色混乱不清。3、现有管理问题：从权限点到用户，中间经历了权限点到系统角色（关联1），系统角色到群组（关联2），群组到用户（关联3）三层关联。关联1由开发人员完成，关联2由运维人员维护N套模板，关联3由业务人员配置使用。层级复杂，三方人员各自为政。4、IT优化：统一业务角色模板，项目属性维度的权限控制，以数据权限的思路控制；支持一线用户对业务角色的定制需求。
接下来，这里给出两个不同方向的优化高阶方案。

---

方案一策略方针：权限可视化、结构化——引入权限树和业务功能树。
权限树根据IT架构来自动生成，以子产品、数据模块来划分；业务功能树依据系统的页面及功能，由运维人员手动构建出一套网站地图。权限点挂载在权限树下，一个权限点对应了一个后台接口服务的管控；系统角色挂载在业务功能树上，系统角色对应一个页面内某独立的最小功能操作。即：将之前混乱的权限点和系统角色以树形结构重组织。变动方案：
页面开发人员到权限中心申明接入平台系统的权限点：
将完成一个完整操作/功能所需的所有权限点包装为权限集：权限点限制接口使用，如果一个操作功能需使用多个带权限的接口，则归到一个权限集中。权限点的定位为接口的调用权限；权限集的定位为某个最小业务功能的使用权限。
系统管理人员到权限中心管理标准角色和配置标准角色的权限：
为了便于权限管理，将权限结构化、可视化。针对每一个权限集，映射到业务功能树上。通过这棵树，将业务视图和IT权限映射绑定在了一起。
业务管理人员到权限中心设置用户标准角色并配置其定制权限：
有了业务功能树，IT层面的权限管控就像黑箱对业务人员隐藏了。业务人员对某个角色定制权限，直接勾选想要的页面及功能的操作权限，便能自动将关联的IT权限集授予到角色。代价和收益：
IT上的变动只是对局部对象进行改造，将权限点和权限集以树形结构进行存储及展示。并没有对模型伤筋动骨，对历史数据也能做到很好的兼容，迁移适配的过程也是对混乱数据的梳理。
业务层面上，管理模式并没有发生改变，其实质在于：将权限的业务属性通过树状配置固化。那么在关联2和关联3的环节，给用户的感知更加友好。但其并没有改变权限点和权限集太多，管理对象太多的问题。权限模型还是太过厚重。

---

方案二策略方针：权限管理减负——功能权限、数据权限分离。
将业务角色权限模板统一为一套标准的功能权限映射表。将项目的场景、产品等属性抽离出来作为数据范围。去掉群组及系统角色这个管理维度，为用户授权则直接关联角色和数据范围。业务角色管控功能权限、数据范围管控数据权限。权限模型改为如下：

变动方案：
1、废除业务角色模板——权限点大幅减少。
此前一套业务角色模板只用到了一部分的权限点。经过梳理后，系统内的权限点可以极大缩减。减少的是针对不同场景、区域、产品定制的权限点。
2、废除群组——减少关联层级。
此前“用户——群组（项目X业务角色）——系统角色——权限点”的模型有三层关联，现在“用户——（角色X数据范围）——（功能权限点/数据维度）”只有两层关联。易管控。
3、角色权限变更的优化。
方案一中，如果对角色的权限进行了修改，要使其对所有用户生效，是很麻烦的。因为用户关联的群组是对业务角色的实例化，需要对系统内千万条数据进行刷新。此方案中，角色和权限点只有一份源数据，修改可以即时生效。
4、用户权限DIY的支持。
该方案对用户权限的支持也更友好。当用户关联了某项目下某角色，则生成了一条权限记录。如需对其进行权限DIY，则变为“用户——（角色X数据范围 + 权限变更）”。这里是以用户为“主键”，记录权限变更是易扩展好实现的。而在方案一中，因为“用户——群组（项目X业务角色）”关联里，是以群组为"主键”，用户层面的权限变更，则需要额外一张表记录。那么在健全时多表操作，性能更差且不易拓展。代价和收益：
IT模型上有着大刀阔斧的改变，砍掉了“群组”、“角色权限模板”并启用了“数据范围”。IT变动太大，所有权限点产生及鉴权部分的代码都要针对性修改，且可能存在不可预知的风险：数据维度的划分是否合理，能否经得住业务需求的考验；大量历史数据需要重新组织，难以做到平滑过渡。这就是对IT系统的一次换血！
但同时，其收益也是显著且影响深远的。该方案可以直接解决此前权限模型的数据混乱和管理混乱问题。

1. 没有了多套业务角色模板，只有一份标准的角色权限，清晰可控；
2. 没有了“权限集”中间商的角色，直接绑定权限点和角色；
3. 管理上也相应简单了很多，运维人员及业务人员为角色配置权限简单直接。

---

总结
进行IT方案设计时，“高速换轮胎”比“平地起高楼”要考虑的东西更多。一个方案，以修补的方式，在短期内以较高的性价比先治标；另一个方案，以大换血的方式，需要大量的投入以达到长治久安。至于怎么抉择，还得看这个痛点有多痛。
系统设计在使用之初设想得可能十分美好，并尽可能多地提供了使用的灵活度。然而在使用演化的过程中，会逐渐出现与业务述求不匹配的现象。
我想，这也是近年来devops敏捷开发模型兴起的缘由吧

---

公众号内观看，效果更佳哟：HappyYoung_wx