背景
內部運營系統的很多 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，日後的改動成本低，運維成本低，並且可以給其他應用提供服務。
而主要的邏輯交給了中臺進行拼接組合，中臺不需要保存狀態。同時，業務邏輯的改動將不涉及數據庫和後臺，中後臺完全接耦，簡化了發佈和部署流程。
👇掃碼關注「心譚博客」，查看「前端圖譜」&「算法題解」，堅持分享，共同成長👇
