[譯]一體化架構(Monolithic Architecure)

This a translation of an article ( http://microservices.io/patterns/monolithic.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson).

模式：一體化架構

背景

假設你在開發一個服務端應用。該應用必須支持各類各樣的客戶端，包括桌面瀏覽器、手機瀏覽器和本地手機應用。應用可能也須要公開部分API供第三方使用，還可能與其餘應用經過web service或消息代理(message broker)相集成。應用執行業務邏輯來處理請求(HTTP請求或者消息)；訪問數據庫；與其餘系統交換消息；並返回HTML/JSON/XML類型的響應。

應用或是多層架構或是六角架構，而且包含多種類型的組件：

• 表示組件(Presentation components) - 響應處理HTTP請求，並返回HTML或JSON/XML(對於web service API)

• 業務邏輯(Business logic) - 應用的業務邏輯

• 數據庫訪問邏輯(Database access logic) - 數據訪問對象用於訪問數據庫

• 應用集成邏輯(Application integration logic) - 消息層，如基於Spring的集成

這些邏輯組件分別響應應用中不一樣的功能模塊。

問題

應用的部署架構是什麼？

推進力

• 該應用由一個開發者團隊在維護

• 團隊新成員必須快速上手

• 應用應該易於理解和修改

• 你想對應用進行持續集成

• 你必須在多臺機器上部署多份應用的拷貝，以知足可伸縮性和可用性的要求

• 你想使用新技術(框架、編程語言等)

解決方案

使用一體化架構構建應用。如：

• 單個Java WAR文件

• 單個Rails或NodeJS目錄結構

舉例

咱們假設你在構建一個電子商務應用，應用從客戶接收訂單，驗證庫存和可用額度，並派送訂單。應用包含多個組件，包括StoreFrontUI，用來實現用戶接口，以及一些後臺服務，用於檢測信用額度、維護庫存和派送訂單。

應用做爲一體應用部署。例如，一個Java web應用運行在Tomcat之類web容器上，僅包含單個WAR文件；一個Rails應用使用Phusion Passenger部署在Apache/Nginx上，或者使用JRuby部署在Tomcat上，它們都僅包含單個目錄結構。爲了伸縮和提升可用性，你能夠在一個負載均衡器下面運行該應用的多份實例。

結果

這個方案有一些好處：

• 易於開發 - 當前開發工具和IDE的目標就是支持這種一體應用的開發

• 易於部署 - 你只須要將WAR文件或目錄結構放到合適的運行環境下

• 易於伸縮 - 你只須要在負載均衡器下面運行應用的多份拷貝就能夠伸縮

可是，一旦應用變大、團隊增加，這種方法的缺點就越發明顯：

• 巨大的一體代碼庫可能會嚇到開發者，尤爲是團隊的新人。應用難於理解和修改。所以，開發速度一般會減緩。另外，因爲沒有模塊硬邊界，模塊化也隨時間而破壞。還有，由於難於理解如何實現變動，代碼質量也隨時間降低。這是個惡性循環！

• 超載的IDE - 代碼庫越大，IDE越慢，開發者效率越低。

• 超載的web容器 - 應用越大，容器啓動時間越長。所以開發者大量的時間被浪費在等待容器啓動上。這也會影響到部署。

• 難於持續部署 - 對於頻繁部署，巨大的一體應用也是個問題。爲了更新一個組件，你必須從新部署整個應用。這還會中斷後臺任務(如Java應用的Quartz做業)，無論變動是否影響到這些任務，此外還可能引起問題。未被更新的組件也可能於是不能正常啓動。所以，鑑於從新部署的相關風險會增長，不鼓勵頻繁更新。這尤爲對用戶界面的開發者來講是個問題，由於他們一般須要快速迭代，頻繁從新部署。

• 難於伸縮應用 - 一體架構只能在一個維度伸縮。一方面，它能夠經過運行多個拷貝來伸縮知足業務量的增長。某些雲服務甚至能夠動態地根據負載調整應用實例的數量。可是另外一方面，該架構不能伸縮知足數據量的增長。每一個應用實例都要訪問所有數據，這使緩存低效，而且提高了內存佔用和I/O流量。並且，不一樣的組件所需資源不一樣 - 有些多是CPU密集型的，另外一些多是內存密集型的。一體架構下，咱們不能獨立伸縮各個組件。

• 難於調整開發規模 - 一體應用對調整開發規模也是個障礙。一旦應用達到必定規模，將工程組織分紅專一於特定功能模塊的團隊一般更有效。好比，咱們可能須要UI團隊，會計團隊，庫存團隊等。一體應用的問題是它阻礙組織團隊相互獨立地工做。團隊之間必須在開發進度和從新部署上進行協調。對團隊來講也很難改變和更新產品。

• 須要對一個技術棧長期投入 - 一體架構迫使你娶下開發初選擇的技術棧(某些狀況下，是那項技術的某個版本)。一體架構下，很難遞增式地採用更新的技術。好比，想象下你選了JVM。除了Java你還能夠選擇其餘使用JVM的語言，它們好比Groovy和Scala也能夠與Java很好地進行互操做。可是一體架構下，非JVM語言寫的組件就不行。並且，若是應用使用了後期過期的平臺框架，將應用遷移到更新更好的框架上就頗有挑戰性。還有可能，爲了採用新的平臺框架，你要重寫整個應用，這就太冒險了。

相關模式

微服務架構是解決一體化架構缺點的替代模式。

已知案例

著名的互聯網服務，如Netflix, Amazon.com和eBay開始都使用一體架構。做者開發的大部分web應用也是一體架構的。

變動

第一篇：一體化架構(Monolithic Architecture)

第二篇：微服務架構(Microservices Architecure)

            伸縮立方(Scale Cube)

第三篇：API網關(API Gateway)