本文首先引入多利熊業務介紹，引出多利熊業務建設權限系統的痛點，接著分別從權限系統模型、權限系統設計以及多利熊業務業務應用方面詳細探討了具體的方案和設計，最后對權限系統設計思考，對數據維度建設拋磚引玉，讓大家一起思考解決方案。

GEEK TALK

01

業務介紹

多利熊，是百度旗下的本地生活服務平臺。多利熊旨在為用戶提供特低價優惠的品質服務，基于百度的AI和雙引擎能力，以改變市場格局之勢迅速推進，為本地商家提供豐富的營銷渠道，決心成為本地生活市場的重塑性力量。

多利熊覆蓋餐飲、酒店、景區、休閑娛樂、麗人等眾多品類。用戶可以花更少的錢享受多利熊甄選的本地生活品質服務。成為多利熊分銷達人，自購更省錢，分享直賣可賺取傭金，鎖粉政策可讓達人長期賺取用戶自行下單傭金，發展下游達人組建團隊更可賺取團隊傭金。

多利熊架構是如何支撐起整個業務生態運轉，如下圖所示：

如圖所示，多利熊整個業務架構分位三層。包括：生態場景層、平臺支撐層、基礎建設層。

• 多利熊生態場景：多利熊除了在百度的雙引擎、百家號、私域中進行分發外，還擴展到了微信生態圈，建設了多利熊微信小程序，用于在微信生態的分發，通過微信群、微信分享、微信達人引流。除了自建外，也通過合作方式引入第三方服務商、自研商家、本地生活服務平臺，從而打造多元化、多類型的本地生活服務生態圈。

• 多利熊平臺支撐：多利熊建設了大量平臺，包括：商戶平臺、運營平臺、審核平臺、小編平臺、分發平臺、干預平臺、質量平臺等等。通過豐富的平臺，降低運營成本、提升商家接入效率，從而更好的支撐業務的高速發展，快速迭代。

• 多利熊基礎建設：多利熊的基礎建設層，通過集成小程序及百度中臺的眾多沉淀系統，迅速支撐業務快速迭代。包括：小程序自研的服務化治理方案：天路、天眼、BRCC；小程序沉淀的數據多維度分析報表和穩定性建設監控和治理手段；以及百度豐富的中臺系統：交易中臺、營銷中臺、互動中臺、審核中臺等等。

從圖中可以看到，整個多利熊業務架構中，平臺角色眾多，權限系統面臨非常多的挑戰。

• 平臺眾多，各個平臺的賬號系統也會存在差異性。權限系統如何支持各平臺的隔離設置，保證平臺數據的合規性和安全性？

• 多個平臺中存在眾多業務角色、角色存在上下級關系，大家需要協同工作。權限系統如何支持高效的配置，保障多角色協同、高效、便利操作？

• 多個平臺基于不同語言開發。權限系統如何保證接入的便捷性？

具體我們是如何建設，解決這些問題的呢？下面將詳細介紹下。

GEEK TALK

02

權限系統介紹

2.1權限系統模型

RBAC(role-based access control)：基于角色的權限訪問控制。

RBAC是一種圍繞角色和權限定義的訪問控制機制，在RBAC中，權限與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是為了完成各種工作而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合并而賦予新的權限，而權限也可根據需要而從某角色中回收。角色與角色的關系可以建立起來以囊括更廣泛的客觀情況。

RBAC四個核心組成部分：

1. S（Subject）：主體，一名使用者或自動代理人

2. R（Role）：角色信息，被定義為一個授權等級的工作職位或職稱

3. SE（Session）：會話級別的身份權限表達，S，R或P之間的映射關系

4. P（Permissions）：權限，一種存取資源的方式

RBAC 定義了三個主要規則：

1. 角色分配：只有當主體選擇或分配了角色時，主體才能行使權限

2. 角色授權：主體的活動角色必須為主體授權。使用上面的規則 1，此規則確保用戶只能承擔他們被授權的角色

3. 權限授權：只有為主體的活動角色授權了權限，主體才能行使權限。對于規則 1 和 2，此規則確保用戶只能行使他們被授權的權限

RBAC的四個模型：

1. Flat RBAC：基本的 RBAC 模型，基本的概念是 用戶被分配給角色，權限也被分配給角色，用戶通過角色獲取對應的權限

