昨天聊了 Stream Processing Engine 的演進，今天來談談一個有趣現象：為什麼遇到即時處理需求時，有可能會想到使用 HTTP？

HTTP：工程師的萬能工具

產品經理興沖沖地說：「我們需要一個即時訂單統計系統！」

工程師的第一直覺通常是：
「簡單！有新訂單就 POST 到統計服務，統計完再回應成功，搞定！」

為什麼會這樣想？ 因為 HTTP 對工程師來說就像瑞士刀一樣萬能：

• 熟悉度滿分：前端後端都在用，閉著眼睛都會寫
• 工具支援完善：Postman、curl、Swagger，要啥有啥
• 學習成本近乎為零：比學 Kafka 簡單一千倍
• Debug 超簡單：一個 curl 指令就能測試

這就形成了典型的同步模型

讓我們來看看這個「HTTP」方案

1. 同步系統架構

• 商店後端（Producer）：有新訂單就 POST 到統計服務
• 統計服務（Server）：收到請求 → 更新記憶體計數 → 回應成功
• 報表頁面（Consumer）：每隔幾秒 GET /stats 拿最新數據

流程圖：
商店系統  --同步HTTP-->  統計服務  <--同步HTTP--  報表頁面

看起來很完美對吧？每個工程師都能 5 分鐘寫出來，而且完全不需要學什麼新技術。

但是...

2. 當流量起來時，問題就浮現了

HTTP 同步模型在低流量時確實沒問題，簡單有效。但當系統需要處理更大規模時：

(1) 耦合度高

商店系統必須等統計服務處理完才算完成訂單流程。統計服務處理慢了，整個訂單 API 都會跟著變慢。

(2) 尖峰流量挑戰

高峰期來 10 萬筆訂單時，統計服務需要同時處理 10 萬個 HTTP 請求，容易成為瓶頸。

(3) 容錯性考驗

網路抖動或服務重啟時，可能會遺失部分統計資料，需要額外的重試和補償機制。

3. 為什麼要改成非同步模型？

同步模型的根本問題在於：傳送與處理被綁死在同一時間點。

任何一端變慢，另一端也會受影響，就像兩個人用鎖鏈綁在一起跑步。

更好的做法是引入中間層（消息隊列 / 事件流平台）：

• 商店後端：只需要把新訂單「丟進事件流」，不用等統計處理完成
• 統計服務：從事件流中取資料，按照自己的速度處理

非同步模型的三大好處：

• 抗壓：尖峰時先把資料放進隊列，慢慢消化
• 解耦：商店系統與統計服務互不影響
• 容錯：事件流本身可做持久化，服務掛了重啟後還能補資料

總結

HTTP 同步模型是個很好的起點，在小規模系統中非常實用。但隨著流量增長，同步處理的本質會帶來耦合度和擴展性的挑戰。

這時候就需要考慮非同步事件驅動的架構，透過中間層來解耦生產者和消費者，讓系統更有彈性。

下一篇我們將深入探討經典的 Lambda 架構，看看它如何優雅地解決這些問題，同時保證既快又準！