普元雲計算-微服務模式系列之一：總體式架構

本文爲普元普元雲計算架構師宋瀟男原創翻譯微服務模式文章系列，獨家受權EAII企業架構創新研究院（微信號：eaworld）發佈，轉載請註明出處，違者必究。

 

熟悉個人朋友都知道，我很不喜歡翻譯東西，由於在兩種語言的思惟方式之間作頻繁切換對我來講是件很痛苦的事情。可是此次不同，公司和同事的大力支持下降了個人痛苦指數，讓我可以堅持把Chris Richardson的微服務模式系列文章翻譯完，今天發佈第一篇，《總體式架構》。

 

背景

  

在開發服務端企業應用時，應用須要支持各類不一樣類型的客戶端，好比桌面瀏覽器、移動瀏覽器以及原生移動應用。應用還須要向第三方提供可訪問的API，並經過Web Service或者消息代理與其它應用實現集成。應用經過執行業務邏輯、訪問數據庫、與其它系統交換信息、並返回一條HTML/JSON/XML響應，來處理請求（HTTP請求與消息）。

 

應用採用多層架構或者六角架構，主要由如下幾類不一樣組件構成：

 

• 展示組件——負責處理HTTP請求並響應HTML或者JSON/XML（對於web Services APIs）

• 業務邏輯——應用的業務邏輯

• 數據庫訪問邏輯——用於訪問數據庫的數據訪問對象

• 應用集成邏輯——消息層，例如基於Spring Integration

 

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

 

 

 

問題

 

 

應用的部署架構是什麼？

 

 

需求

 

 

• 應用須要由一個開發者團隊專門負責

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

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

• 對應用可以進行持續部署

• 須要在多臺設備上運行應用副本，從而知足可擴展性與可用性的要求

• 使用各類新技術（框架、編程語言等）

 

 

 

方案

 

 

使用單體架構構建應用。例如：

單個Java WAR文件。

單個Rails或者NodeJS代碼目錄層級。

 

 

 

舉例

 

 

假設須要構建一款電子商務應用程序，使其可以接收來自客戶的訂單、驗證庫存信息與可用信用額度，然後進行發貨。該應用程序會包含多個組件，其中StoreFrontUI負責實現用戶界面，而其它後端服務則分別負責檢查信用額度、維護庫存信息以及發送訂單。

 

應用被看成一個單體進行部署。例如：一個Java Web應用僅包含一個運行在Tomcat之類的Web容器上WAR文件。一個Rails應用由單一目錄層級構成，該目錄層級的部署經過在Apache/Nginx上使用Phusion Passenger，或者在Tomcat上使用JRuby得以實現。爲了提升擴展性和可用性，你能夠在負載均衡器以後運行此應用的多個實例。

 

 

 

結果

 

 

這類解決方案擁有如下優點：

 

• 易於開發——當前開發工具與IDE的設計目標即在於支持單體應用的開發。

• 易於部署——你只須要將該WAR（或者目錄層級）部署在合適的運行環境中便可。

• 易於擴展——你能夠在負載均衡器後面運行多個應用副本實現擴展。

 

然而，一旦應用變大、團隊擴大，這種方案的弊端將會變得愈發明顯：

 

• 單體應用巨大的代碼庫可能會讓人望而生畏，特別是對那些團隊新成員來講。應用難以被理解和進行修改，進而致使開發速度減慢。因爲沒有清晰的模塊邊界，模塊化會逐漸消失。另外，因爲難以正確把握代碼變化，致使代碼質量逐步下滑，陷入惡性循環。

   

• 過載的IDE——代碼庫越大，IDE速度越慢，開發者的生產效率越低。

   

• 過載的Web容器——應用越大，Web容器啓動時間越長。容器啓動耗費時間，極大影響到開發者的生產效率。對部署工做也有負面影響。

   

• 持續部署困難——巨大的單體應用自己就是頻繁部署的一大障礙。爲了更新一個組件，你必須從新部署整個應用。這會中斷那些可能與更改無關的後臺任務（例如Java應用中的Quartz任務），同時可能引起問題。另外，未被更新的組件有可能沒法正常啓動。從新部署會增長風險，進而阻礙頻繁更新。由於用戶界面開發者常常須要進行快速迭代與頻繁從新部署，因此這對用戶界面開發者而言更加是個難題。

 

• 應用擴展困難——單體架構只能進行一維伸縮。一方面，它能夠經過運行多個應用副原本增長業務容量，實現擴展。一些雲服務甚至能夠根據負載量動態調整實例數量。但在另外一方面，數據量增大會使得該架構沒法伸縮。每一個應用實例須要訪問全部數據，致使緩存低效，加大內存佔用和I/O流量。另外，不一樣的應用組件有不一樣的資源需求——有的是CPU密集型的，另一些是內存密集型的。單體架構沒法單獨伸縮每一個組件。

   

• 難於進行規模化開發——單體應用是規模化開發的障礙。應用一旦達到特定規模，須要將現有組織拆分紅多個團隊，每一個團隊負責不一樣的功能模塊。舉例來講，咱們可能須要設立UI團隊、會計團隊、庫存團隊等等。單體應用的問題在於它使團隊沒法獨立展開工做。團隊須要在工做進度和從新部署上進行協調。對於各團隊而言，這使得變動和更新產品變得異常困難。

   

• 須要長期關注同一套技術棧——單體架構迫使咱們長期使用在開發初期選定的技術堆棧（在某些狀況下，多是某些技術的特定版本）。單體應用是漸進採用新技術的障礙。舉例來講，若是咱們選擇了JVM，那麼咱們能夠選擇Java之外的一些語言，由於Groovy和Scala等基於JVM的語言也能夠和Java進行良好的互操做。但此時以非JVM語言編寫的組件就沒法在該單體架構中使用。另外，若是你們所使用的應用平臺框架已通過時，那麼咱們將很難將應用遷移到其它更新而且更完善的框架當中。有時候爲了採用一套新型平臺框架，咱們甚至須要重寫整個應用，這是風險很大的工做。

 

 

 

相關模式

 

 

微服務架構是一種可以解決單體架構各類侷限的備選模式。

 

 

 

已知案例

 

 

知名的互聯網服務商最初皆採用單體架構，包括Netflix、Amazon.com以及eBay等等。做者開發的大多數Web應用也是用單體架構。

原文連接：http://microservices.io/patterns/monolithic.html

 

若想與做者有更多交流，請添加微信：cloud_primeton

 

 

關於做者：

宋瀟男

EAII-企業架構創新研究院 專家委員

現任普元雲計算架構師，曾任華爲雲計算產品技術總監。曾負責國家電網第一代雲資源管理平臺以及中國銀聯基於OpenStack的金融雲的技術方案、架構設計和技術原型工做。

 

原著做者

Chris Richardson

世界十大軟件架構師之一，《POJOS IN ACTION》一書的做者。他的研究領域包括Spring、Scala、微服務架構設計、NoSQL數據庫、分佈式數據庫、分佈式數據管理、事件驅動的應用編程等。

 

關於EAII

EAII（Enterprise Architecture Innovation Institute）企業架構創新研究院，致力於軟件架構創新與實踐，加速企業數字化轉型。

 

eaworld項目（微信號：eaworld，長按二維碼關注）

eaworld是EAII的官方微信帳號。