從分層架構到微服務架構(三)之管道架構
《從分層架構到微服務架構》是一系列介紹《Fundamentals of Software Architecture》中提到的 8 種架構模式的文章,這裏不會事無鉅細地介紹所有的細節,而是會挑選其中關鍵內容,更多詳情請閱讀原書。
前言
管道架構(Pipeline Architecture),通常也被稱爲管道 - 過濾器架構(Pipes and Filter Architecture),是最常用的架構模式之一。大部分軟件工程師都是通過 Unix 終端初次接觸到該架構模式,Unix 終端的 Shell 語言,對管道 - 過濾器有着原生的支持。
比如,現在需要實現這樣的一個功能:讀取一個文本文件的內容,找到使用頻率最高的 5 個單詞,並按照使用頻率的大小順序打印出單詞及其使用頻率。
那麼,使用 Shell 可以這樣來實現:
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 代碼就是一個簡單的管道架構實現,其中|
表示管道 pipe,每一個 step 就相當於一個過濾器 filter。每個 filter 都將上一個 filter 的輸出結果作爲輸入數據,對數據進行處理後再將結果輸出到管道中。
除了 Shell 語言之外,MapReduce 也是基於管道架構搭建,其中的map
和reduce
可以看成是過濾器,只是它們通信的管道爲 HDFS。
Shell 語言和 MapReduce 編程模型都可以看成是管道架構的 low-level 實現,當然,它也能應用於 higher-level 的系統應用上,下面我們來介紹管道架構模式的架構視圖。
架構視圖
管道架構由管道 pipe 和過濾器 filter 組成:
管道架構架構視圖
pipe 作爲 filter 之間的數據傳輸通道,通常都是單向、點對點通信的,這樣的設計不僅實現簡單,在性能上也能取得較好的效果。另外,pipe 上傳輸的數據並沒有統一的格式,每個系統都可以根據自身的特點選擇合適的數據結構。
filter 作爲數據處理的組件,通常是無狀態的。每個 filter 都應當只完成一項工作,滿足單一職責原則,複雜的工作流應該由多個 filter 組合而成。一般地,我們將 filter 分成以下幾種類型:
-
Producer: 有時候也稱爲 Source,是整個 pipeline 的 start point,負責從數據源中接收數據,並將數據輸出到 pipe 中。
-
Transformer: 從 pipe 中接收輸入數據,然後對部分或全部數據進按照一定的規則行轉換,並將結果輸出到 pipe 中。在函數式編程裏,該步驟通常被稱爲
map
。 -
Tester: 從 pipe 中接收數據,然後對數據進行一些條件判斷,並根據判斷結果選擇是否將數據傳遞到下游的 pipe 中。需要注意的是,tester 並未對數據進行任何修改。
-
Consumer: 是整個 pipeline 的 end point,通常將從 pipe 中讀取到的數據持久化到數據庫或呈現到用戶界面上。
一個系統中可以有多個 producer 和 consumer,比如我們可以同時通過 Kafka 和 REST 接口接收輸入數據,經過系統的處理後,將結果數據存儲到 MySQL 中,同時也傳遞一份到數據倉庫上用作數據分析。總之,管道架構模式有着很大的靈活性。
應用例子
管道架構模式被廣泛應用在很多應用上,下面我們以一個 ETL 系統作爲例子來理解該模式的運作方式。
ETL(Extract, Transform, Load)是將業務系統的數據經過抽取、清洗轉換之後加載到數據倉庫的過程,目的是將企業中的分散、零亂、標準不統一的數據整合到一起,爲企業的決策提供分析依據。
管道架構模式應用例子
業務應用系統在運行過程中會產生各種各樣的數據輸出到 kafka 中,ETL 系統會消費相關數據,並在經過處理後將結果存儲到數據庫上。在上圖的 ETL 系統裏,各個過濾器的作用如下所述:
-
Service Info Capture: 訂閱 kafka 的 topic,從中消費業務系統產生的數據,然後通過 pipe 傳送到下游 filter。
-
Duration Filter: 判斷數據是否與計算_服務請求的處理時長_(duration)指標相關,是則將數據傳遞給 Duration Calculator,否則傳遞給 Uptime Filter。
-
Duration Calculator: 計算服務請求的處理時長,並將計算結果傳遞給 Database Output。
-
Uptime Filter: 判斷數據是否與計算_系統正常運行時長_(uptime)指標相關,是則將數據傳遞給 Uptime Calculator,否則認爲數據並非本 ETL 系統所關係,結束數據流程。
-
Uptime Calculator: 計算系統正常運行時長,並將結果傳遞給 Database Output。
-
Database Output: 將數據持久化到 MongoDB 中。
上述的 ETL 系統由 1 個 producer filter,2 個 tester filter,2 個 transform filter 和 1 個 consumer filter 組成,主要的數據處理邏輯是計算系統的遙測指標。系統在架構上具有很高的可擴展性,比如後續想要新增一個指標計算,我們可以在 Uptime Filter 之後加上新的 tester 和 transform,系統原有的指標計算無需改動;又比如系統後續打算用 HBase 替換 MongoDB,那麼我們可以新開發一個 HBase Output 替換掉原有的 Database Output,系統的其他流程同樣無需改動。
架構評分
管道架構模式的架構評分
管道架構模式通常被實現爲單體架構,同分層架構模式一樣,因爲單體架構本身的劣勢,其在 Elasticity、Fault tolerance、Scalability 方面都具有很低的評分。Simplicity 是管道架構模式的主要優點之一,filter 和 pipe 實現簡單,可以快速構建起一個基於管道架構風格的系統,因此也具有很高的 Overall cost 評分。
另外,相比於分層架構模式,管道架構模式在 Modularity、Evolutionary 和 Testability 上都有着較高的評分,這得益於 filter 之間的松耦合,我們可以很容易擴展系統的 filter,以及對單個 filter 進行測試。
總結
本文主要介紹了管道架構模式,它由管道 pipe 和過濾器 filter 組成。根據具體的數據處理邏輯,它將 filter 劃分爲 producer、transformer、tester 和 consumer 四種類型,是一種典型的 technical partition 軟件架構風格。管道架構模式因爲其可擴展性很高的特點而被廣泛應用,其中不乏有 Shell 語言這種 low-level 的實現,也有 ETL 系統這種 high-level 的實現。
雖說該模式通常被實現爲單體架構,但也有像 MapReduce 這種基於分佈式系統的編程模式實現,總之,如果你需要爲一個數據處理型的系統選型,那麼可以認真地考慮是否採用管道架構模式。
每種架構模式都有其合適的應用場景,只有熟悉常用的幾種架構模式,才能設計出更好的軟件系統。下一篇文章,我們將繼續介紹微內核架構。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/rw1r53GXmvzFLEDrYKKCxQ