最近在做的事情正好需要系統(tǒng)地研究微服務(wù)與單體架構(gòu)的取舍與演進。讀到這篇文章，許多觀點直擊痛點、非常啟發(fā)，于是我順手把它翻譯出來，分享給大家，也希望能給同樣在復(fù)雜性與效率之間權(quán)衡的團隊一些參考。

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

為了把我們的創(chuàng)業(yè)產(chǎn)品擴展到數(shù)百萬用戶，我們搭建了 47 個微服務(wù)。

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

那一刻我才意識到：我們并沒有在構(gòu)建產(chǎn)品，而是在搭建一座分布式的自戀紀(jì)念碑。

我們都信過的謊言

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

于是我們照做了。我們把 Rails 單體拆成一個個服務(wù)：用戶服務(wù)、認證服務(wù)、支付服務(wù)、通知服務(wù)、分析服務(wù)、郵件服務(wù)；然后是子服務(wù)，再然后是調(diào)用服務(wù)的服務(wù)，層層套疊。

到第六個月，我們已經(jīng)在 12 個 GitHub 倉庫里維護 47 個服務(wù)。我們的部署流水線像一張地鐵圖，架構(gòu)圖需要 4K 顯示器才能看清。

當(dāng)“最佳實踐”變成“最差實踐”

我們不斷告誡自己：一切都在運轉(zhuǎn)。我們有 Kubernetes，有服務(wù)網(wǎng)格，有用 Jaeger 的分布式追蹤，有 ELK 的日志——我們很“現(xiàn)代”。

但那些光鮮的微服務(wù)文章從不提的一點是：分布式的隱性稅。

每一個新功能都變成跨團隊的協(xié)商。想給用戶資料加一個字段？那意味著要改五個服務(wù)、提三個 PR、協(xié)調(diào)兩周，并進行一次像劫案電影一樣精心編排的數(shù)據(jù)庫遷移。

我們的預(yù)發(fā)布環(huán)境成本甚至高于生產(chǎn)環(huán)境，因為想測試任何東西，都需要把一切都跑起來。47 個服務(wù)在 Docker Compose 里同時啟動，內(nèi)存被瘋狂吞噬。

那個徹夜崩潰的夜晚

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

生產(chǎn)環(huán)境宕了。不是某一個服務(wù)——是所有服務(wù)。支付服務(wù)連不上用戶服務(wù)，通知服務(wù)不斷超時，API 網(wǎng)關(guān)對每個請求都返回 503。

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

結(jié)果呢？一位初級開發(fā)在認證服務(wù)上發(fā)布了一個配置變更，只是一個環(huán)境變量。它讓令牌校驗多了 2 秒延遲，這個延遲在 11 個下游服務(wù)間層層傳遞，超時疊加、斷路器觸發(fā)、重試邏輯制造請求風(fēng)暴，整個系統(tǒng)在自身重量下轟然倒塌。

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

我們花了六個小時才修復(fù)。并不是因為 bug 復(fù)雜——它只是一個配置的單行改動，而是因為排查分布式系統(tǒng)就像破獲一樁謀殺案：每個目擊者說著不同的語言，而且有一半在撒謊。

那個被忽略的低語

一周后，在復(fù)盤會上，我們的 CTO 說了句讓所有人不自在的話：

“要不我們……回去？”

回到單體。回到一個倉庫?；氐胶唵巍?/p>

會議室一片沉默。你能感到認知失調(diào)。我們是工程師，我們很“高級”。單體是給傳統(tǒng)公司和訓(xùn)練營畢業(yè)生用的，不是給一家正打造未來的 A 輪初創(chuàng)公司用的。

但隨后有人把指標(biāo)展開：平均恢復(fù)時間 4.2 小時；部署頻率每周 2.3 次（從單體時代的每周 12 次一路下滑）；云成本增長速度比營收快 40%。

數(shù)字不會說謊。是架構(gòu)在拖垮我們。

美麗的回歸

我們用了三個月做整合。47 個服務(wù)歸并成一個模塊劃分清晰的 Rails 應(yīng)用；Kubernetes 變成負載均衡后面的三臺 EC2；12 個倉庫的工作流收斂成一個邊界明確的倉庫。

結(jié)果簡直讓人尷尬。

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

開發(fā)者不再說“我需要和三個團隊協(xié)調(diào)”，而是開始說“午飯前給你”。

我們的“分布式系統(tǒng)”變回了結(jié)構(gòu)良好的應(yīng)用。邊界上下文變成 Rails 引擎，服務(wù)調(diào)用變成方法調(diào)用，Kafka 變成后臺任務(wù)，“編排層”……就是 Rails 控制器。

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

我們真正學(xué)到的是什么

這是真相：我們?yōu)榇烁冻鰞赡陼r間和 40 萬美元才領(lǐng)悟——

微服務(wù)不是一種純粹的架構(gòu)模式，而是一種組織模式。Netflix 需要它，因為他們有 200 個團隊。你沒有。Uber 需要它，因為他們一天發(fā)布 4,000 次。你沒有。

復(fù)雜性之所以誘人，是因為它看起來像進步。 擁有 47 個服務(wù)、Kubernetes、服務(wù)網(wǎng)格和分布式追蹤，看起來很“專業(yè)”；而一個單體加一套 Postgres，看起來很“業(yè)余”。

但復(fù)雜性是一種稅。它以認知負擔(dān)、運營開銷、開發(fā)者幸福感和交付速度為代價。

而大多數(shù)初創(chuàng)公司根本付不起這筆稅。

我們花了兩年時間為并不存在的規(guī)模做優(yōu)化，同時犧牲了能讓我們真正達到規(guī)模的簡單性。

你不需要 50 個微服務(wù)，你需要的是自律

軟件架構(gòu)的“骯臟秘密”是：好的設(shè)計在任何規(guī)模都奏效。

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

微服務(wù)并不是因為“糟糕”而式微，而是因為我們出于錯誤的理由使用了它。我們選擇了分布式的復(fù)雜性而不是本地的自律，選擇了運營的負擔(dān)而不是價值的交付。

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

所以我想問一個問題：你構(gòu)建微服務(wù)，是在逃避什么？

如果答案是“一個凌亂的代碼庫”，那我有個壞消息——分布式系統(tǒng)不會修好壞代碼，它只會讓問題更難被發(fā)現(xiàn)。