盡管這本書并沒(méi)有詳細(xì)闡述微服務(wù)和單體架構(gòu)的方方面面，但它也提供了足夠多的信息 —— 甚至可以說(shuō)是全部信息 —— 幫助我們做出最好的，或者說(shuō)是最務(wù)實(shí)的決定，來(lái)構(gòu)建軟件。僅僅是目錄本身就值得稱贊！但是，即使過(guò)去了 25 年，這個(gè)行業(yè)似乎仍未領(lǐng)會(huì)到其最基本的教誨 —— 那就是，根據(jù)實(shí)際情況選擇合適的工具 。

另一個(gè)大名鼎鼎的人物，就是 Martin Fowler，他因遵循 “根據(jù)實(shí)際情況選擇合適的工具” 這一理念而嶄露頭角的。任何熟悉持續(xù)重構(gòu)這一概念的人，也很可能聽(tīng)過(guò) Martin Fowler 的名字。他甚至寫了一本專門講述這個(gè)主題的書。

但如果你不想讀或者買不起，這里有一個(gè)極簡(jiǎn)的版本：“始終保持重構(gòu)。如果你接觸到代碼，并且有能力改進(jìn)它，那就去改進(jìn)，但絕不提前優(yōu)化。 ” 這本書的精髓被濃縮為這句話。在這本書里，他不僅分享了他對(duì)重構(gòu)的見(jiàn)解，還討論了許多其他現(xiàn)代軟件開(kāi)發(fā)的主題，比如架構(gòu)，更具體地說(shuō)，單體架構(gòu)和微服務(wù)。

相反，從單體開(kāi)始，使它保持模塊化，一旦單體成為問(wèn)題時(shí)把它分解成微服務(wù)。

——martinfowler.com

在 2023 年初，React 的開(kāi)發(fā)人員和維護(hù)人員的行為讓開(kāi)發(fā)者們大吃一驚，現(xiàn)在又出現(xiàn)在了亞馬遜 Prime Video 的開(kāi)發(fā)者身上，最近他們發(fā)表了一篇文章，討論了從微服務(wù)轉(zhuǎn)向單體架構(gòu)的過(guò)程（如果你還沒(méi)讀過(guò)，為了理解背景，請(qǐng)閱讀）。這引發(fā)了很大的討論，因?yàn)榭紤]到亞馬遜還擁有 AWS，在其上建立的無(wú)服務(wù)器和微服務(wù)架構(gòu)遠(yuǎn)比我們都應(yīng)該接受的多 —— 但那是另一個(gè)故事了。

那么，到底發(fā)生什么事情了呢？好吧，想象一下。懸崖邊上的第一只羊跳了下去，然后其他羊都跟著跳了下去。但是后面的羊都沒(méi)注意到，第一只羊 —— 亞馬遜 —— 是穿著降落傘跳的。后面的羊都沒(méi)有注意到。不幸的是，這種情況并不少見(jiàn)，而這也是我多年來(lái)一直在反對(duì)的。

僅僅因?yàn)榇笮?a target="_blank">科技公司正在采用一些新的架構(gòu)、工具或庫(kù)，并不意味著它對(duì)每個(gè)人，包括推出它的那個(gè)公司，都是可行的。還記得谷歌的 Angular.js 嗎？就是這個(gè)道理……

亞馬遜 Prime Video 的故事與此非常非常相似。推動(dòng)了云服務(wù)發(fā)展的這家公司的部分部門，已經(jīng)意識(shí)到了 Martin Fowler 在 2014 年非常恰當(dāng)?shù)刂赋龅囊粋€(gè)事實(shí) —— 這種模式可能并不適用，而且還沒(méi)有足夠的證據(jù)來(lái)證明它會(huì)有效。當(dāng)然，這并不意味著亞馬遜就不應(yīng)該嘗試這種架構(gòu)，或者不應(yīng)該構(gòu)建支持這種架構(gòu)的 AWS 產(chǎn)品。Martin 本人也同意，這種嘗試是有價(jià)值的。但是，嘗試與采納是有很大差異的，在產(chǎn)生實(shí)際效果之前的盲目嘗試和盲目采納差異更大。

盡管對(duì)許多人來(lái)說(shuō)，亞馬遜開(kāi)發(fā)者決定放棄部分微服務(wù)，轉(zhuǎn)而選擇單體架構(gòu)的決定可能令人震驚，但這其實(shí)一點(diǎn)都不出人意料。微服務(wù)是否能成功的可能性一直是五五開(kāi)。

與那些永遠(yuǎn)看好未來(lái)、天真樂(lè)觀的人不一樣，軟件開(kāi)發(fā)并非非黑即白，無(wú)論它最終如何編譯成 0 和 1。這就是為什么我們需要回歸到由 Andrew Hunt 和 David Thomas 在《程序員修煉之道：從小工到專家》中闡述的基本原則，這是每一個(gè)緊隨亞馬遜步伐，一頭扎向同樣深淵的人都應(yīng)該做的。

亞馬遜 Prime Video 團(tuán)隊(duì)的決定并不應(yīng)被視為一種普遍的方案，盡管我確信會(huì)有許多人走進(jìn)辦公室，或者登錄 Slack，準(zhǔn)備召開(kāi)緊急的工程全員會(huì)議，提出一個(gè)計(jì)劃，要么恢復(fù)原狀，要么將他們的微服務(wù) “單體化”。我相信我不必須這么說(shuō)，但請(qǐng)你不要這樣做。如果你最終運(yùn)行的微服務(wù)是從解決實(shí)際問(wèn)題的單體架構(gòu)中剝離出來(lái)的，那么你顯然已經(jīng)做出了正確的選擇，推翻這個(gè)決定至少不會(huì)解決任何問(wèn)題。

另一方面，如果你從一開(kāi)始就由于像 “其他人都在這么做” 這樣的輕率理由而采用微服務(wù)，那么你可能需要坐下來(lái)對(duì)你的架構(gòu)進(jìn)行一次真正的成本效益分析，甚至可能需要與亞馬遜 Prime Video 的案例進(jìn)行對(duì)比。他們勇敢地承認(rèn)微服務(wù)是錯(cuò)誤的選擇，這至少表明這個(gè)決定并非出于市場(chǎng)炒作。你的分析結(jié)果可能會(huì)證明，采用單體架構(gòu)所解決的問(wèn)題少于其帶來(lái)的問(wèn)題和投入，在這種情況下，你應(yīng)當(dāng)堅(jiān)持你現(xiàn)有的選擇。

Martin Fowler 和我都贊同一個(gè)簡(jiǎn)單的事實(shí)，那就是

我們?cè)谟懻撨@個(gè)話題，對(duì)前端開(kāi)發(fā)也同樣適用。微前端是一種可能的解決復(fù)雜前端問(wèn)題的方案，但這并不一定意味著它是每個(gè)復(fù)雜前端的正確解決方案。

這篇文章就是要說(shuō)明，不要盲目追隨大型科技公司。務(wù)實(shí)的編程依然占主導(dǎo)地位，根據(jù)實(shí)際情況選擇合適的工具永遠(yuǎn)是最佳建議。