2. Hierarchical RBAC：角色被組織成分層結構，其中“較高”層級的角色從的“較低”層級的角色繼承所有權限

3. Constrained RBAC：向角色添加職責分離 (SOD) 的實施

4. Symmetric RBAC：添加了權限角色審查的要求，類似于 Flat RBAC 中描述的用戶角色審查

四種模型的等級和功能描述：

Flat RBAC模型結構：

Hierarchical RBAC模型結構：

Constrained RBAC模型結構：

靜態職責分離：

1. 互斥角色：同一個用戶在兩個互斥角色中只能選擇一個

2. 基數約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的

3. 先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色

動態職責分離：

1. 會話和角色之間的約束，可以動態的約束用戶擁有的角色，如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。

Symmetric RBAC模型結構：

2.2權限系統設計

RBAC模型如何在我們的實際場景中選型和改造是一件深入思考的事情。首先我們要基于我們的業務場景圈定權限系統核心功能。

我們做的是本地服務tob業務，所以對于商家我們會有商家平臺，除了商家的管理平臺之外，我們還需要對于o端建設平臺進行管理，以及我們開發同學的干預平臺等，這些平臺都需要權限管控。每個系統都有各自的頁面，每個頁面都有自己的功能實現，大到頁面權限的管控，小到按鈕的管控，在未來的業務發展中都是我們權限系統所需要考慮的。所以我們的權限管理相對來說任務也是比較繁重的。

針對我們以上的業務場景和需求形態，我們首先敲定了權限系統的核心職責：

1. 頁面菜單權限的管控

2. 功能組權限管控

3. 按鈕功能權限管控

4. 支持多業務線

我們基于Flat RBAC設計了如下的RBAC模型：

基于我們設計的RBAC模型，繼續細節的考量

1. 支持多業務線接入和業務線業務隔離

2. 需要支持菜單權限、功能組權限、按鈕權限的管控

首先考量業務線支持問題，對于這個事情我們使用了單獨的表來表達產品線信息，在設計user，role 和 func 表，都需要與業務線信息表關聯。

于是我們思考如何支持頁面菜單權限、功能組權限和按鈕權限的問題。

菜單權限、功能組權限和按鈕權限都隸屬于功能權限，于是我們使用一張表進行功能權限的表達，和前端頁面的樹形結構表達相映射，構造一個功能權限樹，于是我們最終落地的ER圖如下：

業務線

對于不同的系統，各自的用戶體系、角色管理、權限管理都是有差異的，需要滿足不同的系統的訴求，首先要做的是對各個系統的隔離。

我們設計了業務線信息的表，核心字段如下：

該表主要描述業務線的基礎信息內容，用于更好的管理和配置。

業務線隔離的實質是用戶表、角色表和權限表都需要指定業務線的prod_id，這樣在BRAC模型的三個核心角色里都做到了業務線隔離，每個系統在使用自己的數據的時候都需要指定自己的prod_id。

用戶

從業務角度分析來看，商家平臺是對外面向商家登錄的用戶賬號體系，對于o端來說，是面向我們運營同學，bd同學使用的場景，使用的內部賬號體系，所以，我們這里就有這不同的用戶登錄體系。

我們面臨著多種用戶體系形態，所以，我們就兼容不同的用戶體系設計，由此我們設計的用戶表核心字段如下：

prod_id、user_type 和 login_id 組成聯合唯一建。

角色

FLAT BRAC模型的角色并沒有涉及角色的繼承關系，我們現在的業務沒有涉及到這么復雜的角色關系，所以我們用最簡單的方式來表達角色信息，從而減少對于角色身份的管理和維護。

角色的核心字段如下：

prod_id 和 en_name組成聯合唯一建。

權限

權限這塊是我們思考最多的地方，我們希望可以通過統一的標準將前端頁面的功能權限進行約定。

我們去了解前端使用的設計，無論是b端還是o端前端，都是我們自己的前端團隊，他們講使用統一的前端框架和風格進行設計，這樣對于我們得權限系統來說就是最好的情況，我們首先需要面對的就是這樣風格的權限管控。

首先看下我們b端的前端頁面樣式如下：

這里左側為頁面菜單欄，右側為菜單欄對應的頁面，里面就是涉及到的各個功能模塊。

我們這里要處理的就是:

