【系统设计】基于角色的权限管理设计实现
背景
内部运营系统的很多 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，日后的改动成本低，运维成本低，并且可以给其他应用提供服务。
而主要的逻辑交给了中台进行拼接组合，中台不需要保存状态。同时，业务逻辑的改动将不涉及数据库和后台，中后台完全接耦，简化了发布和部署流程。
本文参与?腾讯云自媒体分享计划，分享自作者个人站点/博客。
原始发表：2020-05-03，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读