Java中微服務架構與傳統架構的區別

在聊微服務之前，先來看看傳統架構的優缺點。

傳統的 MVC 架構，所有的子系統都集成在一個很繁雜的 JVM 進程中。

優點：

這種單體架構的優點在於方便管理，所有代碼在同一項目中，但是當需求越來越多，項目規模越來越大，其壞處也很明顯。

缺點：

1、項目過於臃腫，部署效率低下

當大大小小的功能模塊都集中在同一項目的時候，整個項目必然會變得臃腫，讓開發者難以維護。單體應用的代碼越來越多，依賴的資源越來越多時，應用編譯打包、部署測試一次非常耗時。系統高可用性差，資源無法隔離，整個單體系統的各個功能模塊都依賴於同樣的數據庫、內存等資源，一旦某個功能模塊對資源使用不當，整個系統都會被拖垮。

2、開發成本高

早期在團隊開發人員只有兩三個人的時候，協作修改代碼，打包部署，更新發布這完全可以控制。但是團隊一旦擴張，還是按照早期的方法去開發，那如果測試階段只要有一塊功能有問題，就得重新編譯打包部署。所有的開發人員又都得參與其中，效率低下，開發成本極高。

3、無法靈活拓展

當系統的訪問量越來越大的時候，單體系統固然可以進行水平擴展，部署在多台機器上組成集群：但是這種擴展並非靈活的擴展，因此，急需一種方法將應用的不同模塊進行解耦，從而降低開發和部署成本。

要解決上面單體應用的問題，就必須引入服務化的概念。

什么是服務化？

用通俗的語言來說，服務化就是把傳統單體應用中通過 JAR 包依賴產生的本地方法調用，改造成 RPC 接口產生的遠程方法調用。這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署。 這些服務的集中管理最少，可以用不同的編程語言編寫，並使用不同的數據存儲技術。

什么是微服務？

微服務架構是一種架構風格和架構思想，它倡導我們在傳統軟件應用架構的基礎上，將系統業務按照功能拆分為更加細粒度的服務，所拆分的每一個服務都是一個獨立的應用，這些應用對外提供公共的API，可以獨立承擔對外服務的職責，通過此種思想方式所開發的軟件服務實體就是“微服務”，而圍繞着微服務思想構建的一系列結，我們可以將它稱之為“微服務架構

微服務有什么樣的具體特點呢？

1、服務拆分粒度更細

微服務可以說是更細維度的服務化，小到一個子模塊，只要該模塊依賴的資源與其他模塊都沒有關系，那么就可以拆分為一個微服務。

2、服務獨立部署

傳統的單體架構是以整個系統為單位進行部署，而微服務則是以每一個獨立組件為單位進行部署。

3、服務獨立維護，分工明確

每個微服務都可以交由一個小團隊進行開發，測試維護部署，並對整個生命周期負責，當我們將每個微服務都隔離為獨立的運行單元之后，任何一個或者多個微服務的失敗都將只影響自己或者少量其他微服務，而不會大面積地波及整個服務運行體系。

微服務它是由單體應用進化到服務化拆分部署,后期隨着移動互聯網規模的不斷擴大,敏捷開發、DevOps 理論的發展和實踐。隨着微服務架構的越來越完善和發展，更多的企業已經使用這種架構方法。

更多最新java技術，資料和知識點，可以私信或評論聯系我領取！