再谈pipeline-filter模式

本文结合最近我正在实现的一个基于RabbitMQ的消息总线上所走的弯路来谈谈设计层面上的责任链模式以及架构层面上的pipeline-filter模式。写这篇文章的另一个目的是为了纠正我之前针对pipeline-filter模式写的一篇博文：《pipeline-filter模式变体之尾循环》，如果你想看看我之前为什么要那么做，你可以先看看那篇文章，不过无论看不看都不影响这篇文章的行文。

消息总线需要扩展性

目前这个消息总线实现了produce/consume、request/response、publish/subscribe、broadcast这几种消息通信场景。这些场景中都涉及到消息的处理。

我想实现一种基于plugin的消息处理。它们需要是粒度较细的，并可在各种消息通信模式之间可复用、易于扩展的，并且基于配置文件可以自动将这些不同的plugin串联成一个pipeline。这种模式称之为责任链模式或pipeline-filter模式（如果你区分得严谨，那么可能会将pipeline-filter划归为架构模式，见POSA 卷4），如果你做过java web开发，你总是容易将它跟filter联系起来。没错，filter的这种模式其实就是责任链模式。

两种模式的主流认识

其实通常我们谈责任链跟pipeline-filter，大部分的注意力都集中在“进”的意识上：数据（通常被封装在一个上下文对象中）在调用链上被每个filter依次处理，向前推进。但java web技术里的filter的实现却同时关注了“进与退”：

这是多种原因共同作用的结果：

1. http有请求也有响应：数据的处理不是单向的，是个闭合的回路
   
2. 它的上下文其实是两个对象：HttpServletRequest、HttpServletResponse，进的时候关注HttpServletRequest对象，退的时候关注HttpServletResponse对象，分工明确，互不干扰
   
3. 实现这种filter-chain的做法通常都是递归调用；而递归调用在方法执行上涉及到入栈跟出栈的过程。临界点就是方法内部对该递归方法的调用（见上面的chain.doFilter。调用之前的代码可看做入栈，会被先调用；调用之后的代码可被看做出栈，会在所有入栈完成后再依次出栈时被调用）。而图中最后的servlet的Service可以看作是该递归的break point，执行完成之后，将会开始退的（处理HttpServletResponse）流程
   

这里有个简单的filter示例：它先判断http请求头中是否包含了支持gzip压缩的信息：如果没包含就直接进入下一步，如果包含了则提取出响应对象，将输出流进行gzip压缩。毫无疑问，提取响应对象肯定应该在servlet被执行之后，但这个filter开始被执行的时机却是在servlet之前，它就依靠了递归调用的入栈跟出栈的执行机制。它同时有对HttpServletRequest以及HttpServletResponse对象的处理：

public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        logger.info("[doFilter] enter into CompressionFilter");
        HttpServletRequest req = (HttpServletRequest) servletRequest;
        HttpServletResponse resp = (HttpServletResponse) servletResponse;

        String encoding = Strings.nullToEmpty(req.getHeader("Accept-Encoding"));

        if (encoding.contains("gzip")) {
            CompressionResponseWrapper warppedResp = new CompressionResponseWrapper(resp);
            warppedResp.setHeader("Content-Encoding", "gzip");
            filterChain.doFilter(req, warppedResp);

            GZIPOutputStream gzos = warppedResp.getGZIPOutputStream();
            gzos.finish();
        } else {
            filterChain.doFilter(req, resp);
        }
    }

顺便提一下，只关注前进的话，只需要将递归调用放在最后一句即可（也就是让递归调用后面不再有代码逻辑）。

消息总线中遇到的问题

第一个问题：上面那篇文章中提到过，在接收消息的时候，由于RabbitMQ官方的java client，提供了一种阻塞等待的推送消费的API，这种模式对于client的用户不够友好，通常我们需要基于它构建一个独立的event loop（在另一个线程上），以onMessage的事件回调作为一种异步API的实现更为友好，因此它涉及到了chain中的处理器跨线程的问题，并且在event loop上会在chain尾部的几个处理器上作循环（消息等待与消息处理）。

第二个问题：web容器针对http区分开请求对象和响应对象，使得它们职责清晰，互不干扰，进退有度。而在消息总线中，单次处理消息的过程（只单独调用produce或consume）中不存在两个上下文对象的语义，这误导我只能把chain的进和退切开来，做成AOP的pre-aspect以及post-aspect（这种实现是我自上面提到的那篇文章之后的改进版）。

第三个问题：这是一大问题，我确实忽略了java实现filter“有进有退”的设计，而总是想着POSA那本书上有进无退的架构层面上的设计，这导致其中有个处理器是从对象池中借出对象，而归还的逻辑却不是在该处理器的递归调用点之后（而是在post-aspect中）。

改进方案

针对第一个问题：我换了个思维，如果我们将异步接收消息的整个chain都包含到event loop线程中（之前只是作为阻塞等待，并触发onMessage的一种实现机制），就解决了chain中有处理器需要跨线程问题；而将接收到消息之后的处理逻辑不再以处理器的方式拆分、复用，而是以继承以及子类化的方式进行复用，这解决了所谓的在chain“尾部循环”的问题。

针对第二、第三个问题：摈弃之前所谓的将一条chain切割成pre-aspect以及post-aspect的处理方式，采用了java中filter的设计方式，以递归调用的临界点的区分“进”、“退”逻辑。

写在最后

pipeline这个词在表述中一直不是太精确，有人用它表达责任链模式，有人将其代指pipeline&filter。在交流上自然不必太过较真，但我想从这篇文章可以给出一个很好的区分：责任链模式是设计模式，面向程序实现；pipeline&filter是架构模式。而不同点，我想你也看到了。

当时实现这部分代码的时候我正好在看POSA卷四，里面谈及了架构模式pipeline-filter。而我想这就是设计模式跟架构模式的区别：设计模式面向代码实现，而在代码实现中不关注运行代码的服务器的部署拓扑结构；而架构模式是一种抽象级别更高的模式，而且卷四本身就是面向分布式系统的，因此它所谓的filter其实是一个分布式的数据处理组件，这自然是一种纯粹的有进无退的的pipeline。

事实上这种设计到现在已经经历到第三版了。第一版是就是那篇文章中说明的方式，完全是POSA表达的那种；第二版，我有意看了一下java filter的实现，但当时被其两个上下文对象搞糊涂了，认为这是一种特定场景下的实现（有请求，有响应），并且我确实没有正视递归调用的实现起了主要作用。第三版，完全基于责任链的设计模式。

代码见: banyan