立即登入 做业务中台的时候，多租户下的权限管理几乎避不开，也最容易踩坑。最近我把整条思路重新梳理了一遍，这篇文章就试着用一种比较好理解的方式，把基于业务中台的多租户权限设计讲清楚。
后台系统的权限管理，其实有一套很通用的套路。不管是 CRM、ERP、EHR 还是电商管理后台，只要涉及多人协作、多部门使用，就一定会碰上权限控制的问题。绝大多数场景的底层逻辑都差不多：把系统运行中产生的菜单、页面、按钮、字段，甚至数据，统统注册成“资源”，然后把资源打包成“角色”，再把角色和用户关联起来。用户登录后访问某个资源时，系统会查他关联的所有角色，看里面有没有包含这个资源，有就放行，没有就拦住。有时候为了方便，还会多加一层用户组，让角色先绑到用户组上，用户再继承用户组的角色，批量管理起来就省事多了。
单个应用这么做，思路确实很直接，也好理解。但一旦把场景切换到业务中台，而且还要支持多租户，就不是这套“单机版”玩法能兜得住的了。这时候必须把租户、应用实例、集中管理这些概念一起拉进来，权限体系才能搭得稳。
为什么要引入这些？因为业务中台的核心目标，就是让企业能快速、低成本地拼装出新的业务应用。一个中台上往往会长出各式各样的应用，不同租户之间数据要隔离，权限也必须隔离。我们作为一家做中台标准产品的厂商，走的是 SaaS 模式，面对的是不同客户，权限设计就必须解决三个很现实的问题：第一，出厂初始化时，需要一套自动化的权限引导流程，不能让客户从零开始配置，那体验太差了；第二，买 SaaS 的客户，更希望在一个地方集中管理所有用户的权限，而不是每个应用单独折腾一遍，否则运营成本太高；第三，不同角色和场景下，对权限管理的诉求完全不一样，比如租户管理员需要全局视角，而应用内的管理员可能只想管好自己那一亩三分地。
我们现在的产品结构大致是这样：业务中台作为基础设施，通过一个叫 MPC 的配置中心，把需要的能力组合成一个个应用，实现能力的复用，快速响应业务变化。应用不是凭空产生的，而是靠配置加上一定的前端页面开发做出来的。然后，我们可以为每个租户单独制作应用实例，租户之间的数据天然隔离。
客户买走整套标准产品后，系统里会预置一个 root 账户，这个 root 持有所有资源权限，算是“上帝视角”。用 root 来创建租户，并为租户实例化应用时，系统会自动为租户生成一个租户管理员，并给他预置好对应应用实例的管理员角色。这一步，就解决了出厂初始化的权限引导问题。租户管理员拿到账号后，登录到业务运营中心（BOC），就能在租户范围内做很多事情：创建用户、设置这些用户可以登录哪些应用、为任何一个应用实例创建角色，再把角色分配给用户。同时，他也能在全局管理界面上统一管理每个应用实例里的角色。这样一来，集中管理就实现了，不需要每个应用再单独维护一套用户体系。
应用内部又怎么办？如果某个用户被赋予了应用实例的权限，他就可以进入这个应用，甚至可以在应用内部继续创建用户和角色，做更细颗粒度的权限划分。这就满足了不同场景下，不同角色对权限灵活性的要求。
这里顺带把几个容易混淆的概念理一理，因为后面再复杂的系统，只要把这几样东西搞清楚了，权限设计就不容易乱。租户，是 SaaS 模式下数据隔离的基本单位，每个租户有自己独立的数据空间。应用实例，就是在租户数据空间中跑起来的那个应用程序。用户，是真正使用系统的人，他们能访问哪些资源，完全由关联的角色决定。资源，就是系统运行中产生的菜单、页面、按钮、字段、数据这些，统统都是资源。
整体看下来，这套方案其实就是把常规的权限管理模型，在业务中台和多租户的语境下做了一次延伸。把初始化、集中管理、灵活分级这些需求都嵌了进去，用 root、租户管理员、应用内角色这几层，把权限的边界切割清楚。这样既能保证开箱即用，又不失灵活性，也比较符合 SaaS 场景下客户的实际操作习惯。
如果对这套设计有任何不同的看法，随时可以一起讨论。毕竟权限管理这种事，没有绝对的银弹，只有不同场景下最合适的取舍。