橙单微服务的权限部分之过滤规则

在橙单中，我们是通过mybatis拦截器统一拦截的，这样最大的好处是业务代码的解耦，不用每个开发人员，都自己写过滤了，很容易错和漏掉。

而mybatis拦截器，也是比较通用的插件方式

通过上图可以看到，我们支持部门过滤和用户过滤，这些都是可以在在线表单和生成器的路由表单中指定的，每个业务表都可以指定自己的

上图是生成器中的配置，在线表单也类似吧

重点说一下代码

生成的代码中，会多出注解，分别是部门和用户过滤

会生成响应的数据权限过滤注解

有需求是，这个mapper下，有的方法需要过滤，有的不需要
注解参数，可以指定哪些方法，不进行过滤
这个是纵向的

还有一种场景是，同一个方法，有的controller接口进来的时候，需要不需要过滤。
这种场景，在工作流中，比较常见，毕竟工作流的数据权限，需要和普通表单的相比，有些差距，需要更好的整合

比如截图中，查看草稿数据，这个就不需要数据过滤，这样我们可以在controller的入口加这个注解即可。

这个就是横向的细粒度控制

还有一种更复杂的控制，就是同一个controller中，有的需要，有的不需要。

当然，这里有个前提，就是业务主表一定是配置了数据过滤注解，否则那就不需要这些的，

现在介绍的前提都是业务主表配置了数据权限过滤。

在线表单和路由表单，行为都是一致的

在最复杂的场景下，也可以手动修改这个标记，对后续的sql，暂时停用数据过滤。

刚刚介绍的这些，都是如何使用

其实绝大多数场景，都不需要这么细粒度控制的

可以看到，我们所有的细粒度控制，都不会需要修改mybatis拦截器中的代码，通过外部的设置，即可完成横纵向的细粒度控制。

在简单介绍一下过滤实现，

数据权限过滤，效率极为重要，灵活性也很重要，因为数据过滤，几乎覆盖绝大多数的sql，select，delete和update，而不仅仅是select，所以他的优化尤为重要

先说简单的优化。明天再分享复杂的优化，涉及到的数据结构。

第一步，就是在服务启动的时候，将所有的实体类和mapper类的注解都预先解析好，并放到map中，便于快速检索

拦截器的入口代码，可以看到，我们这里都没有使用插件模式，多租户和数据过滤都在不同的方法里面，这样做主要还是为了效率，同时也便于二次开发的修改。

大家排错的时候，或者发现数据过滤不起作用的时候，这些几个return尤为重要。有的是逻辑，有的是优化

比如最后一个红框中最后一个return，就是当数据权限中，包含，“可以查看全部”的时候，就没必要继续过滤了，基于短路优化的原则。因为我们取的是数据并集。

用户的数据权限数据，在用户登录的时候，已经缓存到redis了。也是为了加速

这里插一句和效率无关的话，sql语句的动态解析，我们使用了jsqlparser，主要还是为了保证拦截后，sql语句注入的正确性，而且一味的追求效率，仅仅简单的在尾部添加where sql，那样对于子查询，就不work了，而橙单现有的方式，可以支持子查询，支持别名等更为复杂且通用的场景

这里才是真正处理数据权限sql的实现方法。

基于用户的过滤，没啥好优化的，主要的优化在部门过滤，

这里有部门过滤的合并

代码大家看一下，介绍一下合并机制，这样更加易于理解

比如用户A，有两个数据权限，分别是只看本部门和看本部门及其子部门
那个这个时候，只看本部门的数据权限，就没有必要继续使用了，因为后者覆盖了前者，这样我们生成的过滤sql，将只有适合后者，查看本部门及其子部门的。
如果不做合并优化，就会出现两个 deptId = 1 or dpet_id in (本部门和子部门id列表）优化后可以去掉deptId = 1那个
再说另外一种，本部门及子部门，和，多部门及子部门，如果选择的多部门中，包含本部门的话，那么前者就可以忽略了，
如果指定的多部门及其子部门中，不包含本部门，比如我的本部门id是1， 我选择的自定义部门是2,3,4这个时候，就不能忽略1，也就是本部门，但是我们同样做了优化，会把（1,2,3,4）合并到一起，做一次性的sql in list查询，而非一个 = 1 or in （2,3,4）
这两个优化都是非常典型的，其实还有其他的，橙单会推演，如果覆盖就和合并。
大家会问，动态合并也有微小的性能开销呀，虽然比不优化要好。
橙单当然也想到了，这些合并，不是动态查询时候合并，而是用户登录的时候，就完成了合并。

好了，今天就分享到这里了，后面会给大家分享，我们如何让递归的树形部门搜索，编程一次性的数据查询，没有递归。

树形部门扁平化，是一个通用的树形数据优化策略，有兴趣可以去看一下橙单的代码，我们极好的实现了这个，包含使用了闭包插入，等非常高效使用的代码技巧。

以后会给大家分享橙单的多数据源处理，也是极为灵活且直观的