文章結(jié)合具體業(yè)務(wù)場景對電商后臺設(shè)計中的系統(tǒng)權(quán)限設(shè)計的業(yè)務(wù)邏輯展開了梳理說明，并對相關(guān)問題展開了分析，希望通過此文能夠加深你對電商后臺設(shè)計的認識。

在說權(quán)限設(shè)計前我們先來看個現(xiàn)實中的實例，大家在電影里面應(yīng)該都見過這樣的場景，當一個客戶想進入銀行倉庫查看自己的私人保險柜信息時，通常都需要經(jīng)過幾個步驟：

首先進入銀行并說明自己是銀行的客戶以及來意由業(yè)務(wù)經(jīng)理帶領(lǐng)進入對應(yīng)的保險箱倉庫(倉庫應(yīng)該不止一個,猜得啊，我也沒有進去過^_^)業(yè)務(wù)經(jīng)理帶著客戶在眾多保險箱中找到屬于客戶的私人保險箱客戶輸入密碼自己打開保險箱查看內(nèi)部物品

在上面的實例中，客戶在看到保險箱的物品之前，他需要有這么幾個必要條件：

在銀行有開戶信息，能證明自己是銀行客戶有進入保險箱倉庫的權(quán)利在眾多的保險箱中找到屬于自己的那一個有打開保險箱的鑰匙

了解了上面的過程，對于我們理解一個系統(tǒng)的權(quán)限就會容易很多，我們再來梳理一下用戶在系統(tǒng)中看到數(shù)據(jù)的過程：

用戶需要進入系統(tǒng)，這需要后臺管理員給用戶分配賬號(后臺系統(tǒng)是沒有注冊功能的)用戶進入系統(tǒng)能看到哪些菜單導(dǎo)航，需要后臺給配置通過菜單進入到具體的頁面，在頁面內(nèi)能訪問多少數(shù)據(jù)量也是有訪問限制的看到數(shù)據(jù)了，能對數(shù)據(jù)做多少操作也是有操作限制的

在上面的過程中，除了第一步的分配賬號是由管理員操作的，剩下的三步都和用戶所擁有的權(quán)限相關(guān)。通過具體操作對象的不同，上面三步可以分為兩類：

功能：對功能的限制也稱功能權(quán)限，主要是對訪問區(qū)域以及對應(yīng)操作的管理，如上面的倉庫、頁面以及頁面操作按鈕。數(shù)據(jù)：對數(shù)據(jù)的限制也稱數(shù)據(jù)權(quán)限，主要是對數(shù)據(jù)資源的訪問控制，如保險箱和頁面顯示數(shù)據(jù)。

知道了需要對哪些對象進行管控限制，那么設(shè)計功能也就有了針對性，接下來我們一一分析。

01 功能權(quán)限

功能權(quán)限指的是用戶具體能訪問哪些菜單，以及對菜單頁面中的哪些按鈕有操作權(quán)限。把多個菜單和對應(yīng)的功能按鈕組織到一起就行程了一個權(quán)限列表，具體的組織方式如下圖：

對于用戶來說，它又是如何獲得這些權(quán)限列表的呢？通常有以下幾種方案：

方案一：ACL(Access control list), 權(quán)限訪問列表

通過直接將用戶和權(quán)限列表綁定在一起，實現(xiàn)的權(quán)限管理

優(yōu)點：可以為每個用戶個性化的設(shè)置訪問權(quán)限。缺點：當用戶數(shù)量多，并且擁有相同職能的用戶較多時，修改一次權(quán)限，就需要耗費很大力氣。如銷售部有很多的銷售專員，因為他們的職位相同，所有獲得的操作權(quán)限相同，但后期添加或者刪除一個訪問權(quán)限，那么需要給所有人相同職位的人都操作一遍，管理員估計得累死。所以這種設(shè)計方案在開發(fā)中使用的頻率很低。

方案二：RBAC(Role-Based Access Control)，基于角色的訪問控制

