一、傳統的整體式架構

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

系統的水平擴展

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

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

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

缺點

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

三、微服務架構

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

缺點

開發人員必須處理創建分布式系統的復雜性。 部署的復雜性。 增加內存消耗。

微服務架構與SOA的區別

四、如何構建微服務架構

微服務架構的組件

（1）服務注冊中心：注冊系統中所有服務的地方。

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

（3）服務發現：服務調用方從服務注冊中心找到自己需要調用服務的地址。

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

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

（6）服務網關：也稱為API網關，是服務調用的唯一入口，可以在這個組件中實現用戶鑒權、動態路由、灰度發布、負載限流等功能。

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

微服務架構的技術選型

（1）微服務實例的開發：SpringBoot

（2）服務的注冊與發現：Spring Cloud Eureka

（3）負載均衡：Spring Cloud Ribbon

（4）服務容錯：Spring Cloud Hystrix

（5）API網關：Spring Cloud Zuul

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

（7）調試：Swagger

（8）部署：Docker

（9）持續集成：Jenkins

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