系統設計之----抽象的質量

一、權限案例分析

1.1、案例簡介

             最近在一個項目中，設計權限相關的。說到權限，很多會提到RBAC以及ACL模型。技術上JAVA領域也會想到SpringSecurity，以及更早的Acegi；還有不錯的Apache Shiro 等。拋開這些技術點，我們提煉到模型設計上來。RBAC以及ACL是什麼，請找谷哥或是度娘吧。 

常見業務系統中，權限需求：一般分爲菜單操作權限以及數據操作權限。簡化起見，我們稱爲菜單權限，以及數據權限。

             菜單權限：哪些對象（用戶）具有對哪些對象（菜單）的哪些操作（功能操作）。

             數據權限：哪些對象（用戶）具有對哪些對象（數據）的哪些操作（數據過濾）。

             除此之外，還會有權限分配，繼承，擴展等，更進一步有的還需要針對組織架構、崗位職稱等的授權要求。由於組織結構是非常容易發生變更，不同的公司或是業務組織的架構是不盡相同的。那我們要怎麼設計呢，既滿足現有需求，又要靈活設計，擴展性要求。

1.2、模型設計

             我們依賴什麼呢？

             抽象，抽象是管理複雜性的關鍵。一個好的抽象可以將一個不可能完成的任務分成兩個可管理的部分：第一個部分是有關抽象的定義與實現；第二部分是隨時使用它解決問題。人們所能夠解決的問題的複雜性直接取決於抽象的類型和質量。所謂的“類型”是指“所抽象的是什麼？所謂的“質量”是指所要解決問題引入的複雜度。即需要處理的本質複雜度的量減到最少，並不要讓偶然性的複雜度無謂地快速增長。

             具體到這個權限設計模型，以及需求。提到菜單權限，我們抽象除了角色這個概念。說到角色，大多人說，那不就是RBAC模型提到的概念麼，是的。可是爲什麼是這個概念呢，有認真思考過的同學，一定會想到軟件工程中的一個環節叫系統分析，其中一個最重要的篇幅說到用例圖。其中最首要的就是識別出系統具有哪些角色用戶。想一想，爲什麼不是組織或是部門崗位呢？角色這個抽象模型對於一個組織或是部門崗位是我們系統抽象出來的一個概念，是對部門或是崗位最終用戶的一個穩定抽象。它去除了部門崗位的多變，差別大等非權限本質屬性，只保留針對系統需要關注的對資源的統一劃分，資源分配以及資源繼承等等權限系統最核心的權限本質屬性。

             那我們的數據權限劃分是不是也需要統一到角色這個抽象的模型上呢？比如：品牌數據維度的權限，倉儲數據維度的權限，店鋪數據維度的等等，目前爲止已經具有八類，每一類數據的量有多有少。說到這裏，計算下這些數據維度的組合會有多少的量級。並且大多數擁有同一個菜單的用戶具有不同的數據維度的權限。

面對一個數十多個系統，數萬菜單，數十萬用戶級別，上百萬千萬計之的數據權限分配，管理上講，使用ACL模型將消耗太多太大的人力成本，不可取。RBAC也只是對菜單權限做了穩定的抽象。

             那這些數據維度的權限，怎麼來設計呢？

            人類認識規律，類，分類。不同的東西不同的分類。

             那引入用戶類型（注意區分用戶機構、組織部門等）或是叫用戶組，粗粒度上不同的類型或是組分配不同的數據權限維度（細粒度可以區分控制每個數據維度的，單對目前這個系統不需要，不需要就不引入導致系統設計複雜度上升的模型）。

             有人將權限設計分爲垂直型與水平型權限設計，RBAC歸於垂直型。而很多系統中，同一個角色的用戶可以加入不同的用戶組，這些一個個的用戶組，就是一個水平權限控制的系統。只是問題往往出在訪問控制系統的粒度上。如果劃分的粒度不夠細，那麼一個用戶組內的用戶是否可以刪除或修改各自的數據？

             對於粒度的劃分，我把一個訪問控制系統中的最小單位稱之爲一個原子權限。無論是水平權限系統還是垂直權限系統，可能都是對原子權限的不同組合。

看到用戶組的同學說，那RBAC裏面也曾提到有用戶組的概念啊，這個怎麼區分啊？

             我們可將其提高一個層次，對於一個業務系統來講（不涉及流程控制），無非就是這些菜單權限與數據權限的疊加。所以，可以在用戶角色與用戶類型之上組合一個用戶組的模型設計。即對用戶的權限分配，劃歸到某個組裏面，就擁有改組對應的角色菜單以及類型數據。

二、抽象的匹配

              就是說不管何種形式的抽象，都是基於下面的事實：場景與目標。系統設計，場景就是我們所要完成的系統功能集所受的約束與限制；目標設計出的系統要達到哪些核心要求。比如對功能擴展性，靈活性，等等。不同的系統具有不同的設計要求，也就會有不同的抽象模型。滿足現有是最低限度。

              其次是抽象的邊界。我們都知道殺雞不用牛刀的道理。系統設計抽象也是一樣。再解決原有問題複雜度之上，最低限度的減少來自我們引入抽象的複雜度。

              最後，抽象出來的模型形式上看總是簡單的，簡單到開發人員大都能容易理解並易於開發。

三、抽象的能力

怎麼抽？

             抽象能力本身是一種思維能力，也就是說你只有不斷的進行思維鍛鍊才能獲得。
            要想去打鐵，就得去打鐵。
            這是一句法國諺語，要想提高抽象能力，就得不斷的思考。

            良好的設計抽象，來自於對需求的理解以及所要達成目標的追求。

四、修復糟糕的抽象

            一般來說，在修復一個糟糕的抽象時，可以採取的策略分如下兩類：1、把造成問題的那部分抽象拿掉，直接露出底層的細節。2、換一個和底層兼容性更好的抽象模型。

五、討論

             數據集的列權限是否算權限系統的範疇？
            頁面需要展示一個數據集（dataset），那麼對某些列的展示、可讀、可寫的控制，是否要放在權限系統中解決？答案是，爲了簡化，爲了避免過度侵入業務邏輯，列權限不在權限系統範疇內。

六、附錄

1.一個正確的(數學)模型應當在形式上是簡單的。
2.一個正確的模型在它開始的時候可能還不如一個精雕細琢過的錯誤的模型來的準確，但是，如果我們認定大方向是對的，就應該堅持下去。
3.大量準確的數據對研發很重要。
4.正確的模型也可能受噪音干擾，而顯得不準確；這時我們不應該用一種湊合的修正方法來彌補它，而是要找到噪音的根源，這也許能通往重大發現。