結論先講
先做免費午餐，1000 人以內不需要 K8s。 Redis cache + nginx keepalive + multi-worker 三個加起來提升 13 倍，成本幾乎為零。水平擴展到 2 台多 53%，但 4 台就卡在 DB 瓶頸。K8s 在小規模場景（<1000 用戶）反而比 Docker Compose 慢——它的價值在自動化運維，不在效能。大部分團隊需要的不是更複雜的架構，是更正確的配置。
數據總整理
免費午餐（改配置就有的效能提升）
| 優化 | 效果 | 成本 | 篇章 |
|---|---|---|---|
| nginx keepalive | +7% | 一行配置 | [[micro-service/21-infra-free-lunch|#21]] |
| Multi-worker（PM2/gunicorn） | +93% | 一行配置 | [[micro-service/21-infra-free-lunch|#21]] |
| Redis cache（讀多場景） | +650% | 加服務 + 幾行 code | [[micro-service/21-infra-free-lunch|#21]] |
| 三者組合 | +1300%（13 倍） | 半天工作量 | [[micro-service/21-infra-free-lunch|#21]] |
這三個是投資報酬率最高的基礎設施優化。特別是 multi-worker——很多 Node.js 專案跑在單核心上浪費了一半以上的 CPU。
水平擴展
| 配置 | 效果 | 瓶頸 | 篇章 |
|---|---|---|---|
| 1 台 → 2 台 | +53% | — | [[micro-service/22-infra-scaling-and-k8s|#22]] |
| 2 台 → 4 台 | 幾乎沒提升 | DB 連線數飽和 | [[micro-service/22-infra-scaling-and-k8s|#22]] |
| 4 台 + DB 讀寫分離 | 才恢復線性增長 | 成本翻倍 | [[micro-service/22-infra-scaling-and-k8s|#22]] |
關鍵發現：水平擴展不是線性的。加到 4 台 App Server 時，瓶頸從應用層轉移到 DB 層。如果不同時擴展 DB，加再多機器也沒用。這就是為什麼 [[micro-service/65-conclusion-db|#65 DB 結論]] 中的優化優先順序這麼重要——DB 的 pool 和 index 沒調好，擴展 App 是白花錢。
Docker Compose vs K8s
| 場景 | Docker Compose | K8s (k3s) | 篇章 |
|---|---|---|---|
| < 100 用戶 | 穩定 | 啟動慢、資源消耗大 | [[micro-service/41-docker-compose-vs-k8s|#41]] |
| 100-1000 用戶 | 穩定 | 開始有優勢（自動擴縮） | [[micro-service/41-docker-compose-vs-k8s|#41]] |
| > 1000 用戶 | 需要手動管理 | 自動化運維值回成本 | [[micro-service/41-docker-compose-vs-k8s|#41]] |
| 多團隊 / 多服務 | 難以管理 | namespace 隔離有用 | [[micro-service/42-docker-compose-production|#42]] |
K8s 的價值不是效能——它在小規模場景甚至更慢。它的價值是自動化運維：auto-scaling、rolling update、health check、資源限制。你在 1000 用戶以下不需要這些，docker compose up + nginx 就夠了。
其他發現
TLS 額外消耗 -5~7%，但這是必要成本——不要為了效能關 HTTPS。Protobuf vs JSON 快 +30%，但只在微服務間通訊有意義，對外 API 還是用 JSON（[[micro-service/42-docker-compose-production|#42]]）。
部署策略路線圖（按規模）
階段 1：單機部署（0-100 用戶）
[nginx] → [App (PM2 cluster)] → [PG]
- PM2 cluster 開滿 CPU 核心數
- nginx 開 keepalive + gzip
- PG 調好 pool size
- 這個階段不需要 Docker——直接跑就好
成本：一台 2C4G VPS（約 $10-20/月）
階段 2：Docker Compose + nginx LB（100-500 用戶）
[nginx LB] → [App×2 (Docker)] → [PG] + [Redis]
- 用 Docker Compose 管理所有服務
- nginx 做 load balancing
- 加 Redis cache（這時候讀取壓力開始大）
- PG 還是單一台，但 pool 要調到 50+
成本：一台 4C8G 或兩台 2C4G（約 $30-60/月）
階段 3：多節點部署（500-2000 用戶）
[nginx LB] → [App×2-4 (Docker)] → [PG + Replica] + [Redis] + [ES?]
- App Server 拆到 2-4 台獨立機器
- PG 加 Read Replica（這時候 DB 開始是瓶頸）
- 如果有搜尋需求，加 ES
- 開始需要 CI/CD pipeline 和監控（Grafana + Prometheus）
成本：$100-300/月
階段 4：K8s（2000+ 用戶）
[Ingress Controller] → [K8s Pods × auto] → [PG Cluster] + [Redis Cluster] + [ES] + [Kafka?]
- K8s 自動擴縮 Pod 數量
- PG 和 Redis 都需要叢集化
- 開始考慮服務拆分（微服務）
- 需要專職 SRE 或 DevOps
成本：$500+/月 + 人力
常見的錯誤決策
| 錯誤 | 後果 | 正確做法 |
|---|---|---|
| 10 個用戶就上 K8s | 運維成本 >> 業務價值 | Docker Compose 就夠 |
| 水平擴展 App 不擴展 DB | 4 台以上卡在 DB | 先調 DB pool + index |
| 不開 multi-worker | 浪費一半 CPU | PM2 cluster / gunicorn workers |
| nginx 沒開 keepalive | 白白浪費 7% 效能 | 一行配置搞定 |
| 為了效能關 TLS | 安全風險 >> 5% 效能 | TLS 是必要成本 |
| 微服務間全用 REST | JSON 序列化消耗大 | 內部通訊考慮 gRPC / Protobuf |
判斷你在哪個階段
| 信號 | 你該做什麼 |
|---|---|
| P95 回應時間 < 200ms | 什麼都不用做 |
| P95 200-500ms | 做免費午餐（Tier 1） |
| P95 500ms-1s | 加 Redis、確認 DB 配置 |
| P95 > 1s | 水平擴展、考慮讀寫分離 |
| 需要自動擴縮 / 零停機部署 | 上 K8s |
| 月流量 > 100 萬 PV | 認真考慮 K8s + 微服務 |
大部分的應用，一台調好配置的機器 + Redis，就能撐到 500 用戶毫無壓力。
詳細數據見：
- [[micro-service/21-infra-free-lunch|#21 免費午餐]]
- [[micro-service/22-infra-scaling-and-k8s|#22 水平擴展與 K8s]]
- [[micro-service/41-docker-compose-vs-k8s|#41 Docker Compose vs K8s]]
- [[micro-service/42-docker-compose-production|#42 K8s 實戰指南]]
下一篇
從零開始的全棧選型指南 — 五層結論都出來了，最後一篇把所有東西整合成「從零開始該怎麼選」。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：Storage 結論：什麼時候加什麼儲存服務 → 下一篇：從零開始的全棧選型指南：最佳組合是什麼