1. 菜單欄的權限管控：菜單是否展示，菜單層級結構以及菜單設計的頁面權限內容

2. 頁面權限：頁面里涉及到的功能權限

3. 功能組：頁面中某些功能模塊的功能權限

4. 按鈕：按鈕的權限

于是我們準備改造權限表為樹狀結構如圖所示：

基于這樣的樹狀結構，我們就可以描述出前端的整個權限管控內容，權限的核心字段如下：

整體的核心設計就是這樣，結合我們的微服務框架理念，我們整體的業務交互圖如下：

現在我們權限系統已經在支持著多利熊B端平臺和O端平臺的權限管控，并正在支持小編平臺，后續我們將繼續服務更多平臺的權限管控。

2.3多利熊業務應用

基于上述權限系統的設計，使得多利熊業務在面對龐大的人員組織架構、復雜的業務系統時，也能夠高效、靈活地實現權限的管理。

如下圖的商務運營系統應用場景所示，該系統是面向內部多個團隊開放的，每個團隊都具有不同的職能，甚至團隊內部也劃分了不同的崗位。

針對該應用場景，系統權限的分配與管理主要包括以下的步驟：

1. 明確系統角色：如上圖3.1所示，商務運營系統包括商家、商鋪、訂單等在內的多個平臺。針對每個平臺，需要確定好平臺內需要哪些角色，不同角色在平臺內承擔著不同的任務。例如商戶入駐系統包括了幫助商戶入駐的角色、幫助商戶管理成員的角色等。

2. 明確角色權限：針對角色承擔的具體任務，其對應的系統可操作權限也是不同的，這就需要每一個角色分配具體的操作權限。例如幫助商戶入駐的角色，可以有錄入、查詢、修改商家信息等接口與按鈕的權限。

3. 明確團隊架構：如上圖3.2所示，審核管理項目需要有商務、運營、客服等多個團隊，不同團隊下還有相應的崗位來承擔不同的任務。例如商務團隊包括商務小編、商務管理員、商務負責人等崗位。

4. 為團隊成員分配系統角色：為了將系統內的角色權限與團隊內的組織架構進行結合，如上圖3.3所示，管理人員可以通過角色配置的方式，來為崗位的人員賦予對應平臺的權限。例如商務小編只有商品管理的角色，而商務可以同時有商品管理角色、商家入駐角色等，這樣就實現了基于角色進行權限管理的實際應用。

GEEK TALK

03

權限系統思考

有了功能權限，我們進而應該思考另外一塊領域，就是數據權限。

數據權限，就是有或者沒有對某些數據的訪問權限，具體表現形式就是當某用戶有操作權限的時候，但不代表其對所有的數據都有查看或者管理權限。數據權限有兩種表現形式：一種是行權限，另外一種是列權限。

所謂行權限，就是限制用戶對某些行的訪問權限，比如：只能對本人、本部門、本組織的數據進行訪問；也可以是根據數據的范圍進行限制，比如：合同額大小來限制用戶對數據的訪問。所謂列權限，就是限制用戶對某些列的訪問權限，比如：某些內容的摘要可以被查閱，但是詳細內容就只有VIP用戶才能查看。

通過數據權限，可以從物理層級限制用戶對數據的行或列進行獲取，這種方式比把所有數據拿到之后再根據用戶權限來限制某些行或列有諸多好處。以列表數據權限為例，主要通過數據權限控制行數據，讓不同的人有不同的查看數據規則；要實現數據權限，最重要的是需要抽象出數據規則。

但是光有數據規則是不夠的，我們還需要把數據規則跟資源和用戶進行綁定。這樣資源就可以關聯上了數據規則。

在設計上我們需要一個單獨的數據規則管理功能，方便我們錄入數據規則，然后在資源管理頁面上就可以選擇內置的數據規則進行資源與規則的綁定。

那么如何讓不同的用戶擁有不同的數據規則呢？

在RBAC模型中，用戶是通過授予不同的角色來進行資源的管理，同理我們可以讓角色在授予權限的時候關聯上數據規則，這樣最終在系統上就體現為不同的用戶擁有不同的數據規則。

基于此，我們可以基本實現RBAC與數據規則的綁定；同時數據權限是一個實現相對比較復雜的功能，除了在RBAC模型基礎上進行擴展，是否還有其他更合理的思路，留給大家進行思考。