最近在做的事情正好需要系統地研究微服務與單體架構的取捨與演進。讀到這篇文章，許多觀點直擊痛點、非常啓發，於是我順手把它翻譯出來，分享給大家，也希望能給同樣在複雜性與效率之間權衡的團隊一些參考。

微服務正在悄然消亡：這是一件美好的事

為了把我們的創業產品擴展到數百萬用户，我們搭建了 47 個微服務。

用户從未達到一百萬，但我們達到了每月 23,000 美元的 AWS 賬單、長達 14 小時的故障，以及一個再也無法高效交付新功能的團隊。

那一刻我才意識到：我們並沒有在構建產品，而是在搭建一座分佈式的自戀紀念碑。

我們都信過的謊言

五年前，微服務幾乎是教條。Netflix 用它，Uber 用它。每一場技術大會、每一篇 Medium 文章、每一位資深架構師都在高喊同一句話：單體不具備可擴展性，微服務才是答案。

於是我們照做了。我們把 Rails 單體拆成一個個服務：用户服務、認證服務、支付服務、通知服務、分析服務、郵件服務；然後是子服務，再然後是調用服務的服務，層層套疊。

到第六個月，我們已經在 12 個 GitHub 倉庫裏維護 47 個服務。我們的部署流水線像一張地鐵圖，架構圖需要 4K 顯示器才能看清。

當“最佳實踐”變成“最差實踐”

我們不斷告誡自己：一切都在運轉。我們有 Kubernetes，有服務網格，有用 Jaeger 的分佈式追蹤，有 ELK 的日誌——我們很“現代”。

但那些光鮮的微服務文章從不提的一點是：分佈式的隱性税。

每一個新功能都變成跨團隊的協商。想給用户資料加一個字段？那意味着要改五個服務、提三個 PR、協調兩週，並進行一次像劫案電影一樣精心編排的數據庫遷移。

我們的預發佈環境成本甚至高於生產環境，因為想測試任何東西，都需要把一切都跑起來。47 個服務在 Docker Compose 裏同時啓動，內存被瘋狂吞噬。

那個徹夜崩潰的夜晚

凌晨 2:47，Slack 被消息炸翻。

生產環境宕了。不是某一個服務——是所有服務。支付服務連不上用户服務，通知服務不斷超時，API 網關對每個請求都返回 503。

我打開分佈式追蹤面板：一萬五千個 span，全線飄紅。瀑布圖像抽象藝術。我花了 40 分鐘才定位出故障起點。

結果呢？一位初級開發在認證服務上發佈了一個配置變更，只是一個環境變量。它讓令牌校驗多了 2 秒延遲，這個延遲在 11 個下游服務間層層傳遞，超時疊加、斷路器觸發、重試邏輯製造請求風暴，整個系統在自身重量下轟然倒塌。

我們搭了一座紙牌屋，卻稱之為“容錯架構”。

我們花了六個小時才修復。並不是因為 bug 複雜——它只是一個配置的單行改動，而是因為排查分佈式系統就像破獲一樁謀殺案：每個目擊者説着不同的語言，而且有一半在撒謊。

那個被忽略的低語

一週後，在覆盤會上，我們的 CTO 説了句讓所有人不自在的話：

“要不我們……回去？”

回到單體。回到一個倉庫。回到簡單。

會議室一片沉默。你能感到認知失調。我們是工程師，我們很“高級”。單體是給傳統公司和訓練營畢業生用的，不是給一家正打造未來的 A 輪初創公司用的。

但隨後有人把指標展開：平均恢復時間 4.2 小時；部署頻率每週 2.3 次（從單體時代的每週 12 次一路下滑）；雲成本增長速度比營收快 40%。

數字不會説謊。是架構在拖垮我們。

美麗的迴歸

我們用了三個月做整合。47 個服務歸併成一個模塊劃分清晰的 Rails 應用；Kubernetes 變成負載均衡後面的三台 EC2；12 個倉庫的工作流收斂成一個邊界明確的倉庫。

結果簡直讓人尷尬。

部署時間從 25 分鐘降到 90 秒；AWS 賬單從 23,000 美元降到 3,800 美元；P95 延遲提升了 60%，因為我們消除了 80% 的網絡調用。更重要的是——我們又開始按時交付功能了。

開發者不再説“我需要和三個團隊協調”，而是開始説“午飯前給你”。

我們的“分佈式系統”變回了結構良好的應用。邊界上下文變成 Rails 引擎，服務調用變成方法調用，Kafka 變成後台任務，“編排層”……就是 Rails 控制器。

它更快，它更省，它更好。

我們真正學到的是什麼

這是真相：我們為此付出兩年時間和 40 萬美元才領悟——

微服務不是一種純粹的架構模式，而是一種組織模式。Netflix 需要它，因為他們有 200 個團隊。你沒有。Uber 需要它，因為他們一天發佈 4,000 次。你沒有。

複雜性之所以誘人，是因為它看起來像進步。 擁有 47 個服務、Kubernetes、服務網格和分佈式追蹤，看起來很“專業”；而一個單體加一套 Postgres，看起來很“業餘”。

但複雜性是一種税。它以認知負擔、運營開銷、開發者幸福感和交付速度為代價。

而大多數初創公司根本付不起這筆税。

我們花了兩年時間為並不存在的規模做優化，同時犧牲了能讓我們真正達到規模的簡單性。

你不需要 50 個微服務，你需要的是自律

軟件架構的“骯髒秘密”是：好的設計在任何規模都奏效。

一個結構良好的單體，擁有清晰的模塊、明確的邊界上下文和合理的關注點分離，比一團由希望和 YAML 勉強粘合在一起的微服務亂麻走得更遠。

微服務並不是因為“糟糕”而式微，而是因為我們出於錯誤的理由使用了它。我們選擇了分佈式的複雜性而不是本地的自律，選擇了運營的負擔而不是價值的交付。

那些悄悄迴歸單體的公司並非承認失敗，而是在承認更難的事實：我們一直在解決錯誤的問題。

所以我想問一個問題：你構建微服務，是在逃避什麼？

如果答案是“一個凌亂的代碼庫”，那我有個壞消息——分佈式系統不會修好壞代碼，它只會讓問題更難被發現。