分析：SaaS RES 1.0对于功能权限和数据权限都有需求 ， 对于功能权限控制 ， 系统采用公司开发的通用权限组件2.0实现 ， 同时 ， 由于系统的数据权限是根据组织架构进行划分的 ， 数据权限控制的组织架构还会采用公司开发的通用组织架构组件实现 ， 通用权限组件2.0以一种事件拦截的机制来实现基于RBAC的功能权限控制 ， 其原理如下图：图表 5.1.41 通用权限组件2.0原理图当用户试图访问系统的功能服务时 ， 功能 。

38、权限拦截器会首先把用户的请求拦截下来 ， 然后把用户信息和请求信息发送给功能权限控制器 ， 功能权限控制器会根据用户信息从权限数据库中获取该用户的授权信息 ， 即角色集合 ， 然后再获取这些角色的功能权限集合 ， 最后判断出该用户是否拥有其请求的功能服务的访问权 ， 如果有 ， 则请求被传递给相应功能服务 ， 如果没有 ， 请求被拒绝 ， 并重定向到拒绝访问的错误页面 。
使用权限组件这种拦截机制的好处是：把基于角色的访问控制逻辑彻底的从业务逻辑中分离 ， 业务开发人员只需要关注业务 ， 无需编写任何权限判断的逻辑 ， 这大大减轻了业务开发人员的工作量 ， 也提高了系统的灵活性 。
如果说基于角色的访问控制权限与业务无关 ， 那么数据权限却与业务有比较紧密的联 。

39、系 ， 比如：销售团队A的普通销售员只能跟踪自己的客户 ， 但其团队主管却可以跟踪团队内所有成员的客户 。
这些可以看作是系统业务的一部分 ， 但对于SaaS RES 1.0来说 ， 这种数据级别的权限控制是相对稳定和单一的 ， 如上所述 ， 它只有三个级别的数据权限 。
对于数据权限控制 ， 权限组件2.0只提供了扩展的机制 ， 并没有提供具体的实现 。
决策：根据上面的分析 ， 我们可以有两种方式实现数据权限控制：l 直接在业务代码中编写数据权限控制的逻辑 ， 把它视作业务逻辑的一部分；l 通过权限组件2.0提供的框架进行扩展 。
上面提到 ， SaaS RES 1.0的数据权限控制是相对稳定和单一的 ， 这就意味着 ， 数据权限控制的逻辑有很高的重用可能 。

40、性 ， 如果采取第一种方式 ， 业务开发人员就不得不关注数据权限控制逻辑了 ， 而且把数据权限控制逻辑交由业务开发人员实现 ， 代码就很容易失控 。
权限组件2.0虽然没有提供数据权限控制的实现 ， 但它却提供了一个良好的框架 ， 让业务系统可以在框架的基础上进行扩展 ， 实现数据权限控制 。
可以看到 ， 两种方案都需要编写等量的数据权限控制代码 ， 但后者可以让系统的结构更加清晰、合理和容易维护 ， 因此 ， 后者是一种更合适的选择 。
其原理如下图：图表 5.1.42 权限组件2.0中数据权限扩展原理图用户的请求还是先要进行RBAC的功能权限判断（见上述说明） ， 当通过了功能权限判断后 ， 用户请求会进一步被传递给访问前权限处理器 ， 这里的“访问前权 。

41、限处理器”就是权限组件的框架提供的一个扩展点 ， SaaS RES 1.0需要实现此处理器 ， 它的作用是进行数据权限处理 ， 判断当前用户对目标数据是否有操作权 ， 如果没有 ， 则直接拒绝访问 ， 如果有 ， 则可以对用户的请求进行加工 ， 最常见的做法是 ， 为请求添加上数据筛选过滤条件 ， 如：用户发起了一个获取客户列表的功能请求 ， 该用户是销售团队A的普通销售员 ， 访问前权限处理器发现普通销售员这个角色的数据权限级别是“本人负责的数据” ， 则对该请求进行加工 ， 为其添加上“数据拥有者标识”作为筛选条件 ， 然后再把请求发送给业务系统的对应功能服务 。
当服务处理完后 ， 返回结果又会被进一步传递给访问后权限处理器 ， “访问后权限处理器”同样是权 。

42、限组件框架提高的扩展点 ， 可以通过实现此处理器 ， 对返回的结果进行加工 ， 比如屏蔽某些敏感数据等 。
通过这样的设计 ， 利用权限组件框架提供的扩展点 ， 既能很好的实现系统对于数据权限控制的要求 ， 也让数据权限控制的逻辑和功能权限控制逻辑一样 ， 从业务系统的业务逻辑中抽离 ， 使系统的结构更加合理和灵活 。
5.1.5 支持多租户的数据结构由于目前已经确定使用MySQL作为数据库的约束 ， 要支持多租户 ， 我们有以下三种方式可以选择：1.每个租户都有独立的数据库2.租户共享同一个数据库 ， 但独立数据结构（即一个租户对应一个schema）3.租户共享同一个数据库 ， 且共享相同的数据结构 。

稿源：(未知)

【傻大方】网址：/a/2021/0902/0024073868.html

标题：SaaS|SaaS RES营销管理系统架构设计( 七 )