前言

管道架構 （Pipeline Architecture），通常也被稱為 管道-過濾器架構 （Pipes and Filter Architecture），是最常用的架構模式之一。大部分軟件工程師都是通過Unix終端初次接觸到該架構模式，Unix終端的Shell語言，對管道-過濾器有著原生的支持。

比如，現(xiàn)在需要實現(xiàn)這樣的一個功能： 讀取一個文本文件的內容，找到使用頻率最高的5個單詞，并按照使用頻率的大小順序打印出單詞及其使用頻率 。

那么，使用Shell可以這樣來實現(xiàn)：

cat content.txt |     # step1: 讀取文件內容
tr -cs A-Za-z '\\n' |  # step2: 將單詞按行輸出
tr A-Z a-z |          # step3: 將所有單詞轉換為
sort |                # step4: 對單詞進行排序
uniq -c |             # step5: 計算出單詞的頻率
sort -rn |            # step6: 按照頻率對單詞進行排序
head -n 5             # step7: 獲取排序前5的單詞
# 輸出結果示例：
   4 to
   4 and
   3 the
   3 networks
   3 linux

這段Shell代碼就是一個簡單的管道架構實現(xiàn)，其中|表示管道pipe，每一個step就相當于一個過濾器filter。每個filter都將上一個filter的輸出結果作為輸入數(shù)據(jù)，對數(shù)據(jù)進行處理后再將結果輸出到管道中。

除了Shell語言之外，MapReduce也是基于管道架構搭建，其中的map和reduce可以看成是過濾器，只是它們通信的管道為HDFS。

Shell語言和MapReduce編程模型都可以看成是管道架構的low-level實現(xiàn)，當然，它也能應用于higher-level的系統(tǒng)應用上，下面我們來介紹管道架構模式的架構視圖。

架構視圖

管道架構由管道pipe和過濾器filter組成：

管道架構架構視圖

pipe作為filter之間的數(shù)據(jù)傳輸通道，通常都是單向、點對點通信的 ，這樣的設計不僅實現(xiàn)簡單，在性能上也能取得較好的效果。另外，pipe上傳輸?shù)臄?shù)據(jù)并沒有統(tǒng)一的格式，每個系統(tǒng)都可以根據(jù)自身的特點選擇合適的數(shù)據(jù)結構。

filter作為數(shù)據(jù)處理的組件，通常是無狀態(tài)的 。每個filter都應當只完成一項工作，滿足 單一職責原則 ，復雜的工作流應該由多個filter組合而成。一般地，我們將filter分成以下幾種類型：

• Producer : 有時候也稱為 Source ，是整個pipeline的start point，負責從數(shù)據(jù)源中接收數(shù)據(jù)，并將數(shù)據(jù)輸出到pipe中。
• Transformer : 從pipe中接收輸入數(shù)據(jù)，然后對部分或全部數(shù)據(jù)進按照一定的規(guī)則行轉換，并將結果輸出到pipe中。在函數(shù)式編程里，該步驟通常被稱為map。
• Tester : 從pipe中接收數(shù)據(jù)，然后對數(shù)據(jù)進行一些條件判斷，并根據(jù)判斷結果選擇是否將數(shù)據(jù)傳遞到下游的pipe中。需要注意的是， tester并未對數(shù)據(jù)進行任何修改 。
• Consumer : 是整個pipeline的end point，通常將從pipe中讀取到的數(shù)據(jù)持久化到數(shù)據(jù)庫或呈現(xiàn)到用戶界面上。

一個系統(tǒng)中可以有多個producer和consumer，比如我們可以同時通過Kafka和REST接口接收輸入數(shù)據(jù)，經(jīng)過系統(tǒng)的處理后，將結果數(shù)據(jù)存儲到MySQL中，同時也傳遞一份到數(shù)據(jù)倉庫上用作數(shù)據(jù)分析。總之， 管道架構模式有著很大的靈活性 。

應用例子

管道架構模式被廣泛應用在很多應用上，下面我們以一個ETL系統(tǒng)作為例子來理解該模式的運作方式。

