什麼是單體架構
乙個歸檔包（例如war格式或者jar格式）包含了應用所有功能的應用程式，我們通常稱之為單體應用。架構單體應用的方**，我們稱之為單體應用架構，這是一種比較傳統的架構風格。
1.複雜性高
整個專案包含的模組非常多，模組的邊界模糊，依賴關係不清晰，**質量參差不齊,整個專案非常複雜。每次修改**都心驚膽戰，甚至新增乙個簡單的功能，或者修改乙個bug都會造成隱含的缺陷。
2.技術債務逐漸上公升
隨著時間推移、需求變更和人員更迭，會逐漸形成應用程式的技術債務，並且越積越多。已使用的系統設計或**難以修改，因為應用程式的其他模組可能會以意料之外的方式使用它。
3.部署速度逐漸變慢
隨著**的增加，構建和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修復都會導致我們需要重新部署整個應用。全量部署的方式耗時長、影響範圍大、風險高，這使得單體應用專案上線部署的頻率較低，從而又導致兩次發布之間會有大量功能變更和缺陷修復，出錯概率較高。
4.擴充套件能力受限，無法按需伸縮
單體應用只能作為乙個整體進行擴充套件，無法結合業務模組的特點進行伸縮。
5.阻礙技術創新
單體應用往往使用統一的技術平台或方案解決所有問題，團隊的每個成員都必須使用相同的開發語言和架構，想要引入新的框架或技術平台非常困難。由於單體架構的缺陷日益明顯，所以越來越多的公司採用微服務架構解決上面提到的單體架構中的問題。不同於構建單
一、龐大的應用，微服務架構將應用拆分為一套小且互相關聯的服務。
單體架構 的痛點
隨著業務功能的不斷增加,數量不斷的累計,系統迭代難度不斷加大,不利於進行敏捷開發,各個模組之間相互耦合,乙個功能出現問題可能造成整個service 不可用 微服務 的出現就是來解決單體架構的痛點,將各個業務功能進行拆分,以前的各個功能模組轉變成各個微服務,微服務之間的呼叫可以通過閘道器進行 註冊中心...
單體架構存在的問題
複雜性高，模組多，模組邊界模糊，質量參差不齊，每次修改 都心驚膽戰。技術人員更新快，不可能一直在乙個公司，新入職人員可能會遇上離職人員的沒有修復的bug。隨著單體應用功能越來越多，部署時間也會越來越長，出錯概率比較高。可靠性差，比如死迴圈導致整個應用的崩潰。4 可靠性差，比如死迴圈導致整個應用的崩潰...
單體應用架構存在的問題
乙個歸檔包 例如war格式 包含所有功能的應用程式，通常稱為單體程式。而架構單體應用的方 就是單體應用架構。以乙個電影售票系統為例，該系統ui和若干業務模組最終都被打包在乙個war包中，該war包包含了整個系統的所有業務功能，這樣的應用稱為單體應用。很多專案都是從單體應用開始的。單體應用比較容易部署...