架構模式：單體架構
上下文
您正在開發服務器端企業應用程序。它必須支持各種不同的客戶端，包括桌面瀏覽器，移動瀏覽器和本機移動應用程序。該應用程序還可能會公開供第三方使用的API。它還可以通過Web服務或消息代理與其他應用程序集成。應用程序通過執行業務邏輯來處理請求（HTTP請求和消息）;訪問數據庫;與其他系統交換消息;並返回HTML / JSON / XML響應。存在與應用程序的不同功能區域相對應的邏輯組件。
問題
應用程序的部署架構是什么？
關注點
- 有一組開發人員在開發應用程序
- 新團隊成員必須快速提高工作效率
- 應用程序必須易於理解和修改
- 您希望實踐應用程序的持續部署
- 您必須在多台計算機上運行多個應用程序實例才能滿足可伸縮性和可用性要求
- 您希望利用新興技術（框架，編程語言等）
結論
使用單片架構構建應用程序。例如：
- 單個Java WAR文件。
- Rails或NodeJS代碼的單個目錄層次結構
例子
讓我們假設您正在構建一個電子商務應用程序，該應用程序接收來自客戶的訂單，驗證庫存和可用信用，並運送它們。該應用程序包含幾個組件，包括實現用戶界面的StoreFrontUI，以及用於檢查信用，維護庫存和裝運訂單的一些后端服務。
該應用程序部署為單個整體應用程序。例如，Java Web應用程序由單個WAR文件組成，該文件在Web容器（如Tomcat）上運行。Rails應用程序包含使用例如Apache / Nginx上的Phusion Passenger或Tomcat上的JRuby部署的單個目錄層次結構。您可以在負載均衡器后面運行應用程序的多個實例，以便擴展和提高可用性。
結果
該解決方案具有許多優點：
- 易於開發 - 當前開發工具和IDE的目標是支持單片應用程序的開發
- 易於部署 - 您只需在適當的運行時上部署WAR文件（或目錄層次結構）
- 易於擴展 - 您可以通過在負載均衡器后面運行應用程序的多個副本來擴展應用程序
但是，一旦應用程序變得龐大並且團隊規模不斷擴大，這種方法就會有許多缺點，這些缺點變得越來越重要：
-
龐大的整體代碼庫威脅開發人員，尤其是那些不熟悉團隊的人。應用程序可能難以理解和修改。因此，開發通常會放慢速度。此外，由於沒有硬模塊邊界，模塊化隨着時間的推移而崩潰。此外，由於可能難以理解如何正確實現更改，因此代碼質量會隨着時間的推移而下降。這是一個向下螺旋。
-
IDE重載 - 代碼庫越大，IDE越慢，開發人員的工作效率越低。
-
Web容器重載 - 應用程序越大啟動時間越長。由於浪費時間等待容器啟動，這對開發人員的工作效率產生了巨大影響。它也會影響部署。
-
持續部署很困難 - 大型單片應用程序也是頻繁部署的障礙。要更新一個組件，您必須重新部署整個應用程序。這將中斷后台任務（例如Java應用程序中的Quartz作業），無論它們是否受到更改的影響，並可能導致問題。還有可能未更新的組件無法正確啟動。結果，與重新部署相關的風險增加，這阻礙了頻繁的更新。這對於用戶界面開發人員來說尤其是一個問題，因為他們通常需要快速迭代並經常重新部署。
-
擴展應用程序可能很困難 - 單片架構只能在一個維度上擴展。一方面，它可以通過運行更多應用程序副本來增加事務量。有些雲甚至可以根據負載動態調整實例數。但另一方面，這種架構無法隨着數據量的增加而擴展。每個應用程序實例副本都將訪問所有數據，這使緩存效率降低，並增加內存消耗和I / O流量。此外，不同的應用程序組件具有不同的資源要求 - 一個可能是CPU密集型而另一個可能是內存密集使用單片架構，我們無法獨立擴展每個組件
-
擴展開發的障礙 - 單片應用程序也是擴展開發的障礙。一旦應用程序達到一定的規模，將工程組織划分為專注於特定功能區域的團隊就很有用。例如，我們可能希望擁有UI團隊，會計團隊，庫存團隊等。單一應用程序的問題在於它會阻止團隊獨立工作。團隊必須協調他們的開發工作和重新部署。團隊進行更改和更新生產要困難得多。
-
需要對技術堆棧的長期承諾 - 單一架構迫使您與開發時選擇的技術堆棧（在某些情況下，與該技術的特定版本）結合。使用單片應用程序，可能難以逐步采用更新的技術。例如，假設您選擇了JVM。你有一些語言選擇，因為除了Java之外你還可以使用其他與Java很好地交互的JVM語言，比如Groovy和Scala。但是，使用非JVM語言編寫的組件在單片體系結構中沒有位置。此外，如果您的應用程序使用隨后變得過時的平台框架，那么將應用程序逐步遷移到更新更好的框架可能具有挑戰性。為了采用更新的平台框架，您可能需要重寫整個應用程序，這是一項冒險的任務。
相關模式
微服務架構是一種解決單片架構局限性的替代模式。
已知的用戶
眾所周知的互聯網服務，如Netflix，Amazon.com和eBay最初都有一個單一的架構。作者開發的大多數Web應用程序都具有單一體系結構。