結論先講
10 人和 5000 人需要的技術棧完全不同。 10 人什麼框架都行；50 人需要注意 DB 連線池；100 人 bcrypt 開始成為瓶頸；500 人需要 Redis cache；1000 人需要水平擴展；5000 人每一層都要專門設計。不要為了 10 人的產品去設計 5000 人的架構。
這一步怎麼來的：五層都測完了，每一層都有自己的數字。但讀者（包括我們自己）想要的是「我有 N 個用戶，每一層該選什麼」的一張表。這篇就是那張表。
容量規劃表
這張表是從平台 42 項壓測數據整合出來的。每一格的建議都有數據支撐，不是猜的。
10 人同時在線
| 層 | 建議 | 理由 |
|---|---|---|
| F2E | 任何框架，分數都 95+ | F2E 篇：差距只有 6 分 |
| B2E | 任何框架，30-80 req/s | CRUD 篇：10 VU 全部健康 |
| DB | PG 或 MySQL，ORM 直接用 | DB 篇：低壓下差距不大 |
| Storage | 不需要額外儲存 | DB 就夠了 |
| Infra | 直連就好 | 不需要反向代理 |
這個階段的建議：用你最熟的技術，不要過度設計。
50 人同時在線
| 層 | 建議 | 理由 |
|---|---|---|
| F2E | 任何框架，注意打包大小 | Svelte 326KB vs Angular 784KB |
| B2E | Express-TS 約 120 req/s 足夠 | Queue 非同步化幾乎零額外延遲 |
| DB | PG 略優，確認連線池 ≥ 10 | 連線池篇：pool=5 低壓夠用但要留餘量 |
| Storage | 讀多的話考慮 Redis cache | +25% on CRUD |
| Infra | 建議加 nginx（開 keepalive） | 免費午餐篇：+7% |
100 人同時在線
| 層 | 建議 | 理由 |
|---|---|---|
| F2E | React/Vue 為主，做 code splitting | Bundle size 開始影響體驗 |
| B2E | Express-TS + PM2 2 workers | bcrypt 開始成為瓶頸。批次上傳 Go/Express 可達 480+ RPS |
| DB | PG 推薦，加正確的 Index | Bulk 篇：正確 Index 快 3-5 倍 |
| Storage | 加 Redis 做讀取快取 | +25%（CRUD）到 +550%（讀多） |
| Infra | nginx + keepalive 必備 | 考慮開 rate limiting |
這是第一個轉折點——bcrypt 瓶頸出現。 回顧 Bcrypt 篇：在 2 核 CPU 上，bcrypt rounds=10 的理論上限只有 ~25 RPS。100 人同時做 Auth 就會打到天花板。
500 人同時在線
| 層 | 建議 | 理由 |
|---|---|---|
| F2E | 靜態資源上 CDN | 不要讓後端伺服器處理靜態檔案 |
| B2E | Go 或 Express-TS PM2 ×4 | P95 到 2-6s。WS/SSE 每連線約 50KB 記憶體 |
| DB | PG 連線池調到 20-50 | 連線池篇：pool=50 高壓下 +70% |
| Storage | Redis cache 必備 | 讀多場景 +6.5 倍 = 從不夠用變夠用 |
| Infra | PM2 cluster ×4 workers | 免費午餐篇：+93% |
500 人是大部分中型應用的目標。做完免費午餐三件套就能撐住。
1,000 人同時在線
| 層 | 建議 | 理由 |
|---|---|---|
| F2E | SSR 考慮伺服器端渲染 | 降低首屏時間 |
| B2E | Go 推薦 | Queue 9.5K RPS 全程零錯誤。Django/Laravel 需降 bcrypt rounds |
| DB | PG 連線池 50，監控慢查詢 | 開始出現 timeout 錯誤（15%） |
| Storage | Redis + 非同步佇列 | 寫入量大要用 Kafka 做事件緩衝 |
| Infra | 水平擴展 2+ 台 | 擴展篇：2 台 +53%。同時擴 DB 連線池！ |
1,000 人是第二個轉折點——單機不夠了。 但水平擴展前一定要先把單機優化做完（免費午餐），不然加機器也是浪費。
5,000+ 人同時在線
| 層 | 建議 | 理由 |
|---|---|---|
| F2E | CDN + 邊緣快取，考慮 SSG | 減少 server roundtrip |
| B2E | Go + 水平擴展 | WS 需 sticky session 或 Redis Pub/Sub 跨節點 |
| DB | 讀寫分離，PG 需要積極的 VACUUM | max_connections 要算清楚 |
| Storage | 全套：Redis + ES + Kafka | 各儲存做好監控 |
| Infra | 完整架構 | nginx 叢集 + 自動擴展 + 健康檢查 + graceful shutdown |
跨層洞察：5 條核心結論
從 42 項壓測中提煉出的跨層結論：
1. 硬體決定天花板
所有框架都在 2 CPU / 2 GB 下測試。Django 在 2 CPU 上 50 人就 break——不是 bug，是 gunicorn + bcrypt 的 CPU 密集架構在資源受限時的表現。給 4 CPU 就能撐 200 人。
不要看到「Django 50 人就掛了」就否定 Django。 先看你給它多少資源。
2. bcrypt 是共同 CPU 瓶頸
9 個後端框架的共同天花板。Go 用 goroutine 處理最高效，Node.js 用 native addon 也不差，Python 受影響最大。
遇到 bcrypt 瓶頸應該降低加密強度或加 Redis cache，不是換框架。（回顧 Bcrypt 篇）
3. 水平擴展必須同時擴 DB 連線
2 台提升 53%，4 台不更好。瓶頸轉移到 DB。每台 pool=5，4 台就是 20 個連線，不能超過 max_connections。
4. 免費午餐比換框架效果大
Redis cache +6.5 倍、nginx keepalive +7%、multi-worker +93%。三件事加起來比從 Django 換成 Go 的效果還大。
先優化架構，再考慮換框架。（回顧 免費午餐篇）
5. 選框架先問三個問題
- 團隊會什麼語言？
- 硬體預算多少 CPU？
- 需要什麼生態（Python ML / Java 企業 / JS 全端）？
效能排名只是參考。
這個系列到這裡的進度
到目前為止我們走過了：
| Part | 主題 | 篇數 | 核心結論 |
|---|---|---|---|
| 1 | 方法論 | 5 篇 | 怎麼做壓測 |
| 2 | Bcrypt | 3 篇 | 所有框架的共同天花板 |
| 3 | CRUD | 6 篇 | Go 最快但都卡在 bcrypt |
| 4 | F2E | 2 篇 | 差距 6 分，看生態不看分數 |
| 5 | DB | 3 篇 | PG 通用、MySQL 寫入、Bulk 26 倍 |
| 6 | Storage | 1 篇 | PG + Redis 夠用 |
| 7 | Infra | 2 篇 | 免費午餐 > 換框架 |
| 8 | 跨層 | 本篇 | 容量規劃表 |
接下來回到 B2E——混合場景、WS/SSE、Queue、Redis On/Off、Cold Start 的新數據，還有你的微服務實戰經驗。
下一篇
混合場景壓測：Spring Boot 從倒數第二變第一名 — 容量規劃表畫好了，接下來回到 B2E 看更多場景的壓測數據。混合場景把 Auth 從 40% 降到 10%，排名立刻大翻盤。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：水平擴展的天花板：2 台 +53%，4 台卡 DB → 下一篇：混合場景壓測：Spring Boot 從倒數第二變第一名