前言
管道架構(gòu) (Pipeline Architecture),通常也被稱為 管道-過濾器架構(gòu) (Pipes and Filter Architecture),是最常用的架構(gòu)模式之一。大部分軟件工程師都是通過Unix終端初次接觸到該架構(gòu)模式,Unix終端的Shell語言,對管道-過濾器有著原生的支持。
比如,現(xiàn)在需要實(shí)現(xiàn)這樣的一個(gè)功能: 讀取一個(gè)文本文件的內(nèi)容,找到使用頻率最高的5個(gè)單詞,并按照使用頻率的大小順序打印出單詞及其使用頻率 。
那么,使用Shell可以這樣來實(shí)現(xiàn):
cat content.txt | # step1: 讀取文件內(nèi)容
tr -cs A-Za-z '\\n' | # step2: 將單詞按行輸出
tr A-Z a-z | # step3: 將所有單詞轉(zhuǎn)換為
sort | # step4: 對單詞進(jìn)行排序
uniq -c | # step5: 計(jì)算出單詞的頻率
sort -rn | # step6: 按照頻率對單詞進(jìn)行排序
head -n 5 # step7: 獲取排序前5的單詞
# 輸出結(jié)果示例:
4 to
4 and
3 the
3 networks
3 linux
這段Shell代碼就是一個(gè)簡單的管道架構(gòu)實(shí)現(xiàn),其中|
表示管道pipe,每一個(gè)step就相當(dāng)于一個(gè)過濾器filter。每個(gè)filter都將上一個(gè)filter的輸出結(jié)果作為輸入數(shù)據(jù),對數(shù)據(jù)進(jìn)行處理后再將結(jié)果輸出到管道中。
除了Shell語言之外,MapReduce也是基于管道架構(gòu)搭建,其中的map
和reduce
可以看成是過濾器,只是它們通信的管道為HDFS。
Shell語言和MapReduce編程模型都可以看成是管道架構(gòu)的low-level實(shí)現(xiàn),當(dāng)然,它也能應(yīng)用于higher-level的系統(tǒng)應(yīng)用上,下面我們來介紹管道架構(gòu)模式的架構(gòu)視圖。
架構(gòu)視圖
管道架構(gòu)由管道pipe和過濾器filter組成:
管道架構(gòu)架構(gòu)視圖
pipe作為filter之間的數(shù)據(jù)傳輸通道,通常都是單向、點(diǎn)對點(diǎn)通信的 ,這樣的設(shè)計(jì)不僅實(shí)現(xiàn)簡單,在性能上也能取得較好的效果。另外,pipe上傳輸?shù)臄?shù)據(jù)并沒有統(tǒng)一的格式,每個(gè)系統(tǒng)都可以根據(jù)自身的特點(diǎn)選擇合適的數(shù)據(jù)結(jié)構(gòu)。
filter作為數(shù)據(jù)處理的組件,通常是無狀態(tài)的 。每個(gè)filter都應(yīng)當(dāng)只完成一項(xiàng)工作,滿足 單一職責(zé)原則 ,復(fù)雜的工作流應(yīng)該由多個(gè)filter組合而成。一般地,我們將filter分成以下幾種類型:
- Producer : 有時(shí)候也稱為 Source ,是整個(gè)pipeline的start point,負(fù)責(zé)從數(shù)據(jù)源中接收數(shù)據(jù),并將數(shù)據(jù)輸出到pipe中。
- Transformer : 從pipe中接收輸入數(shù)據(jù),然后對部分或全部數(shù)據(jù)進(jìn)按照一定的規(guī)則行轉(zhuǎn)換,并將結(jié)果輸出到pipe中。在函數(shù)式編程里,該步驟通常被稱為
map
。 - Tester : 從pipe中接收數(shù)據(jù),然后對數(shù)據(jù)進(jìn)行一些條件判斷,并根據(jù)判斷結(jié)果選擇是否將數(shù)據(jù)傳遞到下游的pipe中。需要注意的是, tester并未對數(shù)據(jù)進(jìn)行任何修改 。
- Consumer : 是整個(gè)pipeline的end point,通常將從pipe中讀取到的數(shù)據(jù)持久化到數(shù)據(jù)庫或呈現(xiàn)到用戶界面上。
一個(gè)系統(tǒng)中可以有多個(gè)producer和consumer,比如我們可以同時(shí)通過Kafka和REST接口接收輸入數(shù)據(jù),經(jīng)過系統(tǒng)的處理后,將結(jié)果數(shù)據(jù)存儲到MySQL中,同時(shí)也傳遞一份到數(shù)據(jù)倉庫上用作數(shù)據(jù)分析??傊?, 管道架構(gòu)模式有著很大的靈活性 。
應(yīng)用例子
管道架構(gòu)模式被廣泛應(yīng)用在很多應(yīng)用上,下面我們以一個(gè)ETL系統(tǒng)作為例子來理解該模式的運(yùn)作方式。
ETL (Extract, Transform, Load)是將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)經(jīng)過抽取、清洗轉(zhuǎn)換之后加載到數(shù)據(jù)倉庫的過程,目的是將企業(yè)中的分散、零亂、標(biāo)準(zhǔn)不統(tǒng)一的數(shù)據(jù)整合到一起,為企業(yè)的決策提供分析依據(jù)。
管道架構(gòu)模式應(yīng)用例子
業(yè)務(wù)應(yīng)用系統(tǒng)在運(yùn)行過程中會產(chǎn)生各種各樣的數(shù)據(jù)輸出到kafka中,ETL系統(tǒng)會消費(fèi)相關(guān)數(shù)據(jù),并在經(jīng)過處理后將結(jié)果存儲到數(shù)據(jù)庫上。在上圖的ETL系統(tǒng)里,各個(gè)過濾器的作用如下所述:
- Service Info Capture : 訂閱kafka的topic,從中消費(fèi)業(yè)務(wù)系統(tǒng)產(chǎn)生的數(shù)據(jù),然后通過pipe傳送到下游filter。
- Duration Filter : 判斷數(shù)據(jù)是否與計(jì)算 服務(wù)請求的處理時(shí)長 (duration)指標(biāo)相關(guān),是則將數(shù)據(jù)傳遞給Duration Calculator,否則傳遞給Uptime Filter。
- Duration Calculator : 計(jì)算服務(wù)請求的處理時(shí)長,并將計(jì)算結(jié)果傳遞給Database Output。
- Uptime Filter : 判斷數(shù)據(jù)是否與計(jì)算 系統(tǒng)正常運(yùn)行時(shí)長 (uptime)指標(biāo)相關(guān),是則將數(shù)據(jù)傳遞給Uptime Calculator,否則認(rèn)為數(shù)據(jù)并非本ETL系統(tǒng)所關(guān)系,結(jié)束數(shù)據(jù)流程。
- Uptime Calculator : 計(jì)算系統(tǒng)正常運(yùn)行時(shí)長,并將結(jié)果傳遞給Database Output。
- Database Output : 將數(shù)據(jù)持久化到MongoDB中。
上述的ETL系統(tǒng)由1個(gè)producer filter,2個(gè)tester filter,2個(gè)transform filter和1個(gè)consumer filter組成,主要的數(shù)據(jù)處理邏輯是計(jì)算系統(tǒng)的遙測指標(biāo)。系統(tǒng)在架構(gòu)上具有很高的可擴(kuò)展性,比如后續(xù)想要新增一個(gè)指標(biāo)計(jì)算,我們可以在Uptime Filter之后加上新的tester和transform,系統(tǒng)原有的指標(biāo)計(jì)算無需改動;又比如系統(tǒng)后續(xù)打算用HBase替換MongoDB,那么我們可以新開發(fā)一個(gè)HBase Output替換掉原有的Database Output,系統(tǒng)的其他流程同樣無需改動。
架構(gòu)評分
管道架構(gòu)模式的架構(gòu)評分
管道架構(gòu)模式通常被實(shí)現(xiàn)為單體架構(gòu),同分層架構(gòu)模式一樣,因?yàn)閱误w架構(gòu)本身的劣勢,其在Elasticity、Fault tolerance、Scalability方面都具有很低的評分。Simplicity是管道架構(gòu)模式的主要優(yōu)點(diǎn)之一,filter和pipe實(shí)現(xiàn)簡單,可以快速構(gòu)建起一個(gè)基于管道架構(gòu)風(fēng)格的系統(tǒng),因此也具有很高的Overall cost評分。
另外,相比于分層架構(gòu)模式,管道架構(gòu)模式在Modularity、Evolutionary和Testability上都有著較高的評分, 這得益于filter之間的松耦合,我們可以很容易擴(kuò)展系統(tǒng)的filter,以及對單個(gè)filter進(jìn)行測試 。
總結(jié)
本文主要介紹了管道架構(gòu)模式,它由管道pipe和過濾器filter組成。根據(jù)具體的數(shù)據(jù)處理邏輯,它將filter劃分為producer、transformer、tester和consumer四種類型,是一種典型的technical partition軟件架構(gòu)風(fēng)格。管道架構(gòu)模式因?yàn)槠?strong>可擴(kuò)展性很高的特點(diǎn)而被廣泛應(yīng)用,其中不乏有Shell語言這種low-level的實(shí)現(xiàn),也有ETL系統(tǒng)這種high-level的實(shí)現(xiàn)。
雖說該模式通常被實(shí)現(xiàn)為單體架構(gòu),但也有像MapReduce這種基于分布式系統(tǒng)的編程模式實(shí)現(xiàn),總之,如果你需要為一個(gè)數(shù)據(jù)處理型的系統(tǒng)選型,那么可以認(rèn)真地考慮是否采用管道架構(gòu)模式。
每種架構(gòu)模式都有其合適的應(yīng)用場景,只有熟悉常用的幾種架構(gòu)模式,才能設(shè)計(jì)出更好的軟件系統(tǒng)。下一篇文章,我們將繼續(xù)介紹 微內(nèi)核架構(gòu) 。
-
UNIX
+關(guān)注
關(guān)注
0文章
296瀏覽量
42111 -
架構(gòu)
+關(guān)注
關(guān)注
1文章
528瀏覽量
25863 -
過濾器
+關(guān)注
關(guān)注
1文章
436瀏覽量
20245
發(fā)布評論請先 登錄
微服務(wù)架構(gòu)和CQRS架構(gòu)基本概念介紹
微服務(wù)優(yōu)勢_微服務(wù)架構(gòu)的好處與不足
什么是微服務(wù)架構(gòu)_微服務(wù)架構(gòu)的優(yōu)缺點(diǎn)及應(yīng)用

SOA架構(gòu)和微服務(wù)架構(gòu)的主要區(qū)別

微服務(wù)架構(gòu)有哪些_微服務(wù)架構(gòu)設(shè)計(jì)模式

微服務(wù)架構(gòu)的特點(diǎn)_微服務(wù)架構(gòu)適用場景
微服務(wù)軟件架構(gòu)應(yīng)用研究綜述
從分層架構(gòu)到微服務(wù)架構(gòu)介紹(一)

從分層架構(gòu)到微服務(wù)架構(gòu)介紹(二)

從分層架構(gòu)到微服務(wù)架構(gòu)介紹(四)

從分層架構(gòu)到微服務(wù)架構(gòu)介紹(五)

springcloud微服務(wù)架構(gòu)
docker微服務(wù)架構(gòu)實(shí)戰(zhàn)
設(shè)計(jì)微服務(wù)架構(gòu)的原則

架構(gòu)與設(shè)計(jì) 常見微服務(wù)分層架構(gòu)的區(qū)別和落地實(shí)踐

評論