系统设计:基于角色的权限管理设计实现
背景
内部运营系统的很多 API,涉及到外网正式环境下的用户信息变更。出于安全考虑,在设计之初保留了所有的操作记录,但这用于事后回查;真正要避免线上事故的发生,还需要权限管理。
当前,系统的代码由 3 部分组成:前端、中台和后台。其中,前端负责交互逻辑,中台负责主要的业务逻辑,后台负责提供数据库的读写 api。所有的校验和业务逻辑,都是由中台拼接实现,所以权限管理的改造需要中台参与。
基于角色的权限设计
假设系统支持 4 种角色:
- 角色 A:超级管理员
- 角色 B:运营人员
- 角色 C:开发人员
- 角色 D:游客(普通用户)
每个 api 都按照其职能,划分到对应的 api 集合中:
- 集合 a:用户管理相关 api
- 集合 b:
- 日志相关 api
- 环境信息相关 api
- 集合 c:
- 资源调整 api
- 黑名单 api
每种角色可以调通单个/多个/全部的 api 集合:
- 角色 A:所有 api 集合
- 角色 B:
- 集合 b
- 集合 c
- 角色 C:所有 api 集合
- 角色 D:
- 集合 b
需要注意的是,每个用户只能是一种角色,而角色可以对应多个集合,每个集合可以对应多个 api。简而言之,角色是用户身份,它是唯一的。
例如,对于某些特定的用户(比如实习生),可以专门新建一个角色,再对此角色所需要的 api 集合进行排列组合。
中台与服务化
后台以服务化的方式提供了最基本的数据库读写 api,日后的改动成本低,运维成本低,并且可以给其他应用提供服务。
而主要的逻辑交给了中台进行拼接组合,中台不需要保存状态。同时,业务逻辑的改动将不涉及数据库和后台,中后台完全接耦,简化了发布和部署流程。
![](https://tva1.sinaimg.cn/large/006tNbRwly1gbjcfr3xb5j30cw00tjrd.jpg)
👇扫码关注「心谭博客」,查看「前端图谱」&「算法题解」,坚持分享,共同成长👇