Ch11: Pipeline Architecture Style#
Pipeline architecture（管道式架構），也稱為 pipes and filters 架構，是軟體架構中不斷重複出現的基本風格。Unix shell 語言（如 Bash、Zsh）背後的核心原理就是這種架構。
許多 functional programming 語言的語法構造，以及 MapReduce 程式模型，都遵循這個基本拓撲結構。
Topology（拓撲結構）#
Pipeline architecture 由兩個主要元件組成：Pipes 和 Filters。
Pipes#
- 形成 filter 之間的通訊通道
- 通常是單向的（unidirectional）和點對點的（point-to-point）
- 從一個 source 接收輸入，輸出到另一個 source
- Payload 可以是任何格式，但較小的資料量有助於提升效能
Filters#
- 自包含的（self-contained）、獨立的（independent）、通常是無狀態的（stateless）
- 每個 filter 應只執行一個任務，複合任務應由多個 filter 組成的序列處理
四種 filter 類型：
- Producer — 流程的起點，只有輸出（也稱為 source）
- Transformer — 接收輸入，對資料進行轉換後輸出（類似 functional programming 的
map） - Tester — 接收輸入，根據一個或多個條件測試，選擇性產生輸出（類似
reduce） - Consumer — 流程的終點，將最終結果持久化到資料庫或顯示在 UI 上
Pipes and filters 的單向性與簡單性鼓勵組合式重用（compositional reuse）。著名的故事是 Donald Knuth 用 10 頁 Pascal 程式解決的文字處理問題，Doug McIlroy 用幾行 shell 命令就優雅地解決了。
Figure 11.1: Basic topology for pipeline architecture
Example（範例）#
Pipeline architecture 適用於多種場景，尤其是需要簡單、單向處理的任務：
- EDI（Electronic Data Interchange） 工具 — 在不同文件類型之間進行轉換
- ETL（Extract, Transform, Load） 工具 — 在資料庫或資料來源之間搬移與轉換資料
- Orchestrator / Mediator（如 Apache Camel）— 在業務流程的步驟之間傳遞資訊
Kafka streaming 範例：
- Service Info Capture（producer）— 訂閱 Kafka topic，接收服務遙測資訊
- Duration Filter（tester）— 判斷資料是否與 duration 相關，是則傳到 Duration Calculator，否則傳到 Uptime Filter
- Uptime Filter（tester）— 判斷資料是否與 uptime 相關
- Duration Calculator / Uptime Calculator（transformer）— 計算相應指標
- Database Output（consumer）— 將結果持久化至 MongoDB
此範例展示了 pipeline architecture 的可擴展性：可以輕鬆在 Uptime Filter 之後新增 tester filter 來處理新的指標類型。
Figure 11.2: Pipeline architecture example
Architecture Characteristics Ratings#
| Architecture Characteristic | Rating |
|---|---|
| Partitioning type | Technical |
| Number of quanta | 1 |
| Deployability | 2/5 |
| Elasticity | 1/5 |
| Evolutionary | 3/5 |
| Fault tolerance | 1/5 |
| Modularity | 3/5 |
| Overall cost | 5/5 |
| Performance | 2/5 |
| Reliability | 3/5 |
| Scalability | 1/5 |
| Simplicity | 5/5 |
| Testability | 3/5 |
主要優勢：Overall cost、Simplicity、Modularity
- 作為 monolithic 架構，不具備分散式架構的複雜度，建置成本低
- 透過 filter 類型的 separation of concerns 達到良好的架構模組性
- 任何 filter 都可以獨立修改或替換而不影響其他 filter
與 Layered Architecture 的比較：
- Deployability 和 Testability 略高於 layered architecture，因為 filter 的模組化程度較好
- Evolutionary（3/5） — filter 的獨立性使得演進較容易
- Elasticity / Scalability（1/5） — 與 layered architecture 相同，受限於 monolithic 部署
- Fault tolerance（1/5） — 同樣受限於 monolithic 部署，一個 out-of-memory 錯誤會影響整個應用
- Reliability（3/5） — 因為不涉及網路流量和延遲，可靠性中等
