場景描述
假設你正在開發一個大型服務端企業應用，有如下需求：
- 必須支持多種客戶端，包括：WEB 端瀏覽器、WAP 端瀏覽器以及原生移動 APP。
- 對外暴露公共 API 用於調用
- 處理 HTTP 請求，或者消息，執行對應的業務邏輯。
- 訪問數據庫，緩存或者持久化響應的數據
- 與其他系統進行通信，交換所需的信息
- 返回 HTTP 響應，指定好特定的序列化方式，例如 JSON、 XML 等等
- 根據業務邏輯與功能，設計並劃分出不同邏輯模塊
這樣的一個應用，你會如何設計架構並部署呢？
考慮因素
- 這是一個團隊開發的項目，有一個獨立團隊負責
- 團隊成員會發生變化，新加入的成員必須快速上手項目
- 應用程序必須易於理解並修改
- 期望能實現應用的持續集成與部署
- 必須可以多實例部署應用程序，以滿足可伸縮性和可用性要求。
- 想用比較新的技術（框架、編程語言等）
解決方案
使用單體架構，例如：
- 一個 Java WAR 文件啓動的程序
- 一個單目錄 Rails 或者 NodeJS 程序
舉例
假設現在正在設計一個電商應用，功能包括接收來自客戶的訂單（StoreFrontUI），驗證並維護庫存餘額（Inventory Service），驗證並維護用戶可用餘額（Accounting Service），下單成功併發貨（Shipping Service）。這個應用被設計成一個單體架構應用，例如：JavaWeb 應用程序由運行在Web容器(如 Tomcat )上的單個 WAR 文件組成。Rails 應用程序由部署在 Nginx 或 Tomcat 上的 JRuby 或 Nginx 上的單一目錄層次結構組成。可以在負載均衡器後面部署多個實例，以擴展和提高可用性。
分析
這種解決方案的好處有：
- 開發簡單，當前的 IDE 基本都是按照開發單體應用程序開發的。
- 部署簡單，只要把一個文件或者目錄部署到 Web 容器裏即可。
- 擴容簡單，通過在負載均衡器後面部署多個實例就能實現擴容。
但是，隨着產品不斷迭代，這個單體應用程序將會變得越來越大，團隊的規模也越來越大，這種單體設計就會有一些缺點，並且這些缺點會變得越來越嚴重：
- 單體應用代碼在同一個代碼庫，這個代碼庫會越來越大，使開發人員感覺會很頭大，特別是那些剛加入團隊的開發人員。應用程序將很難理解和修改，因此，開發速度通常會被減緩。另外，由於沒有明確的模塊邊界，代碼內部的模塊化會隨着時間的推移而越來越模糊。此外，由於很難理解如何正確實現更改，並且可能還需要兼容老版本的錯誤，因此代碼的質量會隨着時間的推移而下降，慢慢堆積成爲屎山。
- IDE 的壓力會很大。代碼庫越大，IDE 會更慢，IDE 一般爲了智能補全代碼的功能，會對代碼做索引並加載到內存中。臃腫的代碼會拖慢 IDE，降低開發效率。
- Web 容器壓力變大。程序越臃腫，啓動時間會被拖長，導致代碼調試變慢，同時部署時間也會變長。
- 持續集成部署難度越來越大。爲了更新一個組件，您必須重新部署整個應用程序。這會導致所有業務，不管是否有更新，都被影響或者中斷。同時，如果出現問題，回滾時間也會增長。因此，這限制了程序不能持續頻繁更新。
- 不能靈活擴展。不同業務模塊可能壓力不同，以及壓力大的時間段可能也不同，但是每次擴容，都需要所有模塊一塊擴容，造成了浪費。
- 故障擴散。如果有一個模塊出了問題導致內存泄漏，那麼整個業務都會受到影響。
- 團隊分工的障礙。例如，我們可能希望有UI團隊、會計團隊、庫存團隊等等。單塊應用程序的問題在於它阻止了團隊獨立工作。小組必須協調他們的開發工作和重新部署。對於一個團隊來說，進行更改和更新生產要困難得多。
- 需要長期使用同一個技術棧。一種單一的體系結構迫使您與您在開發開始時所選擇的技術堆棧(在某些情況下，與該技術的特定版本)結合在一起。有了單體應用程序，就很難逐步採用一種較新的技術。比如你使用的框架停止更新，或者過時了，在單體應用下很難逐步採用一個新的框架實現。