場景
你正在開發一個服務器端的企業應用程序。它必須支持多種不同的客戶端，包括桌面瀏覽器，移動瀏覽器和本地移動應用的。該應用程序還可能暴露於第三方消費的API。它也可能通過任何Web服務或一個消息代理其他應用程序的集成應用程序：處理通過執行業務邏輯請求（HTTP請求和消息）; 訪問數據庫; 交換與其它系統的消息; 並返回一個HTML / JSON / XML響應。它有對應於應用的不同功能區的邏輯組件。問題
什麼是應用程序的部署架構？要求
有一個應用的開發者團隊新的團隊成員必須迅速提高工作效率
該應用程序必須易於理解和修改
持續部署
必須以滿足可擴展性和可用性要求運行在多臺機器上的應用程序的多個副本
想利用新興技術的優勢（框架，編程語言等）
解決方案
建立一個單體架構的應用程序。例如：一個Java WAR文件。
一個單一的目錄層次結構：Rails或者NodeJS
實例
讓我們想象一下，你正在構建一個電子商務應用程序，有客戶的訂單，覈實庫存和可用信用等等。該應用程序由幾個部分組成，包括StoreFrontUI，它實現了用戶界面，帶有用於檢查信用，保持庫存和運輸訂單一些後端服務。
該應用程序部署爲一個單一的整體應用。例如，一個Java Web應用程序由一個web容器：如Tomcat運行單獨WAR文件。Rails應用程序被部署在單個目錄層次結構中，例如，乘客的Phusion部署在Tomcat的Apache / Nginx或JRuby上。您可以用負載均衡擴大規模的形式，運行多個應用實例，提高可用性。
這種場景的結果
首先，該解決方案有很多好處：開發簡單 - 現有的開發工具和IDE的目標是支持的單一應用程序開發
部署簡單 - 你只需要部署相應的運行時WAR文件（或目錄結構）
簡單的規模 - 您可以通過運行應用程序的多個副本擴展應用
然而，一旦應用程序變大和團隊變大，這種方法有許多缺點：大型單體代碼庫嚇跑新的團隊成員，該應用程序可能很難理解和修改。其結果是，開發通常會減慢。此外，因爲沒有清晰的模塊邊緣界定，隨着時間的推移，它可能很難明白如何正確地實施代碼變更。質量隨時間下降，這是一個向下的螺旋。
IDE負擔過重 - 大型的代碼庫使得IDE變得緩慢，影響了開發者的效率。
Web容器負擔過重 - 更大的應用程序需要更長的時間啓動。也因此，這極大的消耗了開發效率，因爲對於開發人員來說，他們不得不等待容器的啓動。
持續部署困難 - 一個大的整體應用也是一個頻繁部署的障礙。爲了更新一個組件，你必須重新部署整個應用程序。這將中斷後臺任務，先忽略他們是否會因爲變化，而產生新的問題。另外，組件更新失敗，將影響其應用的正常啓動。其結果是，隨着更新，風險增加，阻礙了頻繁的開發迭代。這通常是用戶界面開發者的問題，因爲他們通常需要快速迭代，並經常重新部署。
應用程序擴展困難 - 單體架構是，它可以在一個維中只有規模。在一方面，它可以通過運行應用程序的多個副本與增加交易量規模。有些雲服務，甚至可以動態調整負載實例的數量。但在另一方面，這種架構不能擴展數據量的規模。應用實例的每個副本將訪問數據，這使得緩存不太有效，並增加內存消耗和I / O的流量。另外，不同的應用程序組件具有不同的資源要求 - 一個可能是CPU，而另一個可能佔用大量內存密集型。在單體架構中，我們不能獨立地擴展每個組件
阻礙發展 - 一個整體的應用也是一個縮放發展的障礙。一旦應用程序需要形成一個專業團隊規模，例如，我們可能希望有UI團隊，財務團隊，庫存團隊等。單體應用系統的麻煩是，它防止團隊獨立工作。該團隊必須協調發展和調動，使得團隊變更和發展變得異常困難
需要一個長期穩定的技術棧 - 單體應用，可能很難能夠逐步採用更新的技術。例如，假設您選擇的JVM。你有一些語言的選擇界限，就算在Java中，你可以使用其他JVM語言：比如Groovy和Scala與java協同開發。但是，你沒有選擇非JVM語言的能力。另外，如果您的應用程序使用的平臺框架，隨後變得過時，那麼它非常具有挑戰性——將應用逐步遷移到新的和更好的框架。