通過先創(chuàng)建一個角色，然后將權(quán)限列表在綁定在這個角色上，之后再將角色和綁定到用戶身上，用戶就可以獲得這個角色的所有權(quán)限。

優(yōu)點：首先多人可以公用一個角色；再者如果需要對權(quán)限進行調(diào)整，只需要調(diào)整對應(yīng)角色的權(quán)限即可，也就是只需要一次操作，非常易于操作和管理。缺點：上面優(yōu)點也是一個缺點，因為權(quán)限的操作是按角色來完成的，所以每次修改含有相同角色的用戶都會被影響。

如對于同一職位的職員，正常來說大家的權(quán)限都是一樣的，但是也會有特殊情況發(fā)生，比如給其中一個添加或減少部分權(quán)限，這個時候就沒有辦法了。對于這種情況，在現(xiàn)有的設(shè)計功能上也是有辦法解決的。

通常的方案就是在給角色綁定權(quán)限時，先采用權(quán)限最小化原則，能少給就少給，然后再做一個角色綁定多余的權(quán)限，再把這個角色也綁定給職員，這個時候兩個角色的權(quán)限就合并到一起了，也就是用戶和角色之間是一對多的關(guān)系。

對于RBAC還有幾個擴展模型：

第一種：在角色上加入了上下級關(guān)系，上級可以繼承下級的權(quán)限第二種：在角色之間加入了多個約束關(guān)系，如角色互斥、用戶基數(shù)限制等

實際開發(fā)中這些擴展模型，我們基本都不用，開發(fā)成本太多，實際意義和并不是很大，基本的模型已經(jīng)足夠完成我們的系統(tǒng)需要。如果想了解的同學(xué)，網(wǎng)上搜索一下RBAC，有很多教程我這里就不說了。

下面是基于RBAC的原型設(shè)計圖：

角色列表頁

角色授權(quán)頁

02 數(shù)據(jù)權(quán)限

對于數(shù)據(jù)權(quán)限的管理比較復(fù)雜，這個主要還是有具體的業(yè)務(wù)來決定的，下面我們就看幾種常見的數(shù)據(jù)場景以及解決方案。

場景一：分上下級的數(shù)據(jù)訪問

企業(yè)中通常都有銷售部，銷售部下又分各個大區(qū)，大區(qū)下又劃分小組。對于銷售人員來說，他們的薪資是和業(yè)績掛鉤的，所以沒有人會把自己的客戶資源讓你別人的，這就導(dǎo)致數(shù)據(jù)處理上，銷售專員通常只能看自己的(自愿共享的就不再這里討論)，而對于銷售主管則能看到手下所有的銷售專員的客戶資料，同理，大區(qū)經(jīng)理，和銷售總監(jiān)也都能看到自己手下所有人的客戶資源。

在這種場景下的數(shù)據(jù)，很明顯是能看出，這是根據(jù)企業(yè)的組織架構(gòu)，根據(jù)職員的職位高低來控制數(shù)據(jù)的訪問權(quán)限。所以它通常的解決方案是和組織架構(gòu)相關(guān)聯(lián)的，具體邏輯如下：

在給職員分配賬號的時候，設(shè)置好對應(yīng)的部門和職位當用戶獲取數(shù)據(jù)時，根據(jù)自己當前的部門和職位，獲取到所有下屬的職員信息將屬于這些下屬職員的所有客戶信息顯示出來，這個數(shù)據(jù)控制就完成了

場景二：分區(qū)塊的數(shù)據(jù)訪問

分區(qū)塊的典型案列就是電商企業(yè)員工對多個倉庫的訪問問題，我們假設(shè)有一個大的電商平臺，它在全國有多個倉庫，如北京倉、上海倉、西安倉、甘肅倉。對于各個倉庫的職員來說，通常他們只有當前倉庫的數(shù)據(jù)訪問權(quán)限，而對于總公司的買手、技術(shù)等人員來說，他們平時要巡檢查看各個倉庫數(shù)據(jù)，所以需要有全部倉庫的數(shù)據(jù)。而倉庫的組織架構(gòu)和買手、技術(shù)所屬部門并不存在上下級關(guān)系。

