單體應用架構存在的問題

乙個歸檔包（例如war格式）包含所有功能的應用程式，通常稱為單體程式。而架構單體應用的方**，就是單體應用架構。

以乙個電影售票系統為例，該系統ui和若干業務模組最終都被打包在乙個war包中，該war包包含了整個系統的所有業務功能，這樣的應用稱為單體應用。

很多專案都是從單體應用開始的。單體應用比較容易部署、測試，在專案的初期，單體應用可以很好地執行。然而隨著需求的不斷增加，越來越多的人加入開發團隊，**庫也在飛速膨脹。慢慢地，單體應用變得越來越臃腫，可維護性、靈活性逐漸減低，維護成本越來越高。

下面列舉一些單體應用存在的問題。

1 複雜性高：當乙個專案達到百萬級別，整個專案包含的模組非常多、模組的邊界模糊、依賴關係不清晰、**質量參差不齊、混亂地堆砌在一起。整個專案非常複雜。每次修改**都心驚膽戰，甚至新增乙個簡單的功能，或者修改乙個bug都會帶來隱含的缺陷。

2 技術債務：隨著時間推移、需求變更和人員更迭，會逐漸形成應用程式的技術債務，並且越積越多。「不壞不修」，這在軟體開發中非常常見，在單體應用中，這種思想更嚴重。已使用的系統設計或**難以被修改，因為應用程式中的其他模組可能會以意料之外的方式使用它。

3 部署頻率低：隨著**的增多，構建和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修復都會導致重新部署整個應用。全量部署的方式耗時長、影響範圍大、風險高，這使得單體應用專案部署的頻率較低。而部署頻率低又導致兩次發布之間會有大量功能的變更和缺陷修復，出錯概率較高。

4 可靠性差：某個應用bug，例如死迴圈、oom等，可能導致整個應用崩潰。

5 擴充套件能力受限：單體應用只能作為乙個整體進行擴充套件，無法根據業務模組的需要進行伸縮。例如，應用中有的模組是計算密集型的，它需要強勁的cpu；有的模組則是io密集型的，需要更大的記憶體。由於這些模組部署在一起，不得不在硬體的選擇上做出妥協。

6 阻礙技術創新：單體應用往往使用統一的技術平台或方案解決所有的問題，團隊中的每個成員必須使用相同的開發語言和框架，要想引入新框架或新技術平台會非常困難。例如，乙個使用struts2構建的、有百萬行**的單體應用，如果想要換用spring mvc，毫無疑問切換的成本是非常高的。

綜上，隨著業務需求的發展，功能的不斷增加，單體架構很難滿足網際網路時代快速變化的需要。