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

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

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

相反，從單體開始，使它保持模塊化，一旦單體成為問題時把它分解成微服務。

——martinfowler.com

在 2023 年初，React 的開發人員和維護人員的行為讓開發者們大吃一驚，現在又出現在了亞馬遜 Prime Video 的開發者身上，最近他們發表了一篇文章，討論了從微服務轉向單體架構的過程（如果你還沒讀過，為了理解背景，請閱讀）。這引發了很大的討論，因為考慮到亞馬遜還擁有 AWS，在其上建立的無服務器和微服務架構遠比我們都應該接受的多 —— 但那是另一個故事了。

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

僅僅因為大型科技公司正在采用一些新的架構、工具或庫，并不意味著它對每個人，包括推出它的那個公司，都是可行的。還記得谷歌的 Angular.js 嗎？就是這個道理……

亞馬遜 Prime Video 的故事與此非常非常相似。推動了云服務發展的這家公司的部分部門，已經意識到了 Martin Fowler 在 2014 年非常恰當地指出的一個事實 —— 這種模式可能并不適用，而且還沒有足夠的證據來證明它會有效。當然，這并不意味著亞馬遜就不應該嘗試這種架構，或者不應該構建支持這種架構的 AWS 產品。Martin 本人也同意，這種嘗試是有價值的。但是，嘗試與采納是有很大差異的，在產生實際效果之前的盲目嘗試和盲目采納差異更大。

盡管對許多人來說，亞馬遜開發者決定放棄部分微服務，轉而選擇單體架構的決定可能令人震驚，但這其實一點都不出人意料。微服務是否能成功的可能性一直是五五開。

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

亞馬遜 Prime Video 團隊的決定并不應被視為一種普遍的方案，盡管我確信會有許多人走進辦公室，或者登錄 Slack，準備召開緊急的工程全員會議，提出一個計劃，要么恢復原狀，要么將他們的微服務 “單體化”。我相信我不必須這么說，但請你不要這樣做。如果你最終運行的微服務是從解決實際問題的單體架構中剝離出來的，那么你顯然已經做出了正確的選擇，推翻這個決定至少不會解決任何問題。

另一方面，如果你從一開始就由于像 “其他人都在這么做” 這樣的輕率理由而采用微服務，那么你可能需要坐下來對你的架構進行一次真正的成本效益分析，甚至可能需要與亞馬遜 Prime Video 的案例進行對比。他們勇敢地承認微服務是錯誤的選擇，這至少表明這個決定并非出于市場炒作。你的分析結果可能會證明，采用單體架構所解決的問題少于其帶來的問題和投入，在這種情況下，你應當堅持你現有的選擇。

Martin Fowler 和我都贊同一個簡單的事實，那就是

我們在討論這個話題，對前端開發也同樣適用。微前端是一種可能的解決復雜前端問題的方案，但這并不一定意味著它是每個復雜前端的正確解決方案。

這篇文章就是要說明，不要盲目追隨大型科技公司。務實的編程依然占主導地位，根據實際情況選擇合適的工具永遠是最佳建議。