本文探讨:
- 什么是管道过滤器风格(Pipe-and-filter Style)
- 管道过滤器风格的约束
- 管道过滤器风格的适用场景
- 什么是批量顺序处理风格(Batch-sequential Style)
- 批量顺序处理风格的约束
- 批量顺序处理风格的适用场景
- 批量顺序处理与管道过滤器的差异是什么
- 什么是过程控制风格(Process Control Style)
- 过程控制处理风格的约束
- 过程控制处理风格的适用场景
不论是出国还是看电影,不知道你有没有发现,很多国家的自来水是可以直接喝的,而中国的就不行。你有没有想过,为什么我们国家的自来水不能直接喝呢?而且好像就只有中国人特别喜欢喝热水!感冒、咳嗽、不舒服,发烧、流感、大姨妈,只要身体有点什么不舒服了,不管三七二十一,先喝点热水!
这主要和以前的瘟疫、寄生虫、肠胃炎有关系。以前的水基本没有过滤,寄生虫病菌比较多,经常引起各种疾病,所以很多国家都对水进行了净化处理,能达到直接喝的标准。而以前我们国家还没有能力做这种净化处理,但是发现水烧开了也可以有效的杀死这些细菌,所以喝热水的传统就这么延续下来了。
对水的净化处理其实原理很简单,就是「过滤」!如果你家里安装过净化水系统,应该会发现净化器一般都会有几个过滤器,一般是三个。作用就是自来水经过一个个的过滤器,去除了水中的各种杂质,能达到直接饮用的程度。其中,每一个过滤器都是独立的,可以独立的替换。
数据流风格就是类似的处理方式,将数据看做水,一个个的处理单元看过一层层的过滤,数据经过一个个的处理单元,最终达到我们需要的结果。
说到过滤器,我们的第一印象应该就是Web开发中遇到的「过滤器/拦截器」了,继而想到的应该就是设计模式中的职责链模式。
所以我们就从我们熟悉的职责链模式开始,来聊聊「数据流风格」。
职责链模式
职责链的类图如下:
从结构上看,职责链模式有两个对象:Client和Handler(包括具体的Handler实现)
![](/qrcode.jpg)
- Client发送消息给Handler
- Handler将消息委托给具体的Handler链条处理
- 处理完成后,返回给Client
Handler的具体实现就是一个个的过滤器,独立的处理数据,也可以独立的替换,这就解耦了请求发送者和接收者。请求沿着Handler链条依次传递,每个Handler判断是否需要处理该请求,直到所有Handler都处理完成为止。
职责链主要适用于如下场景:
- 有多个对象可以处理一个请求,但是哪个对象处理该请求需要运行时自动确定
- 需要在不明确指定接收者的情况下,向多个对象中的一个提交一个请求
- 可处理一个请求的对象集合是动态指定的
下面是一个简单的clojure例子:
(defn handler-request1 [condition]
(if (= "ConcreteHandler1" condition)
(println "ConcreteHandler1 handled ")
(println "ConcreteHandler1 passed ")))
(defn handler-request2 [condition]
(if (= "ConcreteHandler2" condition)
(println "ConcreteHandler2 handled ")
(println "ConcreteHandler2 passed ")))
(defn handler-requestn [condition]
(println "ConcreteHandlern handled "))
(->> "ConcreteHandler2"
handler-request1
handler-request2
handler-requestn)
;handler-request2和handler-requestn会处理此字符串
管道过滤器风格
管道过滤器风格和职责链模式在结构上比较类似。管道过滤器风格包含了四个组件:
- 读端口:用于读取数据,如标准输入流、文本文件或传感器采集的数据等。类似职责链的Client发送消息。
- 写端口:用于写出数据,如文本文件、数据库、标准输出等。类似职责链的Client接收处理完的消息。
- 管道:用于连接各个过滤器,使得消息能在各个过滤器之间进行流转,也包含数据缓冲作用。类似职责链里的调用(消息发送)
- 过滤器:处理消息组件,过滤器可以通过pull(后续过滤器从当前过滤器中拉取数据),push(前面的过滤器向当前过滤器推送数据)或主动方式(不断从前面的过滤器中拉取数据,并向后面的过滤器推送数据)来获取消息。类似职责链模式里的Handler。
管道过滤器风格的完整流程为:「读端口」获取需要处理的信息,通过管道传递给过滤器链,每个过滤器自行判断是否需要对信息进行处理,一个过滤器处理完后通过管道将消息传递给下一个或多个过滤器,直到所有的过滤器全部处理完毕,通过写端口,将处理完成的信息写出到目标位置。
管道过滤器风格的典型应用有:
- Linux的Shell
- JavaEE Servlet Filter
- 传统的编译器:一个阶段(包括词法分析、语法分析、语义分析和代码生成)的输出是另一个阶段的输入。
以Linux的Shell为例:
cat "app.log" | grep "^error" | cut -f 2
- cat指令获取app.log的内容,将结果通过管道传递给grep
- grep指令过滤出所有以error开头的行,将结果通过管道传递给cut
- cut取出第二列的内容
在这里cat,grep,cut就是一个个的过滤器;而 | 就是管道;输入输出则是标准输入输出。
管道过滤器风格将处理逻辑封装到独立的过滤器中:
- 可以通过新增过滤器的方式增加对信息的处理逻辑,相反可以通过移除过滤器的方式减少对信息的处理逻辑。提高了系统的扩展性
- 过滤器之间没有逻辑上的关联关系,提高了复用性
- 同时易于增加过滤器和移除过滤器,提高了系统的可维护性
- 但是每个过滤器需要对信息进行解析,降低了系统性能,以及增加了过滤器自身的复杂度
- 不过过滤器可以并行执行,这可以提高系统性能
管道过滤器风格主要用于处理数据的系统,不适用于处理交互的应用。
批量顺序处理风格
同样的「批量顺序处理风格」也是主要用于处理数据的架构风格。一般它的处理组件称为阶段(stages)或者步骤(steps)。
它的处理流程如下:
- 读取一批数据,进行处理
- 信息不是通过所谓的「管道」在各个阶段之间进行流转,而是通过类似临时中间文件来进行阶段之间的流转,而文件可以被删除
- 下一阶段需要在前一阶段处理完后才能执行
- 下一阶段会从前一阶段处理后的文件里,选择自己需要的文件进行处理,处理后再写到文件中
批量顺序处理风格的每一步处理都是独立的,并且每一步是顺序执行的。只有当前一步处理完,后一步处理才能开始。数据传达在每一步处理之间作为一个整体。比较适用于需要顺序执行的某些固定操作的场景,并且这种流程不经常进行变化。Windows下的BAT程序就是这种应用的典型实例。
批量顺序处理风格对架构属性的影响与管道过滤器基本一致,这里不再赘述。
管道过滤器与批量顺序处理差异
两种风格都包含一系列的计算组件,通过将数据交给这一系列的计算组件来处理,来完成任务。
两种风格的不同之处在:
管道过滤器风格 | 批量顺序处理风格 |
---|---|
细粒度 | 粗粒度 |
结果驱动处理 | 高延迟 |
内部输入 | 外部访问输入 |
可以并发 | 不支持并发 |
交互不友好 | 不支持交互 |
内部输入:过滤器之间直接传递数据
外部访问输入:批量顺序处理一般都会先输出到一个临时文件,下一个阶段再从临时文件中获取
过程控制风格
过程控制风格和上面的两个风格处理方式差异较大,一般应用在嵌入式开发中,包含了四个组件:
- 传感器(Sensor):监听某些重要信息
- 控制器(Controller):逻辑控制
- 执行器(Actuator):操作过程的物理方法
- 过程(Process):你想要控制的内容
空调使用的就是过程控制风格,如下图:
- 我们打开空调,设置了21度
- 空调的温度传感器(Sensor)检测到室内温度(Process)为15度,温差为6度
- 控制器(Controller)控制执行器(Actuator)吹热风
- 当室内温度达到21度后,传感器就通知控制器控制执行器停止工作
过程控制风格将系统拆分为一个个的子系统或模块:
- 各个子系统或模块相互独立,提高了模块的复用性,以及系统的进化性和可维护性
- 子系统或模块间的交互可能会影响性能