赞
踩
相信大家在日常的开发中都遇到过复杂数据处理和复杂数据校验的场景,本文从一线开发者的角度,分享了责任链模式在这种复杂数据处理场景下的实战案例,此外,作者在普通责任链模式的基础上进行了升级改造,可以适配更加复杂的应用场景;文章整体读下来,可以让读者对于设计模式-责任链模式有深刻的印象。
什么是责任链模式
责任链模式让多个对象都有机会处理同一个请求。它将请求的发送者和处理者之间进行解耦,同时将这些处理者对象连成一条链,并沿着这条链传递该请求,满足条件的处理者会执行相应的逻辑直至走完整个链条;
如果在一次请求中,需要多个处理者处理多种复杂的逻辑,且希望能够解耦多个处理者,实现高扩展性,可以考虑使用责任链模式。
Servlet中的过滤器(Filter)和过滤器链(FilterChain)
Filter和FilterChain是【责任链模式】的一种热门应用场景,过滤器Filter相信大家都很熟悉了,我们在Servlet中经常能发现它的身影。
【Filter】一般用于Servlet处理之前做一些前置的校验,每个Filter都有自己的职责和逻辑。调用filter时,需要传入当前filterChain的引用,来告诉filter当前执行的是哪一个filterChain
- public interface Filter {
- //初始化方法
- public void init(FilterConfig filterConfig) throws ServletException;
- //处理逻辑,
- public void doFilter(ServletRequest request, ServletResponse response,
- FilterChain chain) throws IOException, ServletException;
- //生命周期销毁
- public void destroy();
- }
【FilterChain】是由多个Filter组成的链条,如果在链上的filter校验通过或处理完成,那么调用"chain.doFilter(request, response)"就可以让下一个filter继续执行逻辑直到filterChain结束
- public interface FilterChain {
- public void doFilter(ServletRequest request, ServletResponse response)
- throws IOException, ServletException;
- }
请求资源时,过滤器链中的过滤器依次对请求进行处理,并将请求传递给下一个过滤器,直到最后将请求传递给目标资源。发送响应信息时,则按照相反的顺序对响应进行处理,直到将响应返回给客户端;
Servlet中的责任链模式给我们展示的是利用Filter和FilterChain来过滤和拦截请求;我们在复杂的业务场景中是否也能模仿来实现一个业务处理的责任链呢?
我们可以发现,Filter与Filter之间是互相解耦的,我们可以很轻量级的加入一个新的Filter到FilterChain当中;
此外,我们还可以实现多个FilterChain,其中装载不同的Filter来适配多种业务场景。
业务场景应用案例
在电商平台的很多业务场景下,涉及到对于数据的多重校验或多重过滤等操作。而随着业务的增长,校验逻辑或者数据处理逻辑会变得越来越复杂,这个时候责任链模式就能够体现出很好的优势了。
拿创建优惠券活动来举例;用户可以自由选择某些类目、某些商品或者某些门店来参与券活动;并且可以按需导入或者选择自己需要参与活动的数据;
【系统需要校验用户上传的数据是否满足业务条件、并将校验失败的数据返回给客户】
根据上述业务场景,在一次请求中,我们需要做多种校验逻辑:
数据鉴权校验、过滤用户无权限的数据
若用户选择商品,需对商品类型进行校验;(电商的商品模型有很多种,每一种商品模型都对应一种校验规则)
若用户选择门店,需对门店类型进行校验;(电商的门店类型也有很多,比如线上门店、旗舰店、线下门店等等,需要判断门店是否能够参与优惠活动)
对于不同投放渠道也有不同渠道的校验规则
我们需要完整的走完所有校验逻辑,而不能因为中途的一个逻辑校验不通过而阻断校验,因为我们需要返回给用户一个完整的数据校验结果;举个例子,如果用户上传的商品当中,既存在无权限的商品,又存在不符合商品类型的数据,那么我们需要走完所有校验逻辑,一并给用户返回所有的报错,而不是只返回无权限的商品;
其他校验规则……
如果使用流水式代码,将会显得很臃肿,且有很多ifelse……嵌套,让人很难看懂和维护。如下:
- //校验数据
- if (用户选择商品) {
- if (商品模型一) {
- //校验逻辑1
- } else if (商品模型二) {
- //校验逻辑2
- } else if (商品模型三) {
- //校验逻辑3
- } else {
- //校验逻辑4
- }
- } else if (用户选择门店) {
- if (门店模型一) {
- //校验逻辑1
- } else if (门店模型二) {
- //校验逻辑2
- }
- //校验逻辑……
- } else if (用户选择类目) {
- //校验逻辑……
- }
- //校验渠道
- if (渠道是A渠道){
-
-
- } else if (渠道是B渠道){
-
-
- }
上述伪代码仅仅只覆盖了几种简单的校验场景;试想就算开发完成之后,如果下次再有一个业务逻辑校验需要加入进来,则对代码需要进行很大的改动,需要重新梳理if else 的逻辑,缺乏代码的可读性和可拓展性。
我们可以遵守单一职责原则,定义多个Filter对象,每个对象实现自己的业务校验逻辑;同时主干代码上仅需要初始化一个FilterChain,并调用doFilter方法执行链上每一个filter即可。
参照Servlet的filter与filterChain接口【见2.1】,自己实现了多种不同的过滤器,也在其基础上结合业务需求进行了相应的改进:
让Filter对象具备顺序属性,初始化FilterChain的时候,可以按顺序排列filter;同时定义accept方法,让filter自行控制是否处理请求。
- @Data
- public abstract class AbstractOrderFilter implements Filter, Comparable<AbstractOrderFilter> {
- protected Integer order;
- @Override
- public int compareTo(AbstractOrderFilter o) {
- return getOrder().compareTo(o.getOrder());
- }
- //根据Filter自己使用的业务场景,自行定义
- public boolean accept(FilterRequestDTO filterRequestDTO) {
- return true;
- }
- @Override
- public void doFilter(FilterRequestDTO filterRequestDTO, FilterChain filterChain) {
- }
- }
举例:定义一个ItemPermissionFilter,专门做商品权限校验
- @Slf4j
- public class ItemPermissionFilter extends AbstractOrderFilter {
- //当前filter对应的业务逻辑manager(自行根据业务场景定义)
- ItemCheckManager itemCheckManager;
- //构造器私有
- private ItemPermissionFilter(Integer order, ItemCheckManager itemCheckManager) {
- super.order = order;
- this.itemCheckManager = itemCheckManager;
- }
- @Override
- public void doFilter(FilterRequestDTO filterRequestDTO, FilterChain filterChain) {
- if (accept(filterRequestDTO)) {
- //业务逻辑对应的manager进行校验处理(不做展开)
- itemCheckManager.checkItemPermission(filterRequestDTO, elementCheckResults);
- }
- //继续走责任链的下一个filter
- filterChain.doFilter(filterRequestDTO);
- }
- @Override
- public boolean accept(FilterRequestDTO filterRequestDTO) {
- //自行根据业务场景定义处理何种请求
- return true;
- }
- //对外暴露的create方法
- public static ItemPermissionFilter create(Integer order, ItemCheckManager itemCheckManager) {
- return new ItemPermissionFilter(order, itemCheckManager);
- }
- }
注意其中几个属性:
【filters】是filterChain当中的filter集合;
【posLocal】是一个ThreadLocal变量,记录着当前filterChain执行到了第几个filter的index;
【checkResult】也是一个ThreadLocal变量,它记录着全局所有Filter的校验结果,每执行一个filter,filter就会把当前的执行结果记录在该变量中,之后会统一返回给用户,大大减少了参数的传递复杂度;
- public class CouponFilterChain implements FilterChain {
- /**
- * 责任链中的所有的处理组件 非变量
- */
- private final List<? extends AbstractOrderFilter> filters;
- /**
- * 当前执行到的位置 这是个共享变量
- */
- private static ThreadLocal<Integer> posLocal = ThreadLocal.withInitial(() -> 0);
-
-
- /**
- * 责任链的校验结果--即需要给用户反馈的校验结果,共享变量,threadLocal,会作为全局参数
- */
- public static final ThreadLocal<List<CheckResult>> checkResult = new ThreadLocal<>();
-
-
- /**
- * 包含filter数量 非变量
- */
- private final int size;
-
-
- @Override
- public void doFilter(FilterRequestDTO filterRequestDTO) {
- //共享变量记住当前filterChain执行的filter的index,直至结束
- Integer pos = posLocal.get();
- if (pos < size) {
- pos++;
- posLocal.set(pos);
- Filter filter = this.filters.get(pos - 1);
- filter.doFilter(filterRequestDTO, this);
- }
- }
-
-
- //供外部业务代码调用的主要方法
- public BaseResult<CheckResult> process(FilterRequestDTO filterRequestDTO) {
- this.doFilter(filterRequestDTO);
- //将共享变量里面的结果取出来,返回给用户
- return BaseResult.makeSuccess(checkResult.get(););
- }
-
-
- @Override
- //注意避免ThreadLocal内存泄漏,要remove
- public void reset() {
- posLocal.remove();
- posLocal.set(0);
- checkResult.remove();
- }
-
-
- public CouponFilterChain(List<? extends AbstractOrderFilter> filters) {
- filters.sort(AbstractOrderFilter::compareTo);
- this.filters = filters;
- this.size = filters.size();
- }
- }
在实现好了Filter已经FilterChain之后,我们需要对他们进行初始化,这个时候就可以根据你所需要的业务场景自行组装filter到filterChain当中; 有多种初始化方法,下面只简单介绍一种(将商品filter和门店filter初始化)
- @Component
- @Slf4j
- public class FilterChainManager {
- @Resource
- StoreManager storeManager;
- @Resource
- ItemManager itemManager;
-
-
- private CouponFilterChain couponFilterChain;
-
-
- //初始化责任链
- @PostConstruct
- private void init() {
- //总链
- List<AbstractOrderFilter> filters = new ArrayList<>();
- //按需添加链上的filter……
- //商品校验filter
- filters.add(ItemFilter.create(100, ItemManager));
- //门店校验filter
- filters.add(StoreFilter.create(200, StoreManager));
- this.couponFilterChain = new CouponFilterChain(filters);
- }
-
-
- //供外部调用的方法
- public BaseResult<CheckResult> process(FilterRequestDTO filterRequestDTO) {
- BaseResult<CheckResult> result = null;
- try {
- //责任链模式,校验每一个参数的合法性并输出错误原因
- result = couponFilterChain.process(filterRequestDTO);
- return result
- } catch (Exception e) {
- return TMPResult.failOf("system error", e.getMessage());
- } finally {
- //这里非常重要 必须重置
- if (couponFilterChain != null) {
- couponFilterChain.reset();
- }
- }
- }
- }
到此我们已经实现了责任链模式,可以画个图理解一下:
有时候我们的filter当中可能需要加上一些子处理,为了遵守单一职责原则,不适合将这些业务逻辑放在同一个filter中,于是考虑将多个filter合并组合成一个大的Filter; SpringMVC还有一种过滤器叫做组合过滤器CompositeFilter,过滤器里面嵌套过滤器,使得整个处理过程更加有层次;参照org.springframework.web.filter.CompositeFilter【有兴趣的同学可以参考下源码】,自己定义了一个CompositeFilter
- /**
- * 合成的过滤器,改过滤器内部由多个过滤器组合而成
- */
- public class CompositeFilter extends AbstractOrderFilter {
- /**
- * 所有的责任事件
- */
- private List<? extends AbstractOrderFilter> filters = new ArrayList();
-
-
- public CompositeFilter(Integer order, List<? extends AbstractOrderFilter> filters) {
- super.order = order;
- this.filters = filters;
- }
-
-
- @Override
- public void doFilter(FilterRequestDTO filterRequestDTO, FilterChain filterChain) {
- (new InnerFilterChain(filterChain, this.filters)).doFilter(filterRequestDTO);
- }
-
-
- /**
- * 内部链处理逻辑,优先将合成过滤器的内部过滤器进行处理,然后再传给下一个过滤器
- */
- private static class InnerFilterChain implements FilterChain {
- private final FilterChain originalChain;
- private final List<? extends AbstractOrderFilter> additionalFilters;
- private int currentPosition = 0;
-
-
- public InnerFilterChain(FilterChain chain, List<? extends AbstractOrderFilter> additionalFilters) {
- this.originalChain = chain;
- this.additionalFilters = additionalFilters;
- }
-
-
- @Override
- public void doFilter(FilterRequestDTO filterRequestDTO) {
- if (this.currentPosition >= this.additionalFilters.size()) {
- //如果已经执行完了内部过滤器,则跳到外部继续执行外部下一个节点的过滤器
- this.originalChain.doFilter(filterRequestDTO);
- } else {
- //继续执行内部过滤器
- this.currentPosition++;
- AbstractOrderFilter currentFilter = this.additionalFilters.get(this.currentPosition - 1);
- currentFilter.doFilter(filterRequestDTO, this);
- }
-
-
- }
-
-
- @Override
- public void reset() {
-
-
- }
- }
-
-
- public static CompositeFilter create(Integer order, List<? extends AbstractOrderFilter> filters) {
- filters.sort(AbstractOrderFilter::compareTo);
- return new CompositeFilter(order, filters);
- }
- }
实现了组合过滤器之后,可以将其与FilterChain结合; 示意图如下图所示,在一条责任链上可以有普通的Filter和CompositeFilter,当执行到B时,按照B内部的顺序,从内部子filterB1执行开始一直到B4,直到执行完整个组合责任链然后再执行C,依次类推。可以看出CompositeFilter让整个责任链模块化,模块与模块之间能够各司其职,模块内部也能按照自定义的顺序执行。
思考
本文实现的责任链仅供参考,大家可以结合自己的业务场景定义合适的FilterChain和Filter;与Servlet中的Filter不同的是,本文中定义的Filter只有一个入参FilterRequestDTO,而是将response作为了ThreadLocal共享变量,大家使用时也一定要注意内存泄漏的风险。
其实不需要FilterChain,我们只需要使用一个List<Filter>并保留Filter与Filter之间的引用关系即可,如一个Filter的next指针指向下一个Filter;定义FilterChain的原因我想也是开发者考虑到封装和更好的变化。
如果直接上手阅读源码,很容易被层层的方法带乱自己的阵脚;带着问题和目的去阅读和学习源码是一件事半功倍的事情,会让你在学习过程中有一条清晰明朗的线。
¤ 拓展阅读 ¤
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。