您好,登錄后才能下訂單哦!
本篇內容主要講解“java單體架構的缺點有哪些”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“java單體架構的缺點有哪些”吧!
通常我們所使用的傳統單體應用架構都是模塊化的設計邏輯,程序在編寫完成后會被打包并部署為一個具體的應用,而應用的格式則依賴于相應的應用語言和框架。
例如,在網上商城系統中,JavaWeb工程通常會被打成WA R包部署在Web服務器上,而普通Java工程會以JAR包的形式包含在WA R包中,如圖1-1所示。
早期單體架構圖
上圖中的這種應用開發風格很常見,它易于開發和調試,并且易于部署。在用戶量不多時,此種架構方式完全可以滿足需求,但隨著用戶人數的增加,一臺機器已經滿足不了系統的負載,此時我們就會考慮系統的水平擴展。通常情況下,我們只需要增加服務器的數量,并將打包好的應用拷貝到不同服務器(如Tomcat),然后通過負載均衡器(如Apache、Nginx)就可以輕松實現應用的水平擴展,如圖所示。
在早期,單體架構的這種擴展方式可以很好的滿足使用需求,但隨著時間的推移,這種方式就會產生很多問題,具體表現如下:
一個簡單的應用會隨著時間的推移而逐漸變大。一旦應用變的龐大而又復雜,那么開發團隊將會面臨很多問題,其中最主要問題就是這個應用太復雜,以至于任何單個開發者都很難進行二次開發或維護。
雖然使用負載均衡的方式可以對項目中的服務容量進行水平擴展,但由于傳統單體架構的代碼中只有一個包含所有功能的WA R包,所以在對服務容量擴容時,只能選擇重復的部署這個WA R包來擴展服務能力,而不僅僅是擴展了所需的服務。這樣導致其他不需要擴展的服務也進行了相應的擴展,但這種擴展是不需要的,因此這種方式會極大的浪費資源。
當一個應用越大時,啟動時間就會越長。開發和調試的過程中,如果有很大一部分時間都要在等待中渡過,那么必然會對開發效率有極大的影響。
傳統單體應用架構在運行時的可靠性比較低,當所有模塊都運行在一個進程中時,如果任何一個模塊中出現了一個Bug,可能會導致整個進程崩潰,從而影響到整個應用。
傳統單體應用架構一旦選定使用某些技術,則后期的開發和擴展將在這些技術的基礎上實現。如果需要更改某種技術,則可能需要將整個應用全部重新開發,這種成本是非常大的。當然,傳統單體應用架構的問題還不只這些,但出現這些問題的根本原因可以說就是由于傳統單體架構中一個WA R包內包含了系統的所有服務功能所導致的。隨著業務變的越來越多,問題也就越來越多。
如何解決傳統應用架構的問題
針對傳統單體架構的問題,大部分企業通過SOA(Service-Oriented Architecture,面向服務的架構)來解決上述問題。
SOA的思路是把應用中相近的功能聚合到一起,以服務的形式提供出去,因此基于SOA架構的應用可以理解為一批服務的組合。
同樣以網上商城為例,一個簡單的SOA系統如圖1-3所示。
從上圖可以看出,SOA將原來的單體架構按照功能細分為不同的子系統,然后再由各個子系統依賴服務中間件(這里指企業服務總線Enterprise Service Bus,簡稱ESB)來調用所需服務。
使用SOA可以將系統切分成多個組件服務,這種通過多個組件服務來完成請求的方式有很多好處,具體如下:
l把項目拆分成若干個子項目,不同的團隊可以負責不同的子項目,從而提高開發效率;
l把模塊拆分,使用接口通信,降低了模塊之間的耦合度;
l為企業的現有資源帶來了更好的重用性;l能夠在最新的和現有的應用之上創建應用;
l能夠使客戶或服務消費者免予服務實現的改變所帶來的影響;
l能夠升級單個服務或服務消費者而無需重寫整個應用,也無需保留已經不再適用于新需求的現有系統。
雖然使用SOA解決了單體架構中的問題,但多數情況下,SOA中相互獨立的服務仍然會部署在同一個運行環境中(類似于一個Tomcat實例下,運行了很多web應用)。和單體架構類似,隨著業務功能的增多,SOA的服務會變得越來越復雜。本質上看,單體架構的問題并沒有因為使用SOA而變的更好。
針對單體架構和SOA的問題,許多公司(如Amazon、eBay和NetFlix)通過采用微處理結構模式解決了系統架構中的問題。其思路不是開發一個巨大的單體式的應用,而是將應用分解為小的、互相連接的微服務。隨著微服務的使用,微服務架構的思想也隨之產生。
到此,相信大家對“java單體架構的缺點有哪些”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。