【系统设计】基于角色的权限管理设计实现

背景

内部运营系统的很多 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，日后的改动成本低，运维成本低，并且可以给其他应用提供服务。

而主要的逻辑交给了中台进行拼接组合，中台不需要保存状态。同时，业务逻辑的改动将不涉及数据库和后台，中后台完全接耦，简化了发布和部署流程。