ETL （Extract, Transform, Load）是將業(yè)務系統(tǒng)的數(shù)據(jù)經(jīng)過抽取、清洗轉換之后加載到數(shù)據(jù)倉庫的過程，目的是將企業(yè)中的分散、零亂、標準不統(tǒng)一的數(shù)據(jù)整合到一起，為企業(yè)的決策提供分析依據(jù)。

管道架構模式應用例子

業(yè)務應用系統(tǒng)在運行過程中會產(chǎn)生各種各樣的數(shù)據(jù)輸出到kafka中，ETL系統(tǒng)會消費相關數(shù)據(jù)，并在經(jīng)過處理后將結果存儲到數(shù)據(jù)庫上。在上圖的ETL系統(tǒng)里，各個過濾器的作用如下所述：

• Service Info Capture : 訂閱kafka的topic，從中消費業(yè)務系統(tǒng)產(chǎn)生的數(shù)據(jù)，然后通過pipe傳送到下游filter。
• Duration Filter : 判斷數(shù)據(jù)是否與計算 服務請求的處理時長 （duration）指標相關，是則將數(shù)據(jù)傳遞給Duration Calculator，否則傳遞給Uptime Filter。
• Duration Calculator : 計算服務請求的處理時長，并將計算結果傳遞給Database Output。
• Uptime Filter : 判斷數(shù)據(jù)是否與計算 系統(tǒng)正常運行時長 （uptime）指標相關，是則將數(shù)據(jù)傳遞給Uptime Calculator，否則認為數(shù)據(jù)并非本ETL系統(tǒng)所關系，結束數(shù)據(jù)流程。
• Uptime Calculator : 計算系統(tǒng)正常運行時長，并將結果傳遞給Database Output。
• Database Output : 將數(shù)據(jù)持久化到MongoDB中。

上述的ETL系統(tǒng)由1個producer filter，2個tester filter，2個transform filter和1個consumer filter組成，主要的數(shù)據(jù)處理邏輯是計算系統(tǒng)的遙測指標。系統(tǒng)在架構上具有很高的可擴展性，比如后續(xù)想要新增一個指標計算，我們可以在Uptime Filter之后加上新的tester和transform，系統(tǒng)原有的指標計算無需改動；又比如系統(tǒng)后續(xù)打算用HBase替換MongoDB，那么我們可以新開發(fā)一個HBase Output替換掉原有的Database Output，系統(tǒng)的其他流程同樣無需改動。

架構評分

管道架構模式的架構評分

管道架構模式通常被實現(xiàn)為單體架構，同分層架構模式一樣，因為單體架構本身的劣勢，其在Elasticity、Fault tolerance、Scalability方面都具有很低的評分。Simplicity是管道架構模式的主要優(yōu)點之一，filter和pipe實現(xiàn)簡單，可以快速構建起一個基于管道架構風格的系統(tǒng)，因此也具有很高的Overall cost評分。

另外，相比于分層架構模式，管道架構模式在Modularity、Evolutionary和Testability上都有著較高的評分， 這得益于filter之間的松耦合，我們可以很容易擴展系統(tǒng)的filter，以及對單個filter進行測試 。

總結

本文主要介紹了管道架構模式，它由管道pipe和過濾器filter組成。根據(jù)具體的數(shù)據(jù)處理邏輯，它將filter劃分為producer、transformer、tester和consumer四種類型，是一種典型的technical partition軟件架構風格。管道架構模式因為其可擴展性很高的特點而被廣泛應用，其中不乏有Shell語言這種low-level的實現(xiàn)，也有ETL系統(tǒng)這種high-level的實現(xiàn)。

雖說該模式通常被實現(xiàn)為單體架構，但也有像MapReduce這種基于分布式系統(tǒng)的編程模式實現(xiàn)，總之，如果你需要為一個數(shù)據(jù)處理型的系統(tǒng)選型，那么可以認真地考慮是否采用管道架構模式。

每種架構模式都有其合適的應用場景，只有熟悉常用的幾種架構模式，才能設計出更好的軟件系統(tǒng)。下一篇文章，我們將繼續(xù)介紹 微內核架構 。