加密貨幣交易所
從 0 構建並部署高併發加密貨幣交易所的演進式架構，學習 AWS ECS、Redis 快取、Kafka 非同步處理與效能壓測。
專案概述
這是一個以壓力測試數據驅動架構演進的後端專案，旨在從 0 構建學習分散式架構與 AWS 部署運維。透過 k6 不斷將系統推向瓶頸，找出效能弱點，並依序引入單體容器化 (ECS)、快取層 (Redis)、水平擴展 (ALB)、非同步架構 (Kafka) 與完整的可觀測性堆疊 (Prometheus/Grafana/CloudWatch)。
技術挑戰與解決方案
單體資料庫連線池與讀取熱點瓶頸
當併發到達 100 VU 時，GET /orderbook 佔據 70% 的流量，每次皆直接叩擊 DB，導致 CPU 飆高且 P95 延遲暴增，最終出現 too many clients 錯誤。
單機資源飽和與 WebSocket 全域廣播問題
隨著流量上升，單一 ECS 任務的 CPU 使用率超過 70%。需要引入 ALB 進行水平擴展（多個機器實例），但水平擴展會破壞原本 in-memory 的 WebSocket 黏性連線。
寫入瓶頸與峰值流量削峰
下單 QPS 暴增時，同步回傳處理導致交易引擎與 DB 的寫入速度成為無法立即擴展的瓶頸（系統阻塞）。
系統架構
API 伺服器使用 Go (Gin) 實作並以 Docker 容器化，部署於 AWS ECS。針對不同階段的瓶頸，使用 PostgreSQL 儲存核心狀態，Redis 作為 Orderbook 的讀取快取 (Cache-Aside Pattern) 以及支援 WebSocket 廣播，Kafka 用作削峰填谷以非同步處理下單請求，並整合 Prometheus / Grafana 以及 CloudWatch 來提供完整的請求追蹤與即時監控指標。
學習與心得
此專案讓我深刻體會到「沒有絕對正確的架構，只有符合當下數據與瓶頸的架構」。透過 k6 實際看見延遲從 50ms 飆升到 1500ms 的崩潰點，然後看著引入 Redis Cache 後降回 10ms，這種由數據引導重構的過程非常有成就感。這也為我奠定了未來規劃高併發微服務架構時，根據流量與數據做出決策的工程直覺。