本篇和大家谈谈一种通用的设计与处理模型——Pipeline（管道）。
Pipeline简介
Pipeline模型最早被使用在Unix操作系统中。据称，如果说Unix是计算机文明中最伟大的发明，那么，Unix下的Pipe管道就是跟随Unix所带来的另一个伟大的发明【1】。我认为管道的出现，所要解决的问题，还是软件设计中老生常谈的设计目标——高内聚，低耦合。它以一种“链式模型”来串接不同的程序或者不同的组件，让它们组成一条直线的工作流。这样给定一个完整的输入，经过各个组件的先后协同处理，得到唯一的最终输出。
Pipeline模型的应用
以下列举了，我熟悉或者有所了解的典型pipeline模型的应用。
公司.net web程序员很多，那么首先就谈谈asp.net。一个http请求到达http服务器IIS之后，就是经过pipeline模型被处理的。参见下图：
说明一下，这幅图，并没有下面的图形来得直观。它的侧重点在于展示管道中各个组件处理事件触发的时序图，而不是pipeline模型。但如果你思考以下，也能体会到其中“管道”的概念（注意右面循环图标，如果需要比划一下的话，就是一个U逆时针旋转90度的形状）。
最后，我还是决定上个清晰点的图：
上图可以请求到达IIS，经过HttpApplication工厂得到一个HttpApplication，创建一个HttpContext上下文，然后就会进入Http Pipeline。好了，这篇的目标并不是谈论http处理行为以及asp.net底层架构，所以到此为止。
又一个大家熟悉的web container，特别是java web人员——Tomcat
Tomcat接受请求之后，请求从被接受，被分发，被处理，到最后转变成http响应，会走如下的管道【2】：
在《Tomcat系统架构与设计模式，第2部分: 设计模式分析》【3】中，你可以清晰地发现一个最为显而易见的设计模式——责任链模式（这是实现管道模型比较常用的一种设计模式）
可见，pipeline模型几乎是大部分主流http server处理请求的通用模型。这种设计并不意外，因为pipeline模型特定的理念会让你感觉到它似乎就是为了处理请求而生的。事实上，它的应用原不止这些web 服务器架构。
下面，给大家带来的另一个典型示例也是在web架构里广为人知的MVC模型的良好实践——Struts:
我认为用这幅图来阐述Pipeline最为清晰，简洁。从上面这幅图中你能够看到对于pipeline模型的多处使用（单向、双向都有）。它也很好地展示了高内聚，低耦合的设计目标，展示了各个组件以类似“搭建积木”的形式来组合功能（见图中Interceptor），我最近有空也在读struts2的源码，如果你也有兴趣，可以看看这个专题。
最后一个示例了，公司Java服务器的开发人员，相信都会对Mina框架有所了解。下面是Mina的处理模型图：
不再废话了，同样是pipeline的优秀实践。
上面介绍了很多pipeline的优秀实践，他们并非来自同一个领域，有web端，有处理socket的等。但对于他们的一个归纳，可以是——优秀的服务端数据处理模型，我觉得公司在数据处理上比较频繁，这也是选择介绍pipeline模型的原因。
Pipeline模型带来的启示
其实，关于它的好处已经在上面各种优秀的实践中得以体现。但你还是应该能够从中去发现一些能够为我们所用的设计思想。我总结了我得一些观点，欢迎各位拍砖：
(1)工作流的参考模型
上面的各个模型图很难让我不把pipeline模型与工作流模型联想到一块儿去。他们都是链式的（或者说流程式的），就像一条生产线一样。各个组件的前后协同，会让你联想到生产流水线上得工人处理流过自己的产品环节。事实上，我在去年年末的时候在云方圆徐工基础任务流程里面曾经尝试使用了该模型，作为工作流模型。
(2)服务framework的参考构建模型
Pipeline模型的一个特点是，在其内部是以组建的模式来实现组合的（虽然这些组建有先后顺序之分），它假如你把侧重点放在它的链式组合上，而不是将侧重点放在上面的工作流上（工作流的关注点是流程的先后顺序），那么完全可以用这种方式来搭建一个复杂的服务，当然这样做的前提是，单个组件的粒度必须尽可能小并且耦合性极低。
在这里我冒昧吐槽几句：
在我的印象中，公司很多服务都喜欢采用WebService，即使不是Web Service也是Http GET请求。当然，，这其中的很多情况是不得不采用它来和别的系统或者业务平台交互。但我一直坚持认为，只有在理论上你根本没有可能拿到那些数据时，你才会采用别人提供的服务，比如：股票行情、天气预报、各大开放平台（新浪、支付宝）的API的等。本公司之内的，原则上其实可以访问的某些数据，有时我们反而退而求其次选择采用Web Service这种模式。批量数据走http或者之上的协议（SOAP）在网络上传输，有时web系统还有可能发布在远端。想要性能从哪儿来？我了解你担心安全性，希望保持本业务平台数据库的独立性。告诉我，其实你也明白有些担心是没有意义的。我直接连你的库，只做一些查询会有什么问题？如果你真的比较谨慎的话，你也应该担心一下你的系统有被攻击的可能性，为什么你没有呢。甚至有人希望，某些相似的业务逻辑也把他抽象出来在dll外面包装成web service。如果真得是这样的话，我觉得“可复用的组件”这个词就没有必要存在了。
Pipeline模型应用
刚才谈到，我认为Pipeline模型带来的启示，我个人更看好第二点。我认为在NGP构建API的时候，这种模型也能够派上大用场。
就拿Redis举个例子（在一些场景下）：
读取数据流程
(1)客户程序从Redis读取数据，如果读取到则返回
(2)如果没有读取到，则从数据库抓取数据
(3)从数据库抓取到的数据存储到Redis
写入数据流程
(1)客户程序将数据写入Redis
(2)将数据写入数据库
天不负;卧薪尝胆，三千越甲可吞吴。
