系统设计之----抽象的质量

一、权限案例分析

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.正确的模型也可能受噪音干扰，而显得不准确；这时我们不应该用一种凑合的修正方法来弥补它，而是要找到噪音的根源，这也许能通往重大发现。