隨著互聯網技術的發展，傳統的應用架構已滿足不了實際需求，微服務架構就隨之產生。那么傳統應用架構到底出了什么問題呢?又如何解決?接下來我們將從傳統單體架構的問題開始，對為什么需要微服務架構進行詳細講解。

傳統單體應用架構的問題

通常我們所使用的傳統單體應用架構都是模塊化的設計邏輯，程序在編寫完成后會被打包并部署為一個具體的應用，而應用的格式則依賴于相應的應用語言和框架。

例如，在網上商城系統中，JavaWeb工程通常會被打成WA R包部署在Web服務器上，而普通Java工程會以JAR包的形式包含在WA R包中，如圖1-1所示。

(資料圖)

早期單體架構圖

上圖中的這種應用開發風格很常見，它易于開發和調試，并且易于部署。在用戶量不多時，此種架構方式完全可以滿足需求，但隨著用戶人數的增加，一臺機器已經滿足不了系統的負載，此時我們就會考慮系統的水平擴展。通常情況下，我們只需要增加服務器的數量，并將打包好的應用拷貝到不同服務器(如Tomcat)，然后通過負載均衡器(如Apache、Nginx)就可以輕松實現應用的水平擴展，如圖所示。

在早期，單體架構的這種擴展方式可以很好的滿足使用需求，但隨著時間的推移，這種方式就會產生很多問題，具體表現如下：

1.應用復雜度增加，更新、維護困難

一個簡單的應用會隨著時間的推移而逐漸變大。一旦應用變的龐大而又復雜，那么開發團隊將會面臨很多問題，其中最主要問題就是這個應用太復雜，以至于任何單個開發者都很難進行二次開發或維護。

2.易造成系統資源浪費

雖然使用負載均衡的方式可以對項目中的服務容量進行水平擴展，但由于傳統單體架構的代碼中只有一個包含所有功能的WA R包，所以在對服務容量擴容時，只能選擇重復的部署這個WA R包來擴展服務能力，而不僅僅是擴展了所需的服務。這樣導致其他不需要擴展的服務也進行了相應的擴展，但這種擴展是不需要的，因此這種方式會極大的浪費資源。

3.影響開發效率

當一個應用越大時，啟動時間就會越長。開發和調試的過程中，如果有很大一部分時間都要在等待中渡過，那么必然會對開發效率有極大的影響。

4.應用可靠性低

傳統單體應用架構在運行時的可靠性比較低，當所有模塊都運行在一個進程中時，如果任何一個模塊中出現了一個Bug，可能會導致整個進程崩潰，從而影響到整個應用。

5.不利于技術的更新

傳統單體應用架構一旦選定使用某些技術，則后期的開發和擴展將在這些技術的基礎上實現。如果需要更改某種技術，則可能需要將整個應用全部重新開發，這種成本是非常大的。當然，傳統單體應用架構的問題還不只這些，但出現這些問題的根本原因可以說就是由于傳統單體架構中一個WA R包內包含了系統的所有服務功能所導致的。隨著業務變的越來越多，問題也就越來越多。

如何解決傳統應用架構的問題

針對傳統單體架構的問題，大部分企業通過SOA(Service-Oriented Architecture，面向服務的架構)來解決上述問題。

SOA的思路是把應用中相近的功能聚合到一起，以服務的形式提供出去，因此基于SOA架構的應用可以理解為一批服務的組合。

同樣以網上商城為例，一個簡單的SOA系統如圖1-3所示。

SOA系統

從上圖可以看出，SOA將原來的單體架構按照功能細分為不同的子系統，然后再由各個子系統依賴服務中間件(這里指企業服務總線Enterprise Service Bus，簡稱ESB)來調用所需服務。

使用SOA可以將系統切分成多個組件服務，這種通過多個組件服務來完成請求的方式有很多好處，具體如下：

l把項目拆分成若干個子項目，不同的團隊可以負責不同的子項目，從而提高開發效率;

l把模塊拆分，使用接口通信，降低了模塊之間的耦合度;

l為企業的現有資源帶來了更好的重用性;l能夠在最新的和現有的應用之上創建應用;

l能夠使客戶或服務消費者免予服務實現的改變所帶來的影響;

l能夠升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經不再適用于新需求的現有系統。

雖然使用SOA解決了單體架構中的問題，但多數情況下，SOA中相互獨立的服務仍然會部署在同一個運行環境中(類似于一個Tomcat實例下，運行了很多web應用)。和單體架構類似，隨著業務功能的增多，SOA的服務會變得越來越復雜。本質上看，單體架構的問題并沒有因為使用SOA而變的更好。

針對單體架構和SOA的問題，許多公司(如Amazon、eBay和NetFlix)通過采用微處理結構模式解決了系統架構中的問題。其思路不是開發一個巨大的單體式的應用，而是將應用分解為小的、互相連接的微服務。隨著微服務的使用，微服務架構的思想也隨之產生。

到此這篇關于淺談一下單體架構的缺點是什么的文章就介紹到這了,更多相關單體架構的缺點內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！

關鍵詞：