转载

途牛原创｜途牛无线权限系统的架构设计与实践

序

之前写过一篇大话权限中心的PHP架构之道，主要是从软件工程角度介绍，如何通过 编码规范、依赖管理、数据源架构、事务处理、单元测试 等技术，来保障权限系统的高可用，并未真正的涉及这套系统的架构。

今天准备从 设计细节 上分享一二。望各位看官，心有“空杯”，带着“问题”一探究竟。

RBAC3

这里还是尤为的重要，因为他是整套系统设计的根基。

所以残忍的从上一篇中复制了一遍。。。

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What(Which)进行How的操作”。

Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege，正向授权与负向授权）。
Operator：操作。表明对What的How操作。也就是Privilege+Resource
Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.

途牛原创｜途牛无线权限系统的架构设计与实践

权限系统的本质就是这个模型（个人观点勿喷）。我们在此核心思想上，抽象了两个新概念。

应用建模、权限自治

下面将从以下4个层面展开介绍。

应用建模
业务场景
权限管理
鉴权设计

应用建模

系统架构上支撑权限系统灵活配置，不僵硬字段，不僵硬行为，基于各种业务权限管控的特征灵活设计。

公式一枚： 应用＝资源＋行为＋角色

字段定义

简单点说，就是 要管控资源的属性和行为 。

比如要管控菜单，属性就包括 菜单ID、菜单名称、菜单URL、菜单ICON、上级菜单ID 等，行为就包括 访问、授权 等。（菜单权限）
比如要管控城市，属性就包括 区域ID、区域名称、区域代码、所属区域ID 等，行为就包括 访问、授权 等。（区域权限）
比如要管控CMS，字段就包含 页面ID、页面名称 等，行为就包括 访问、授权、编辑、重置 等。（CMS数据权限）

按照惯性的思维，这里就是 3张资源表对应角色表，同时还有3张资源角色关系表 ，换而言之，就是有多少资源需要管控就有多少张表（又是个人观点，勿喷）。

惯性的思维， 两个痛点 。

每一种资源都要独立存储。
每一种资源都要有一套Form排版&交互&存储实现。

为了解决这个问题，我们做了以下的设计。

字段建模

任意资源的字段，都可以抽象成如下几类。

资源映射字段（mapField）
资源节点字段（treeFiled）
资源系统字段（systemFields）
资源表单字段（columns）
资源行为字段（privileges）

举个栗子：菜单资源。

 class menu extends app {     public static $appMapField = 'url';     public static $appTreeField = 'name';     public static $columns = array(         array(             'id' => 'id',             'label'  => '菜单ID',             'type'  => 'input',             'format' => 'int',             'option' => array()         ),         array(             'id' => 'name',             'label'  => '菜单名称',             'type'  => 'input',             'format' => 'string',             'option' => array()         ),         array(             'id' => 'icon',             'label'  => '菜单ICON',             'type'  => 'input',             'format' => 'string',             'option' => array()         ),         array(             'id' => 'url',             'label'  => '菜单链接',             'type'  => 'input',             'format' => 'string',             'option' => array()         ),         array(             'id' => 'parent_id',             'label'  => '上级菜单ID',             'type'  => 'input',             'format' => 'int',             'option' => array()         ),     );     public static $privileges = array(         array(             'id'    => 'access',             'name'  => '访问'         ),         array(             'id'    => 'op',             'name'  => '授权'         )     );     public static $systemFields = array('id', 'parent_id'); }

动态表单

表单在网页中主要负责数据采集功能。一个表单有三个基本组成部分：

表单标签；
表单域，包含了文本框、密码框、隐藏域、多行文本框、复选框、单选框、下拉选择框和文件上传框等；
表单按钮。

常规工作是静态表单。

设计动态表单模型，基本的思路应该是 数据和表现显示的分离 。抛开表现层，一个表单包含的若干个字段和填写的数据。所谓动态，就是这些字段名称可能改变，数量可能有增减。

通过 资源的columns字段 控制表现层。
通过 资源的数据字段 控制数据层。

通过这种模式，任意资源的 Form排版&交互&存储 都动态实现了。

数据存储

资源表对应的Schema如下：

字段名称	字段备注
应用ID	/
资源ID	/
资源父ID	/
资源Data	JSON

通过 反射API ，获取当前应用的资源存储插件（资源Data字段）。

app::find($params['app_id'])->getResoucePlugin()->save($params['data']);

通过 资源基类 做数据存储的统一封装。

 public function save($attributes = array()) {     $this->beforeSave($attributes);     $json = array();     foreach (static::$columns as $column) {         if (in_array($column['id'], static::$systemFields)) continue;         if (isset($attributes[$column['id']])) {             $json[$column['id']] = $column['format'] == 'int'                 ? intval($attributes[$column['id']])                 : $attributes[$column['id']];         }     }     return $json; }  protected function beforeSave($attributes = array()) {     if (!isset($attributes[static::$appTreeField])         || !$attributes[static::$appTreeField]) {         throw new /Exception('资源数据保存失败，请录入资源名称', '900404');     } }

很显然 资源Data 字段，不能很好的完成 单资源行为鉴权 的任务。

设计上引入了资源 映射字段 ，每当资源变更时，触发 addMap ，会 同步字段信息 到资源映射关系表中（资源的语义化索引）。

举几个栗子，方便大家理解这个字段：

比如菜单类应用，映射字段就是菜单链接。
比如数据类应用，映射字段就是数据ID。

 public function addMap($mapFiledValue = null) {     if ($this->map) {         if ($this->map->f_value !== $mapFiledValue) {             $this->map->f_value = $mapFiledValue;             $this->map->save();         }     } else {         $this->create_map(             array(                 'f_app_id' => $this->f_app_id,                 'f_value'  => $mapFiledValue             )         );     } }

应用建模，相对来说是一个较技术的话题，换个方向，下面来和大家聊一聊系统的业务场景。