詳解Java 微服務架構

一、傳統的整體式架構

傳統的整體式架構都是模塊化的設計邏輯,如展示(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 微服務架構的資料請關註WalkonNet其它相關文章!