在這種場景下的數(shù)據(jù)，它就是按照分區(qū)塊的方式來劃分。要解決這個問題其實也很簡單，就是上面講的【用戶-角色-權(quán)限列表】，只是這里的權(quán)限列表內(nèi)容不再是菜單和操作按鈕，而是各個倉庫。

場景三：數(shù)據(jù)共享

數(shù)據(jù)共享的場景是很常見的，像我們經(jīng)常使用的協(xié)同文檔軟件，里面都會有將內(nèi)容共享給個人或者共享給某個組的功能。

這種場景下的的數(shù)據(jù)，我們需要通過單獨建表，維護共享者和被共享對象的關(guān)系，獲取數(shù)據(jù)時從對應(yīng)關(guān)系表中讀取對應(yīng)共享數(shù)據(jù)即可。

場景四：分狀態(tài)的數(shù)據(jù)訪問

分狀態(tài)的數(shù)據(jù)控制，這種場景比較少見，一般出現(xiàn)在流程比較長的業(yè)務(wù)中。如金融借貸系統(tǒng)中，比如一個用戶想要去借貸平臺上貸款，假設(shè)他們的流程如下圖：

通常要完成整個業(yè)務(wù)流程，需要多個部門相互配合的，由于整個業(yè)務(wù)涉及了許多客戶隱私信息，所以各個部門的職員一般只允許看到對應(yīng)步驟的數(shù)據(jù)，如審查組通常只能看到狀態(tài)為【待審核】的信息，風(fēng)控組只能看到【待評估】的信息，財務(wù)組只能看到【待放貸】的信息。

基于這種場景，有兩種解決方案：

首先在代碼里面配置好部門和職位對應(yīng)的訪問狀態(tài)碼(也就是寫死在代碼里)，當用戶訪問數(shù)據(jù)時，根據(jù)部門和職位獲得對應(yīng)狀態(tài)碼，再進行數(shù)據(jù)過濾。優(yōu)點就是開發(fā)比較快寫幾行邏輯判斷就行了，缺點就是如果想給部分人(如公司領(lǐng)導(dǎo))設(shè)置個性化的訪問狀態(tài)碼，就很難做到了。還是參考【用戶-角色-權(quán)限列表】的方式，將權(quán)限列表里的數(shù)據(jù)更換成業(yè)務(wù)狀態(tài)碼，訪問數(shù)據(jù)時，先根據(jù)用戶設(shè)置的角色獲取分配的狀態(tài)碼，再根據(jù)狀態(tài)碼獲取數(shù)據(jù)。優(yōu)點是代碼開發(fā)完后，任意的個性化都可以手動維護并快速配置。缺點就是開發(fā)量稍微大一點。

上面兩種方式其實內(nèi)部邏輯是一樣的，都是先根據(jù)用戶的部門和職位先獲取狀態(tài)碼再獲取數(shù)據(jù)，但是可操作性和擴展性缺完全不一樣。

以上就是權(quán)限功能涉及的內(nèi)容，如果你的業(yè)務(wù)還有更多花樣，請在下方留言。最后再給出一張用戶綁定權(quán)限原型圖，大家根據(jù)自己的業(yè)務(wù)適當調(diào)整：

小結(jié)系統(tǒng)權(quán)限模塊的設(shè)計時需要考慮兩點：功能權(quán)限和數(shù)據(jù)權(quán)限。功能權(quán)限和菜單以及菜單頁面內(nèi)的按鈕相關(guān)，而數(shù)據(jù)權(quán)限和業(yè)務(wù)相關(guān)。在處理一些有規(guī)則調(diào)整的功能時，最好設(shè)計可以手動維護的，這樣對于后期的維護和擴展會非常方便，否則運營經(jīng)常會找研發(fā)修改配置，這樣的工作即沒有技術(shù)含量，時間長了還挺讓人煩的，這點我在工作中深有體會。

作者：JackLiu；個人微信公眾號: 揚帆去遠航（ID:Jackai_liu)

本文由 @Jack 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。