一、傳統(tǒng)的整體式架構

傳統(tǒng)的整體式架構都是模塊化的設計邏輯，如展示（Views）、應用程序邏輯（Controller）、業(yè)務邏輯（Service）和數(shù)據(jù)訪問對象（Dao），程序在編寫完成后被打包部署為一個具體的應用。如圖所示：

系統(tǒng)的水平擴展

如果要對系統(tǒng)進行水平擴展，通常情況下，只需要增加服務器的數(shù)量，并將打包好的應用拷貝到不同的服務器，然后通過負載均衡器（Nginx）就可以輕松實現(xiàn)應用的水平擴展。

整體式架構的缺點 應用復雜度增加，更新、維護困難。 易造成系統(tǒng)資源浪費。 影響開發(fā)效率。 應用可靠性低。 不利于技術更新。 二、面向服務的架構SOA（Service-Oriented Architecture）

SOA的思路是把應用中相近的功能聚合在一起，以服務的形式提供出去。如圖所示：

缺點

雖然SOA解決了整體式架構中的問題，但多數(shù)情況下，SOA中相互獨立的服務仍然會部署在同一個運行環(huán)境中。和整體式架構類似，隨著業(yè)務功能的增多，SOA的服務會變得越來越復雜。本質(zhì)上看，整體式架構的問題并沒有因為使用SOA而變得更好。

三、微服務架構

微服務架構是一種架構風格和架構思想，它倡導我們在傳統(tǒng)軟件應用架構的基礎上，將系統(tǒng)業(yè)務按照功能拆分為更加細粒度的服務，所拆分的每一個服務都是一個獨立的應用，這些應用對外提供公共的API，可以獨立承擔對外服務的職責，通過此種思想方式所開發(fā)的軟件服務實體就是“微服務”，而圍繞著微服務思想構建的一系列結構（包括開發(fā)、測試、部署等），我們可以將它稱之為“微服務架構”。如圖所示：

缺點

開發(fā)人員必須處理創(chuàng)建分布式系統(tǒng)的復雜性。 部署的復雜性。 增加內(nèi)存消耗。

微服務架構與SOA的區(qū)別

四、如何構建微服務架構

微服務架構的組件

（1）服務注冊中心：注冊系統(tǒng)中所有服務的地方。

（2）服務注冊：服務提供方將自己調(diào)用地址注冊到服務注冊中心，讓服務調(diào)用方能夠方便地找到自己。

（3）服務發(fā)現(xiàn)：服務調(diào)用方從服務注冊中心找到自己需要調(diào)用服務的地址。

（4）負載均衡：服務提供方一般以多實例的形式提供服務，使用負載均衡能夠讓服務調(diào)用方連接到合適的服務節(jié)點。

（5）服務容錯：通過斷路器（也稱熔斷器）等一系列的服務保護機制，保證服務調(diào)用者在調(diào)用異常服務時能快速地返回結果，避免大量的同步等待。

（6）服務網(wǎng)關：也稱為API網(wǎng)關，是服務調(diào)用的唯一入口，可以在這個組件中實現(xiàn)用戶鑒權、動態(tài)路由、灰度發(fā)布、負載限流等功能。

（7）分布式配置中心：將本地化的配置信息（properties、yml、yaml等）注冊到配置中心，實現(xiàn)程序包在開發(fā)、測試、生產(chǎn)環(huán)境的無差別性，方便程序包的遷移。

微服務架構的技術選型

（1）微服務實例的開發(fā)：SpringBoot

（2）服務的注冊與發(fā)現(xiàn)：Spring Cloud Eureka

（3）負載均衡：Spring Cloud Ribbon

（4）服務容錯：Spring Cloud Hystrix

（5）API網(wǎng)關：Spring Cloud Zuul

（6）分布式配置中心：Spring Cloud Config

（7）調(diào)試：Swagger

（8）部署：Docker

（9）持續(xù)集成：Jenkins

以上就是詳解Java 微服務架構的詳細內(nèi)容，更多關于Java 微服務架構的資料請關注好吧啦網(wǎng)其它相關文章！