第六章：我的权限控制方法论——分布式权限控制
发布于
文章大纲
一、分布式角色权限体系
1、前后端分离的分布式权限控制
2、前端的多端分布式权限控制
3、后端的多模块分布式权限控制
二、分布式凭证权限体系
无论在哪个SAAS或是管理系统中，权限控制的设计都是一个复杂的事情。
我们先看一下Wordpress的权限设计。
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
|---|---|---|---|---|---|---|
| create_sites | Y | |||||
| delete_sites | Y | |||||
| manage_network | Y | |||||
| manage_sites | Y | |||||
| manage_network_users | Y | |||||
| manage_network_plugins | Y | |||||
| manage_network_themes | Y | |||||
| manage_network_options | Y | |||||
| upload_plugins | Y | |||||
| upload_themes | Y | |||||
| upgrade_network | Y | |||||
| setup_network | Y | |||||
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| activate_plugins | Y | Y (single site or enabled by network setting) | ||||
| create_users | Y | Y (single site) | ||||
| delete_plugins | Y | Y (single site) | ||||
| delete_themes | Y | Y (single site) | ||||
| delete_users | Y | Y (single site) | ||||
| edit_files | Y | Y (single site) | ||||
| edit_plugins | Y | Y (single site) | ||||
| edit_theme_options | Y | Y | ||||
| edit_themes | Y | Y (single site) | ||||
| edit_users | Y | Y (single site) | ||||
| export | Y | Y | ||||
| import | Y | Y | ||||
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| install_plugins | Y | Y (single site) | ||||
| install_themes | Y | Y (single site) | ||||
| list_users | Y | Y | ||||
| manage_options | Y | Y | ||||
| promote_users | Y | Y | ||||
| remove_users | Y | Y | ||||
| switch_themes | Y | Y | ||||
| update_core | Y | Y (single site) | ||||
| update_plugins | Y | Y (single site) | ||||
| update_themes | Y | Y (single site) | ||||
| edit_dashboard | Y | Y | ||||
| customize | Y | Y | ||||
| delete_site | Y | Y | ||||
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| moderate_comments | Y | Y | Y | |||
| manage_categories | Y | Y | Y | |||
| manage_links | Y | Y | Y | |||
| edit_others_posts | Y | Y | Y | |||
| edit_pages | Y | Y | Y | |||
| edit_others_pages | Y | Y | Y | |||
| edit_published_pages | Y | Y | Y | |||
| publish_pages | Y | Y | Y | |||
| delete_pages | Y | Y | Y | |||
| delete_others_pages | Y | Y | Y | |||
| delete_published_pages | Y | Y | Y | |||
| delete_others_posts | Y | Y | Y | |||
| delete_private_posts | Y | Y | Y | |||
| edit_private_posts | Y | Y | Y | |||
| read_private_posts | Y | Y | Y | |||
| delete_private_pages | Y | Y | Y | |||
| edit_private_pages | Y | Y | Y | |||
| read_private_pages | Y | Y | Y | |||
| unfiltered_html | Y | Y (single site) | Y (single site) | |||
| unfiltered_html | Y | Y | Y | |||
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| edit_published_posts | Y | Y | Y | Y | ||
| upload_files | Y | Y | Y | Y | ||
| publish_posts | Y | Y | Y | Y | ||
| delete_published_posts | Y | Y | Y | Y | ||
| edit_posts | Y | Y | Y | Y | Y | |
| delete_posts | Y | Y | Y | Y | Y | |
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| read | Y | Y | Y | Y | Y | Y |
基于用户角色和用户等级，实现分层次的角色权限控制体系。
Wordpress权限控制系统是一个非常经典的权限控制系统，但是，因为Wordpress在用户和权限方面做得非常“轻量化”，所以，Wordpress的权限控制系统可以说只是一个完整的“骨架”，然而，仅仅是一个骨架也足以让很多人头昏脑胀。
所以，你可以想象一下，在那些大系统、复杂系统中，权限控制能复杂到多么地令人发指。
我曾经做过很多很多产品，涉及面也很广，权限控制系统几乎是每个产品都会涉及的，所以在这方面积累了大量的经验。
我曾经无数次优化和简化各种权限控制系统。最终总结出一套简单有效的方法。我把这套方法称之为：分布式权限控制。
权限控制之所以复杂，最根本的原因是因为集中式的权限设计、分配和管理导致我们不得不“集中式”地，上帝视角地去考虑各种各样的角色在各种各样的场景中的“能”和“不能”。
而，如果，权限的分配和管理被分散开，那么，一切都将变得简单得多了。
一、分布式角色权限体系
经典的权限控制体系都是集中式的角色权限体系。
角色权限体系，一直是主流。
这里介绍的是分布式的角色权限体系。
无论集中式还是分布式，角色权限体系有一点是相同的：角色决定权限，是什么样的人决定了有什么样的能力。
分布式角色权限体系可以分成三种。
[pms-restrict subscription_plans = “1125”]
1、前后端分离的分布式权限控制
在前后端分离的开发模式流行之前，权限的控制只能完全地在后端控制，所以才需要依赖集中式的、复杂的权限控制系统。
而在前后端分离的开发模式中，权限控制完全可以实现前后端的分离。
后端主要负责角色的划分、分配和管理等框架性的事情，前端主要负责根据用户角色实现具体的、细节的权限的控制。
在集中式的角色权限体系中，后端，不仅要分配和管理角色，还要决定每个角色能做什么和不能做什么，然后还要“控制能力”部署到各个地方，最终实现权限的控制。
而在前后端分离的分布式权限控制中，后端只需要分配和管理角色，不需要决定每个角色的“能”与“不能”，也不需要实现具体的权限控制，而是由前端决定每个角色的“能”与“不能”，也由前端实现具体的权限的控制。
那么，整个权限控制系统将变得简单地多，同时，前端的权限控制会更加灵活。
这样一来，就大幅度的降低了权限控制的复杂度。
2、前端的多端分布式权限控制
权限控制实行前后端分离后，可以再将前端多端化。
这里说的多端，实际上是按角色划分的多端。
在很多时候，不同的角色是不需要用同一个“端”的。比如，打车类的产品。乘客端和司机端是完全可以分开的。两个角色的需求完全不同。
乘客端根本不需要考虑司机的需求，司机端也根本不需要考虑乘客的需求。所以乘客端和司机端对于权限控制的要求就变得简单了很多。
所以，在做产品的时候，就需要我们更多地考虑使用这个产品的角色都有什么，需求又分别是什么？
3、后端的多模块分布式权限控制
可以把它理解成权限控制的“微内核架构”和“微服务架构”。
简单的说，就是每个模块都有自己独立的、同时又是按照和其它模块或“内核”同一个标准建立的一套角色。为了方便，我把这样的一套角色命名为“角色系列（role series）”。
一个用户可以拥有多个角色，但，每个角色系列，一个用户只能有一个角色。
这是原则。
这样，用户在某个角色系列中的角色就决定了他在相应的模块中的权限。
权限控制的“微内核架构”和“微服务架构”稍有不同。
- 权限控制的“微内核架构”
集中式的角色分配和管理，分布式的权限控制的实现。类似前后端分离的分布式权限控制。
也就是说，每个模块的角色系列都依赖“内核”的角色体系框架，并且由内核完成角色的分配和管理。但是，每个模块的权限的控制完全由模块自己处理。当模块被启用时，“内核”中才会由这个模块相应的角色系列。当模块被关闭后，“内核”中也不再由这个模块相应的角色系列。
这种方式是我比较推荐的，和权限控制的“微服务架构”想比，在角色整体的管理上会更加方便。
- 权限控制的“微服务架构”
和“微内核架构”不同。“微服务架构”更加“分布式”。
权限控制的“微服务架构”，每个“微服务”都有自己完全独立的角色权限体系。然后用户使用哪个“微服务”模块时，便拥有那个模块分配的的角色和权限。
因为每个“微服务”模块都是处理一些小的功能和业务，所以它的角色权限体系会比较简单。
这样一来，就将整个系统复杂的权限控制分散到各个“微服务”模块上，从而整体上降低权限控制的复杂度。
要采用这种分布式权限控制，需要谨慎，因为每个“微服务”模块的角色如何分配是一个很重要的问题。
其它的分布式权限控制，角色的分配和管理都是集中式的。而这种分布式权限控制，连角色的分配和管理都是分散在各个模块中的。
权限控制的“微内核架构”和“微服务架构”不建议混合使用，会很麻烦。
二、分布式凭证权限体系
和角色权限体系完全不同，凭证权限体系的核心是：凭证决定权限，也就是，用户有什么凭证就有了什么能力，失去某项凭证就失去某些能力。
这个，其实很好理解。
比如，我们去电影院看电影，我们需要先买一张电影票，然后凭着这张电影票，我们才能进入影厅看电影。
而，这张电影票就是凭证。
这就是凭证权限体系。
最常见的几种。
- 优惠券
这个恐怕是我们最常见到的。优惠券就是一种凭证权限体系。有某个优惠券就能享受某项优惠权益，没有，就不能享受这个权益。
- 基于订单的权限控制。
在一些电信、金融之类的业务中，由于各种业务产品种类繁多，并且都不是实体商品。所以，很多时候会采用基于订单的权限控制。有什么样的订单，就有什么样的权限。当订单失效或是过期了，相应的权限则消失。
这种情况下，权限的控制就会变得简单地多。
- 开放平台的APP token
玩技术的都知道，一般开放平台对API的调用限制，是通过给每一个APP分配token实现的。（APPid、APP secret、APP key、APP token，各个平台的名称会不太一样）。
凭证，可以是订单、可以是某种卡券（比如优惠券、会员卡等）、可以是一个token、也可以是一份合约等等。
到目前为止，基于凭证的分布式权限控制的应用是比较少的。
实际上，从根本上来说，角色权限体系本质上就是集中式权限体系，无论采用哪种方式将它“分布式处理”，它依然是集中式的整体架构。
而，凭证权限体系，本质上就是真正的分布式权限体系。
我们以前做的产品、系统，从根本上说都是集中式或类集中式的系统，所以，采用分布式凭证权限体系的场景比较少。而，随着区块链和WEB3的不断深入发展，我认为未来，更多的场景会需要分布式凭证权限体系。
另外，角色权限体系和凭证权限体系是可以混合使用的。而且，实际上，到目前为止，用到凭证权限体系的系统，往往也是以角色权限体系为主的。
[/pms-restrict]