高併發 SaaS 服務怎麼部署？Docker 容器化與微服務架構實戰

在建置一個如 Flozium 這樣需要處理大量影音轉檔、無損壓縮的 SaaS 平台時，開發者面臨的最大挑戰往往不是「如何寫出轉檔程式」，而是「如何確保當 100 個使用者同時上傳 4K 影片時，伺服器不會崩潰」。

傳統的單體式架構 (Monolithic Architecture) 將網頁前端、資料庫、處理引擎全部塞在同一台主機裡。這在專案初期或許方便，但一旦流量突增，整個系統就會像塞車的高速公路一樣完全停擺。

為了解決這個痛點，現代 SaaS 平台必須擁抱「容器化 (Containerization)」與「微服務 (Microservices)」。這篇文章將分享我們如何利用 Docker 建構高可用的服務架構。

什麼是 Docker？為什麼 SaaS 不能沒有它？

如果你曾經在本地電腦上跑得好好的程式，部署到雲端伺服器卻出現一堆 Missing Library 或是 Version Conflict 的錯誤，你就會明白 Docker 的偉大之處。

Docker 允許開發者將應用程式及其所有的依賴套件（如特定版本的 Python、FFmpeg、系統字型）打包成一個標準化的「容器 (Container)」。 * 一致性： 無論是在你的筆電、測試環境，還是 AWS 生產伺服器上，容器跑起來的結果完全一致。 * 隔離性： 一個容器崩潰了，不會影響到同主機上的其他容器。

微服務架構實戰：拆解 Flozium 的處理流程

以我們的雲端媒體處理平台為例，我們不會讓「接收檔案的網頁伺服器」同時去處理「極耗 CPU 的影片轉碼」。我們將系統拆分為獨立的微服務：

1. API 網關 (API Gateway) 與前端容器

這是面對使用者的第一線。我們使用輕量級的 Nginx 搭配 Node.js 或 Flask 容器，只負責接收使用者的請求、驗證 JWT Token 與上傳檔案，並將處理任務寫入「訊息佇列 (Message Queue)」。它非常輕巧，即使同時湧入上千個請求也能快速回應。

2. 訊息佇列 (Message Queue) 核心

這是在高併發環境下不漏接任務的關鍵。我們常使用 Redis 或 RabbitMQ 容器。當 API 網關收到 100 個轉檔請求時，它不會立刻開始轉檔，而是把任務排進佇列中。

3. Worker 節點 (運算工作節點)

這才是真正幹活的地方。我們設計了專門處理 FFmpeg 轉碼的 Worker 容器。 * 彈性擴展 (Auto-scaling)： 這是微服務最強大的地方。當訊息佇列裡的任務積壓過多時，我們可以透過 Kubernetes 或 Docker Swarm，自動在雲端開啟更多台裝有 Worker 容器的虛擬機來並行處理。當任務消化完畢，再自動關閉這些機器以節省成本。

部署實例：Docker Compose

對於中小型專案，使用 docker-compose.yml 就能輕鬆啟動整套服務： ```yaml version: '3.8' services: web_api: build: ./api ports: - "80:8000" depends_on: - redis_queue

redis_queue: image: redis:alpine

media_worker: build: ./worker deploy: replicas: 3 # 啟動 3 個轉檔 Worker 同時運作 depends_on: - redis_queue