微服務之旅

這個系列不是規劃出來的，是走出來的。

起點很單純——我們的單體電商（FastAPI）在 UV 10 就報錯，想搞清楚「到底能撐多少人」。於是蓋了一個壓測平台，拿 9 個後端框架在相同條件下比較。

結果越測越多。後端測完想知道前端差多少，前端測完想知道 DB 怎麼選，DB 選完想知道要不要加 Redis，加了 Redis 想知道架構怎麼配。一個「簡單的壓測」變成了涵蓋前端、後端、資料庫、儲存、架構五層的完整技術選型。

最後回到起點的問題：到底該不該拆微服務？答案是「遲早要拆，但不要急」。大部分效能問題不是框架不好，而是配置沒做對——Redis cache + nginx keepalive + multi-worker，三個零成本改動的效果比換框架還大。

68 篇文章，42 項壓測數據。這是一個工程師從「單體撐不住了怎麼辦」走到「原來每一層都有學問」的完整紀錄。

主系列（01-30）

一步一步走完壓測的過程。每一步都是因為上一步的發現才走到這裡。

Part 1 — 方法論 「UV 10 就報錯，但不知道瓶頸在哪——得先有個能重複測試的環境。」

Part 2 — Bcrypt 專題 「9 個框架壓測完，發現全部卡在同一個地方——為什麼？」

Part 3 — B2E 後端框架壓測 「知道 bcrypt 是共同天花板之後，框架之間的差異到底有多大？不同場景排名會不會不同？」

Part 4 — F2E 前端框架 「後端的差距可以到 20 倍。那前端呢？值不值得為了效能換框架？」

Part 5 — DB 資料庫層 「bcrypt 之外，DB 查詢是第二大瓶頸。PG 和 MySQL 差多少？ORM 真的慢嗎？」

Part 6 — Storage 儲存層 「DB 選好了，那 Redis、Elasticsearch、MongoDB 這些什麼時候該加？」

每種儲存的甜蜜點

Part 7 — Infra 架構模式 「框架和 DB 都選了，不改程式碼只改配置能提升多少？」

Part 8 — 跨層總結 「五層都測完了，從 10 人到 5000 人，每一層該選什麼？」

跨層容量規劃

Part 9 — 微服務經驗 「數據都有了，回到最初的問題——到底該不該拆微服務？」

延伸系列（31-61）

主系列回答了「選什麼」。延伸系列回答「怎麼做」——每個主題都是從主系列的某個發現延伸出來的。

資料庫深入

「壓測說 PG 通用、MySQL 寫入強——但具體怎麼選、怎麼遷移、讀寫分離值不值得？」

Cache 策略

「Redis cache +6.5 倍——但加錯地方沒效果，invalidation 做錯會出 bug。」

搜尋與推薦

「ES 比 PG LIKE 快 2.6 倍——但從 LIKE 到 ES 中間還有 PG FTS，不一定要直接跳。」

併發控制

「搶購場景兩個人同時買最後一件——單體用 DB 鎖就好，微服務怎麼辦？」

微服務通訊

「拆成微服務之後，服務之間怎麼講話？REST 夠嗎？什麼時候上 gRPC？」

資料一致性

「微服務拆了之後不能跨服務做 transaction——Saga Pattern 和 Eventual Consistency 怎麼選？」

框架選型

「壓測數據只佔選型的 25%——團隊能力、硬體預算、生態需求怎麼一起考慮？」

微服務拆分

「決定要拆了——什麼 UV 該拆？怎麼拆才不會 big bang 失敗？」

部署與容器

「微服務拆好了，怎麼部署？K8s 還是 Docker Compose？怎麼做到 zero downtime？」

可觀測性

「微服務上線了，一個 request 跨三個服務——出問題怎麼追？」

安全

「服務之間需要驗證嗎？API Gateway 該做什麼安全措施？」

開發者體驗

「微服務讓部署變好了，但本地開發變痛苦了——5 個服務吃掉所有 RAM。」

成本

「效能優化不是免費的——每個 request 多少錢？什麼優化的 ROI 最高？」

總結篇（62-68）

「走完整段旅程，把所有數據整合成一張地圖——該先做什麼、後做什麼、什麼不用做。」

微服務之旅：從「該不該拆」到「每一層該怎麼選」