結論先講
最佳化的順序比最佳化本身更重要。 Redis cache（+6.5 倍）的 ROI 是讀寫分離（+30%）的 20 倍，但很多人先做讀寫分離。Multi-worker（+93%）是改一行配置，但有人先去學 K8s。這篇把 61 篇文章的所有優化方案按 ROI 排序，告訴你「先做什麼、後做什麼、什麼不用做」。
五層結論總覽
F2E 前端
結論：差距只有 6 分，看生態不看效能。
| 發現 | 數據 | 篇章 |
|---|---|---|
| Lighthouse 分數差距極小 | 93~99 分 | [[micro-service/15-f2e-lighthouse-ranking|#15]] |
| Bundle size 才是真正差異 | Svelte 326KB vs Angular 784KB | [[micro-service/15-f2e-lighthouse-ranking|#15]] |
| Astro Islands 簡單頁面反而慢 | > 2.5 秒 LCP | [[micro-service/16-f2e-render-strategy|#16]] |
| SSR 增加 server 壓力 | CPU +30~50% | [[micro-service/16-f2e-render-strategy|#16]] |
行動：選你最熟的框架。React 是安全牌。不要為了 6 分換框架。
B2E 後端
結論：Go 最穩、Spring Boot 讀取最強、Express-TS 是安全牌。免費午餐比換框架效果大。
| 發現 | 數據 | 篇章 |
|---|---|---|
| bcrypt 是所有框架的共同天花板 | 9/9 框架觸發 | [[micro-service/06-bcrypt-bottleneck|#6]] |
| CRUD 和混合場景排名完全不同 | Spring Boot 8th→1st | [[micro-service/24-mixed-overview|#24]] |
| WS/SSE 所有框架都能撐 | 500 VU 零錯誤 | [[micro-service/26-websocket-sse|#26]] |
| Cold Start Go 最快 | 6.7s vs NestJS 30.3s | [[micro-service/27-queue-redis-coldstart|#27]] |
| 免費午餐組合提升 13 倍 | Redis+keepalive+worker | [[micro-service/21-infra-free-lunch|#21]] |
行動：先做免費午餐，撐不住再考慮換框架或拆微服務。
DB 資料庫
結論：PG 通用、MySQL 寫入強、「怎麼寫」比「用什麼 DB」影響更大。
| 發現 | 數據 | 篇章 |
|---|---|---|
| PG JSONB 比 MySQL JSON 快 | 3.2 倍 | [[micro-service/17-db-pg-vs-mysql|#17]] |
| MySQL 寫入密集場景快 | 2.5 倍 | [[micro-service/17-db-pg-vs-mysql|#17]] |
| Bulk Insert vs 逐筆 | 26 倍！ | [[micro-service/18-db-bulk-and-index|#18]] |
| ORM vs Raw SQL 差距小 | < 10% | [[micro-service/18-db-bulk-and-index|#18]] |
| Pool=50 vs Pool=5 高壓 | +70% | [[micro-service/19-db-pool-and-infra|#19]] |
| 讀寫分離效果不如 Redis | +30% vs +650% | [[micro-service/61-db-read-write-splitting|#61]] |
行動：用 PG、調 pool size、用 Bulk Insert。讀寫分離是最後手段。
Storage 儲存
結論：PG + Redis 夠用，需要時再加。
| 發現 | 數據 | 篇章 |
|---|---|---|
| Redis KV 最快 | 5,346 req/s | [[micro-service/20-storage-redis-es|#20]] |
| PG JSONB ≈ MongoDB | 只差 4% | [[micro-service/20-storage-redis-es|#20]] |
| ES 搜尋比 PG LIKE 快 | 2.6 倍 | [[micro-service/56-search-mysql-pg-elk|#56]] |
行動：起步用 PG。讀多加 Redis。搜尋量大加 ES。不要一次全裝。
Infra 架構
結論：免費午餐效果 > 換框架。1000 人以內不需要 K8s。
| 發現 | 數據 | 篇章 |
|---|---|---|
| Redis cache 讀多場景 | +6.5 倍 | [[micro-service/21-infra-free-lunch|#21]] |
| nginx keepalive | +7%（零成本） | [[micro-service/21-infra-free-lunch|#21]] |
| Multi-worker | +93% | [[micro-service/21-infra-free-lunch|#21]] |
| 水平擴展 2 台 | +53%（4 台卡 DB） | [[micro-service/22-infra-scaling-and-k8s|#22]] |
| k3s < Docker Compose | 100 人以上報錯 | [[micro-service/41-docker-compose-vs-k8s|#41]] |
行動：先做三個免費午餐，再考慮水平擴展，最後才上 K8s。
最佳化路線圖（按 ROI 排序）
Tier 1：零成本 / 改配置（先做完這些）
| 排序 | 優化 | 效果 | 成本 | 篇章 |
|---|---|---|---|---|
| 1 | nginx 開 keepalive | +7% | 一行配置 | [[micro-service/21-infra-free-lunch|#21]] |
| 2 | 開多 worker（PM2/gunicorn） | +93% | 一行配置 | [[micro-service/21-infra-free-lunch|#21]] |
| 3 | 調 DB connection pool | +70% | 一行配置 | [[micro-service/19-db-pool-and-infra|#19]] |
| 4 | 批次寫入改用 Bulk | +2600% | 改幾行 code | [[micro-service/18-db-bulk-and-index|#18]] |
| 5 | 檢查 DB Index | +300~500% | 加 migration | [[micro-service/18-db-bulk-and-index|#18]] |
Tier 1 合計效果：可能 5-10 倍提升，花不到一天。
Tier 2：低成本 / 加服務（Tier 1 做完才做）
| 排序 | 優化 | 效果 | 成本 | 篇章 |
|---|---|---|---|---|
| 6 | 加 Redis cache（讀多場景） | +650% | 加幾行 code + Redis 服務 | [[micro-service/33-cache-correct-usage|#33]] |
| 7 | 加 nginx 反向代理 | +7% + 安全性 | 加 nginx 配置 | [[micro-service/21-infra-free-lunch|#21]] |
| 8 | 降低 bcrypt rounds（內部系統） | +400% auth | 改一行 | [[micro-service/06-bcrypt-bottleneck|#6]] |
Tier 3：中成本 / 架構調整（Tier 2 撐不住才做）
| 排序 | 優化 | 效果 | 成本 | 篇章 |
|---|---|---|---|---|
| 9 | 水平擴展（2-4 台） | +53% | 多台機器 + LB | [[micro-service/22-infra-scaling-and-k8s|#22]] |
| 10 | DB 讀寫分離 | +30~50% | Replica + 路由邏輯 | [[micro-service/61-db-read-write-splitting|#61]] |
| 11 | 加 Elasticsearch（搜尋） | 搜尋 +260% | ES 叢集 + 資料同步 | [[micro-service/56-search-mysql-pg-elk|#56]] |
| 12 | 換 DB（PG → MySQL 寫入場景） | +250% 寫入 | 遷移成本高 | [[micro-service/32-pg-migration-guide|#32]] |
Tier 4：高成本 / 重構（確定需要才做）
| 排序 | 優化 | 效果 | 成本 | 篇章 |
|---|---|---|---|---|
| 13 | 拆微服務 | 看場景 | Event-Driven + 監控 + CI/CD | [[micro-service/39-when-to-split|#39]] |
| 14 | 換後端框架 | 4-5 倍（Django→Go） | 團隊學習 + 重寫 | [[micro-service/37-framework-selection-methodology|#37]] |
| 15 | 上 K8s | 自動化運維（不提升效能） | 學習 + 維護 | [[micro-service/41-docker-compose-vs-k8s|#41]] |
| 16 | 微服務間改 gRPC | +30%（Protobuf） | .proto 定義 + code gen | [[micro-service/58-communication-protocols|#58]] |
常見的錯誤順序
| 錯誤 | 正確做法 |
|---|---|
| DB 慢 → 先做讀寫分離 | DB 慢 → 先調 pool + 加 index + 加 Redis |
| 系統慢 → 換 Go | 系統慢 → 先做免費午餐（13 倍提升） |
| 要擴展 → 上 K8s | 要擴展 → 先 Docker Compose + nginx LB |
| 搜尋慢 → 上 Elasticsearch | 搜尋慢 → 先用 PG pg_trgm + GIN index |
| 要微服務 → 全部重寫 | 要微服務 → Strangler Fig 漸進式替換 |
| 前端慢 → 換 Svelte | 前端慢 → 先做 code splitting + lazy loading |
每一個「正確做法」的 ROI 都比「錯誤做法」高 5-20 倍，而且風險低得多。
一張圖看完
UV 10: 什麼都不用做，先跑壓測確認基線
↓
UV 50: Tier 1（keepalive + worker + pool + bulk + index）
↓
UV 100: Tier 2（Redis cache + nginx）
↓
UV 500: 還是 Tier 1+2，確認都做了
↓
UV 1000: Tier 3（水平擴展 2 台 + 讀寫分離考慮）
↓
UV 5000: Tier 4（微服務 + Go 核心路徑 + K8s）
大部分應用永遠停在 UV 100-500。Tier 1 + Tier 2 就能解決 90% 的效能問題。
這是整個系列的最終地圖
從 第 1 篇「功能測試回答能不能動，壓力測試回答能撐多少人」出發，到這裡你有了完整的答案：
- 能撐多少人 → 第 23 篇 容量規劃表
- 該先做什麼 → 本篇的 Tier 1-4 路線圖
- 每一層選什麼 → 五層結論總覽（本篇上半部）
- 具體怎麼做 → 61 篇各自的實作指南
完整目錄見 系列首頁
下一篇
F2E 結論：前端框架最終推薦 — 路線圖畫好了，接下來每一層各一篇結論，從前端開始。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：DB 讀寫分離：值不值得做？什麼時候做？ → 下一篇：F2E 結論：前端框架與渲染策略最終推薦