大多數應用程序（可能是其中的90％）採用了單體架構。爲了避免過度工程化，我們應該從一個簡單的架構開始，並根據需求進行演變。在Reactive Summit 2018大會上，Randy Shoup在演講中分享了他與小公司一起，逐步發展成爲大型全球性互聯網公司的經驗，以及它們的架構是如何進行演變的，並從IT專業的角度爲創辦新公司或推出新產品提出了一些建議。
Shoup曾在eBay、谷歌和Stitch Fix工作，目前是WeWork的工程副總裁。他例舉的第一個例子是eBay，從1995年開始，作爲一個爲期三天的週末項目，不是作爲業務的概念證明（PoC），而是爲了弄清楚是否有可能在網上做一些有趣的事情。今天，他們正在對基礎設施進行第5次完全重寫，Shoup將該公司的架構描述爲多語言微服務集，並補充說Twitter和亞馬遜都經歷了類似的演變。
Shoup認爲，從某種形式的單體架構開始，最後得到一組微服務，這是大公司的常見演變模式。Shoup還指出，這種模式包含了兩個部分——沒有人從一開始就採用微服務架構，而是達到一定規模後才走向微服務。
Shoup所提到的公司都非常龐大，他指出，這些公司的架構並不完全適用於大多數其他公司。大多數應用程序採用單體架構就足夠了，Shoup建議，在構建新應用程序或系統時先從簡單的架構開始，並根據需要改進架構。他說：
如果你到後面不後悔早期的技術決策，那麼你之前可能過度工程化了。
Shoup認爲，大多數公司和產品的常見演化曲線包括構思和啓動階段，分佈式系統可能還包含伸縮階段，以及優化階段：
在構思階段，我們不應該考慮架構問題，而只是進行原型設計。爲避免過度工程化，我們應該不斷問自己：“我們要解決什麼問題？”這個階段的目標是儘可能快地探索解決方案，並以最低成本：
- 找到商業模式；
- 找到契合的產品市場；
- 吸引我們的第一批客戶。
他建議我們，如果有可能，儘量避免使用任何技術，但可以使用谷歌廣告來驗證是否有用戶點擊，或使用原型或Excel電子表格。
進入啓動階段，目標變成了滿足近期的客戶需求，並儘可能以低成本來實現目標。在這個階段，團隊通常由4到6個人組成。他們的工作時間很短，可能只需要3到4個月，因爲在這個階段往往很難預先知道要構建哪些功能。我們只需要少量足以讓我們前進的架構。Shoup強調，它個階段不要考慮伸縮性問題，我們應該使用簡單而熟悉的技術，這絕對是一個單體架構——單個應用程序和單個數據庫。基礎設施應該儘可能小，而且不需要自己構建。相反，他建議使用平臺即服務（PaaS）或類似的技術。
在這個階段使用單體架構的優勢包括：
- 簡單；
- 速度快，因爲它只有進程內延遲；
- 你將獲得單個構建部署單元；
- 節省資源。
除了缺乏可伸縮性和存在單點故障之外，單體架構的主要缺點是缺乏模塊化能力。雖然可以進行模塊化，但它需要額外的編程和團隊紀律。Shoup指出，在這個階段，這些都不是問題。但他認爲，當我們需要爲擴展做準備時，單體架構的組件化或模塊化就變得有必要了。這將爲在未來修改或替換服務提供便利。
對於我們何時需要重構單體，Shoup列出了一些指標：
- 速度：由於耦合和缺乏隔離，導致交付速度減慢；
- 伸縮：垂直伸縮不再有效，或者系統的不同部分需要獨立伸縮；
- 部署：系統不同部分的演化速度不一樣，因此需要獨立部署。
在進入擴展階段時，我們的目標是保持業務的快速增長以及應用程序能夠正常運行。在組織方面，我們現在通常會增加團隊數量，並擴大工作時間範圍。通常還需要引入可重複的過程。
在技術方面，擴展階段通常意味着轉向可擴展的技術。通常，我們開始從單體中分離出服務，並且嘗試減少單個數據庫的負載，例如爲某些數據創建只讀副本。通常也會將一些服務（如支付和計費等特殊服務）分離出來，並引入事件隊列或消息總線。
Shoup認爲，這個時候通常也需要考慮我們是否應該將單體分解成小型的獨立組件，也就是微服務。我們還必須考慮現在使用的單個存儲器是否仍然合適。在紐約2017 QCon大會上，Shoup展示瞭如何將單體應用程序增量遷移爲微服務和幾個獨立的存儲。
“The Art of Scalability”一書描述了一種三維可伸縮性模型（AKF Scale Cube），其中三個軸分別代表了不同類型的縮放：
- X：水平復制和克隆；
- Y：功能分解和分割（微服務）；
- Z：水平數據分區（分片）。
最後一個是優化階段，Shoup強調，這個階段是成功的標誌。此時的目標是保留功能，使用更少的資源，可能會減少團隊。工作時間範圍更長，可能是2到5年。
Shoup總結說，在這種情況下，進行重構其實是一件好事：
重新構建系統是成功的標誌，而不是失敗。
業務發展得很好，你也有資源去做重構。這並不是說你一定要進行重構，而是你已經到了需要進行重構的時候。
查看英文原文：https://www.infoq.com/news/2019/01/rearchitecture-system-success