63 | 职责链模式（下）：框架中常用的过滤器、拦截器是如何实现的？

三者应用范围不同: web filter 作用于容器，应用范围影响最大；spring interceptor 作用于框架，范围影响适中；aop 作用于业务逻辑，精细化处理，范围影响最小。

Filter 可以拿到原始的http请求，但是拿不到你请求的控制器和请求控制器中的方法的信息; Interceptor 可以拿到你请求的控制器和方法，却拿不到请求方法的参数; Aop 可以拿到方法的参数，但是却拿不到http请求和响应的对象

针对问题1而言，其实要实现一个鉴权的过滤器，通过以上3种方式都是可以去实现的，然而从粒度，场景，和方式上边有有所区别，主要采取用哪个，还是有业务来决定去用，没有统一的参考标准。比如要对所有的web接口，进行统一的权限处理，不需要区分动作，写或者读，所有一视同仁，这种情况下，servlet的更加适合。针对一些存在状态的，比如做一些统一的去参数转换，cookie转uid之类，以及通用检验uid是否符合当前权限，则很用mvc较好，而aop粒度就可以分的更加细致了，在一些更新需要，查询不需要的，如分控，日志记录等，就比较适合

AOP、Servlet Filter、Spring Interceptor这三者可以从不同权限检查的范围大小的视角来应用： 1. Servlet Filter 运维部门需要对只供内部访问的服务进行IP限制或访问审查时，在容器这一层增加一个Filter，在发布时发布系统自动加挂这个Filter，这样对上层应用就是透明的，内网IP地址段增减或审查规则调整都不需要上层应用的开发人员去关心。 2. Spring Interceptor 由框架或基础服务部门来提供的微服务间相互调用的授权检查时，可以提供统一的SDK，由程序员在需要的服务上配置。 3. AOP 业务应用内权限检查，可以把权限检查在统一模块中实现，通过配置由AOP加插拦截检查。

首先需要明确“访问控制功能”的粒度，如果访问控制功能要精确到每个请求，那么要使用AOP，AOP可以配置每个controller的访问权限。而Spring interceptor和servlet filter的粒度会粗一些，控制HttpRequest, HttpResponse的访问。另外servlet filter不能够使用 Spring 容器资源，只能在容器（如tomcat）启动时调用一次，而Spring Interceptor是一个Spring的组件，归Spring管理，配置在Spring文件中，因此能使用Spring里的任何资源、对象，例如 Service对象、数据源、事务管理等，通过IoC注入到Interceptor即可。相比较而言，Spring interceptor更灵活一些。

针对问题1，一把泪水想起了项目中的坑. 个人觉得最大的不同还是生效粒度的问题. 1. Servlet Filter是针对Servlet容器里的方法都能生效. 就是说Servlet容器里就算要把Spring换成别的框架，鉴权代码依然能生效. 2. Spring开头的就只能在Spring中生效， 2.1. 但更好还是在interceptor，因为interceptor天然的设计背景就是[在请求前，在相应后.] 2.2. 如果用AOP实现，就很依赖于AOP的pointcut设置，一不小心就会在[一次请求响应里]执行了[多次重复的鉴权服务]……

1、个人感觉权限的话，属于api的调用，应该放在调用链比较靠前的位置，早发现早处理，所以用Servlet Filter会更好一些吧，如果是rpc层的话，例如dubbo，就需要 在实现filter的时候通过order吧filter得优先级提高一些，让这个filter先执行，个人感觉哈 2、Dubbo Filter的核心处理逻辑在ProtocolFilterWrapper类下的buildInvokerChain这个方法中，属于把所有的filter的类对象搞成一个list，通过遍历list去调用所有的filter，Netty ChannelPipeline我记得是一个双向链表，pipeline 中的节点的数据结构是 ChannelHandlerContext 类，每个 ChannelHandlerContext 包含一个 ChannelHandler这种，支持从头尾开始传播事件，也就是触发调用，也可以从中间节点进行调用，入栈(read)是从head开始传播，也就是开始依次调用，出栈(write)是从tail开始传播，倒着调用。感觉算是对责任链的一个拓展使用，记不清了，得去看看代码，如果说错了，欢迎指点

课后题1，当然是全部都是用啊。 filter，可以控制所有的请求，用来处理网络攻击什么的。 interceptor可以控制用户和非用户的登录啊。 AOP可以控制用户角色对方方法的访问权限。 详情请见shiro，或者spring security。

Servlet Fillter，Spring Interceptor，Spring AOP三者粒度是越来越细的。根据业务场景的覆盖度选择。 1. 比如限流就可以在Filter层去做，因为全局都需要限流防止服务被压垮。 2. 用户是否登录权限等可以使用Interceptor做。 3. 细粒度到类或者方法的控制使用AOP去做，比如日志 事务 方法级别权限。

一个请求从客户端到服务端再到响应，假设Filter、Interceptor、AOP都存在，经过的路径大概是：请求->Filter->Interceptor->AOP->核心业务处理->AOP->Interceptor->Filter->响应。 Filter、Interceptor、 AOP在不同的节点所能感知到的数据状态都是不同的，姑且理解为域不同吧，要实现权限访问控制，肯定是在到达核心业务前植入权限控制逻辑，那就在“请求->Filter->Interceptor->AOP->核心业务处理”。 权限控制逻辑需要三个核心属性：资源、角色、角色资源映射。资源：一般我们用uri来标识某一个资源，或者可以通过注解等方式在方法上声明一个资源标识；角色和角色资源映射一般通过读取Session获取。那么权限控制逻辑放在那里取决于哪里可以拿到这两个信息？理论上角色和角色资源映射在哪里都可以读取到的。就看资源怎么表示了，如果你的资源是标识的servlet，那就通过Filter控制，如果你的资源是标识的Controller，可以在Interceptor控制，如果你的资源是标识的很深层的方法，可以在AOP控制