[翻譯]微服務設計模式 - 1. 單體應用模式

原文地址：https://microservices.io/patterns/monolithic.html

場景描述

假設你正在開發一個大型服務端企業應用，有以下需求：

• 必須支持多種客戶端，包括：WEB 端瀏覽器、WAP 端瀏覽器以及原生移動 APP。
• 對外暴露公共 API 用於調用
• 處理 HTTP 請求，或者消息，執行對應的業務邏輯。
• 訪問數據庫，緩存或者持久化響應的數據
• 與其餘系統進行通訊，交換所需的信息
• 返回 HTTP 響應，指定好特定的序列化方式，例如 JSON、 XML 等等
• 根據業務邏輯與功能，設計並劃分出不一樣邏輯模塊

這樣的一個應用，你會如何設計架構並部署呢？

考慮因素

• 這是一個團隊開發的項目，有一個獨立團隊負責
• 團隊成員會發生變化，新加入的成員必須快速上手項目
• 應用程序必須易於理解並修改
• 指望能實現應用的持續集成與部署
• 必須能夠多實例部署應用程序，以知足可伸縮性和可用性要求。
• 想用比較新的技術（框架、編程語言等）

解決方案

使用單體架構，例如：

• 一個 Java WAR 文件啓動的程序
• 一個單目錄 Rails 或者 NodeJS 程序

舉例

假設如今正在設計一個電商應用，功能包括接收來自客戶的訂單（StoreFrontUI），驗證並維護庫存餘額（Inventory Service），驗證並維護用戶可用餘額（Accounting Service），下單成功併發貨（Shipping Service）。這個應用被設計成一個單體架構應用，例如：JavaWeb 應用程序由運行在Web容器(如 Tomcat )上的單個 WAR 文件組成。Rails 應用程序由部署在 Nginx 或 Tomcat 上的 JRuby 或 Nginx 上的單一目錄層次結構組成。能夠在負載均衡器後面部署多個實例，以擴展和提升可用性。

分析

這種解決方案的好處有：

• 開發簡單，當前的 IDE 基本都是按照開發單體應用程序開發的。
• 部署簡單，只要把一個文件或者目錄部署到 Web 容器裏便可。
• 擴容簡單，經過在負載均衡器後面部署多個實例就能實現擴容。

可是，隨着產品不斷迭代，這個單體應用程序將會變得愈來愈大，團隊的規模也愈來愈大，這種單體設計就會有一些缺點，而且這些缺點會變得愈來愈嚴重：

• 單體應用代碼在同一個代碼庫，這個代碼庫會愈來愈大，使開發人員感受會很頭大，特別是那些剛加入團隊的開發人員。應用程序將很難理解和修改，所以，開發速度一般會被減緩。另外，因爲沒有明確的模塊邊界，代碼內部的模塊化會隨着時間的推移而愈來愈模糊。此外，因爲很難理解如何正確實現更改，而且可能還須要兼容老版本的錯誤，所以代碼的質量會隨着時間的推移而降低，慢慢堆積成爲屎山。
• IDE 的壓力會很大。代碼庫越大，IDE 會更慢，IDE 通常爲了智能補全代碼的功能，會對代碼作索引並加載到內存中。臃腫的代碼會拖慢 IDE，下降開發效率。
• Web 容器壓力變大。程序越臃腫，啓動時間會被拖長，致使代碼調試變慢，同時部署時間也會變長。
• 持續集成部署難度愈來愈大。爲了更新一個組件，您必須從新部署整個應用程序。這會致使全部業務，不論是否有更新，都被影響或者中斷。同時，若是出現問題，回滾時間也會增加。所以，這限制了程序不能持續頻繁更新。
• 不能靈活擴展。不一樣業務模塊可能壓力不一樣，以及壓力大的時間段可能也不一樣，可是每次擴容，都須要全部模塊一塊擴容，形成了浪費。
• 故障擴散。若是有一個模塊出了問題致使內存泄漏，那麼整個業務都會受到影響。
• 團隊分工的障礙。例如，咱們可能但願有UI團隊、會計團隊、庫存團隊等等。單塊應用程序的問題在於它阻止了團隊獨立工做。小組必須協調他們的開發工做和從新部署。對於一個團隊來講，進行更改和更新生產要困可貴多。
• 須要長期使用同一個技術棧。一種單一的體系結構迫使您與您在開發開始時所選擇的技術堆棧(在某些狀況下，與該技術的特定版本)結合在一塊兒。有了單體應用程序，就很難逐步採用一種較新的技術。好比你使用的框架中止更新，或者過期了，在單體應用下很難逐步採用一個新的框架實現。