權限模型設計——資源-組-标簽模型/Resources-Group-Tag（RGT）
1、前言
RBAC模型可以說是權限模型的事實标準了，也有大量基于其的變種或增強設計，如RBAC0、RBAC1、RBAC2、RBAC3等等，但其設計或實作都太過繁瑣和複雜了，這裡借用一位博友做的RBAC3模型作比較（各有所長，無比較高低之意，僅借為基礎作展開講解），表設計圖如下：
圖1
僅僅一個權限就有15個表之多，而且大多數表互相之間都有多對多關聯，複雜度之高~~~就這，還沒有實作最全的權限系統，如SaaS所需要的資料分離、資料合并等資料權限功能基于這個設計就很難實作（其設計中僅有基于組織的資料隔離，并且組織和權限在同一個次元）；另外由于其設計是針對一個具體的系統進行的，太具象了，不夠通用，較難移植。
RGT模型：先上一張最終的表設計圖，核心的思想就是把對象進行統一抽象（多個類似對象抽象為一個）、簡化（用一個表來表達一對多關系），應用到具體應用中時隻需要拓展資源表的字段即可。
圖2
與圖1相比，把使用者、權限統一抽象為資源，并使用URI管理上下級關系（類似檔案系統的機制，優勢：可使用索引）；把組織、身份、使用者組、角色統一抽象為組，組本身是樹結構，資源群組之間是多對多關系，這就完成了圖1所支援的功能。另外新添加了另一個次元——标簽，用于從另一個次元做資料權限功能。
2、權限模型對比
RGT核心思想也是源自于RBAC模型，但對RBAC模型有進一步抽象。
RBAC基礎模型：
RGT基礎模型：
把RBAC中的使用者和權限統一抽象成了資源、把角色抽象成了組，在這個基礎上增加了标簽，用于實作資料隔離、資料合并等資料權限功能。
RBAC常用結構：
其中使用者為線性表，權限可級聯，角色可拓展為樹，如下：
對于其它層次的拓展也是基于使用者-角色，如圖1的組織架構、使用者組等。
RGT常用結構：
其中資源、組、Tag本身都可以是樹結構。
這裡Tag隻是一個次元的統一叫法，可以用來表示任何概念，如國家、公司、域、網段、租戶等等。
3、複雜度對比
時間複雜度：
由于RBAC可能存在多級多對多級聯，而RGT最多隻存在一次多對多級聯，故在時間複雜度上RGT更優。基于緩存的情況下這個優勢會非常明顯。
邏輯複雜度：
由于RGT比較抽象，在了解和實際操作中需要對整個設計都非常明确；而RBAC每個表的意義都很确定，操作簡單；故邏輯複雜度RBAC更優。
開發複雜度：
RBAC有大量的表和表關系，開發複雜度很高，特别是多級緩存會很難設計；RGT一般就3張表，最多4張表，開發和拓展都比較簡單。
PS：空間複雜度相差不大，不作比較。
4、實施的具體步驟
經過前面的對比，自行選擇适合的方案，後續章節僅針對RGT展開。
4.1、定義資源、組、Tag
确認模型後的第一步需要根據實際項目情況定義資源、組、Tag分别代表什麼。以圖1為案例（後續也使用該業務為案例），在其基礎上拓展一層公司，公司與公司間的權限完全隔離，公司内部的權限采用層級管理；那麼資源代表使用者和權限，組代表組織、身份、使用者組、角色，Tag代表公司。
4.2、套入模型
模型隻是定義了權限相關的設計，并沒有包含業務，需要把模型套入實際的項目中并且根據實際業務情況拓展使用者、公司等基礎資訊的字段，并且在需要做資料權限的相關業務表上添加Tag字段（複雜資料權限可以使用多對多）。
4.3、基礎資料初始化
要讓權限系統正常工作，需要預先把基礎的使用者、權限、組織、身份、使用者組、角色、公司等資訊添加到系統中。
4.4、鑒權
當某個使用者請求某個資源時，首先判定該使用者是否具有通路該資源的功能權限（查詢資源-組映射表），然後判定該使用者是否具有通路該資源的資料權限（查詢Tag）。
4.5、優化
至此，核心業務功能已經完成了，對性能沒要求的業務就結束了。
由于鑒權是無處不在的，如果每一個動作都按如上操作進行鑒權，那性能是無法忍受的（一次鑒權至少需要3次查詢，平均開銷50ms+），那就開始優化吧。第一步：直接緩存4個表的資料，平均開銷能壓到5ms左右。第二步：重構4個表的資料，采用K-V結構緩存，平均開銷能壓到2ms左右。第三步：集中緩存+本地緩存，平均開銷能壓到0.1ms左右。
注：實際步驟之間沒有順序關系，為了表達性能提升的遞進關系才按順序寫，緩存是以空間換時間，請根據實際需要進行選擇。