微服務構架-單體架構

一、上下文

您正在開發服務器端企業應用程序。它必須支持各類不一樣的客戶端，包括桌面瀏覽器，移動瀏覽器和本機移動應用程序。該應用程序還可能會公開供第三方使用的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語言編寫的組件在單片體系結構中沒有位置。此外，若是您的應用程序使用隨後變得過期的平臺框架，那麼將應用程序逐步遷移到更新更好的框架可能具備挑戰性。