Java之Spring Cloud概念介紹
文章大綱
一、理解微服務
二、Spring Cloud知識介紹
三、參考資料下載
四、參考文章
一、理解微服務
我們通過軟體架構演進過程來理解什麼是微服務,軟體架構的發展經歷了從單體結構、垂直架構、SOA架構到微服務架構的過程。
1. 單體架構
1.1 特點
(1)所有的功能整合在一個專案工程中。
(2)所有的功能打一個war包部署到伺服器。
(3)應用與資料庫分開部署。
(4)通過部署應用叢集和資料庫叢集來提高系統的效能。
1.2 優點
(1)專案架構簡單,前期開發成本低,週期短,小型專案的首選。
1.3 缺點
(1)全部功能整合在一個工程中,對於大型專案不易開發、擴充套件及維護。
(2)系統性能擴充套件只能通過擴充套件叢集結點,成本高、有瓶頸。
(3)技術棧受限。
2. 垂直架構
2.1 特點
(1)以單體結構規模的專案為單位進行垂直劃分專案即將一個大專案拆分成一個一個單體結構專案。
(2)專案與專案之間的存在資料冗餘,耦合性較大,比如上圖中三個專案都存在客戶資訊。
(3)專案之間的介面多為資料同步功能,如:資料庫之間的資料庫,通過網路介面進行資料庫同步。
2.2 優點
(1)專案架構簡單,前期開發成本低,週期短,小型專案的首選。
(2)通過垂直拆分,原來的單體專案不至於無限擴大。
2.3 缺點
(1)全部功能整合在一個工程中,對於大型專案不易開發、擴充套件及維護。
(2)系統性能擴充套件只能通過擴充套件叢集結點,成本高、有瓶頸。
3. SOA架構
3.1特點
(1)基於SOA的架構思想將重複公用的功能抽取為元件,以服務的方式給各各系統提供服務。
(2)各個專案(系統)與服務之間採用webservice、rpc等方式進行通訊。
(3)ESB企業服務匯流排作為專案與服務之間通訊的橋樑。
3.2 優點
(1)將重複的功能抽取為服務,提高開發效率,提高系統的可重用性、可維護性。
(2)可以針對不同服務的特點制定叢集及優化方案。
3.3 缺點
(1)系統與服務的界限模糊,不利於開發及維護。
(2)雖然使用了ESB,但是服務的介面協議不固定,種類繁多,不利於系統維護。
(3)抽取的服務的粒度過大,系統與服務之間耦合性高。
4. 微服務架構
為適應企業的業務發展,提高軟體研發的生產力,降低軟體研發的成本,軟體架構也作了升級和優化,將一個獨立的系統拆分成若干小的服務,每個小服務執行在不同的程序中,服務與服務之間採用http 輕量協議(比如流行的RESTful)傳輸資料,每個服務所擁有的功能具有獨立性強、高內聚的特點,這樣的設計就實現了單個服務的高內聚,服務與服務之間的低耦合效果,這一個一個的小服務就是微服務,基於這種方法設計的系統架構即微服務架構。
4.1 特點
(1)將系統服務層完全獨立出來,並將服務層抽取為一個一個的微服務。
(2)微服務遵循單一原則。
(3)微服務之間採用RESTful等輕量協議傳輸。
4.2 優點
(1)服務拆分粒度更細,有利於資源重複利用,提高開發效率。
(2)可以更加精準的制定每個服務的優化方案,提高系統可維護性。
(3)微服務架構採用去中心化思想,服務之間採用RESTful等輕量協議通訊,相比ESB更輕量。
(4)適用於網際網路時代,產品迭代週期更短。
4.3 缺點
(1)微服務過多,服務治理成本高,不利於系統維護。
(2)分散式系統開發的技術成本高(容錯、分散式事務等),對團隊挑戰大。
5. SOA架構和微服務架構的區別
首先SOA和微服務架構一個層面的東西,而對於ESB和微服務閘道器是一個層面的東西,一個談到是架構風格和方法,一個談的是實現工具或元件。
(1)SOA(Service Oriented Architecture)“面向服務的架構”:他是一種設計方法,其中包含多個服務, 服務之間通過相互依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在與作業系統程序中。各個服務之間 通過網路呼叫。
(2)微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的昇華,微服務架構強調的一個重點是“業務需要徹底的元件化和服務化”,原有的單個業務系統會拆分為多個可以獨立開發、設計、執行的小應用。這些小應用之間通過服務完成互動和整合。
微服務架構 = 80%的SOA服務架構思想 + 100%的元件化架構思想 + 80%的領域建模思想
二、Spring Cloud知識介紹
1. 微服務的技術棧
負載均衡,閘道器路由:高可用、叢集部署,校驗、請求轉發、服務整合。
服務治理:服務註冊、發現。
容錯:避免雪崩。
監控跟蹤:監控資源利用、服務響應、容器資源利用情況。
訊息匯流排:訊息佇列、非同步通訊。
配置管理:統一配置管理。
2. Spring Cloud是什麼
Spring Cloud為開發人員構建微服務架構提供了完整的解決方案,SpringCloud是若干個框架的集合,它包括spring-cloud-config、spring-cloud-bus等近20個子專案,它提供了服務治理、服務閘道器、智慧路由、負載均衡、斷路器、監控跟蹤、分散式訊息佇列、配置管理等領域的解決方案。
3. Spring Cloud技術棧
微服務的興起出現了很多優秀的公司和技術:
服務治理:Dubbo(阿里巴巴)、Dubbox(噹噹)、Eureka(Netflix)等 。
配置管理:Disconf(百度)、QConf(360)、Diamood(淘寶)等 。
服務跟蹤:Hydra(京東)、Zipkin(Twitter)、Sleuth(Spring Cloud)等 。
Spring Cloud 提供一站式的微服務架構解決方案,如下圖:
4. 為什麼使用Spring Cloud
微服務架構的優點表明它可以提高我們的生產力,但是分散式系統本身的技術成本問題給網際網路那些創業型公司不少的挑戰,阿里、百度等巨頭所提供的微服務技術只是解決其中某個問題,而整合封裝這些優秀的技術恐怕是Spring最擅長的領域了,Spring Cloud也正因為此而誕生。
使用Spring Cloud來構建微服務架構可以省去你整合各家技術的成本,Spring Cloud為我們構建微服務架構提供了一站式的解決方案,就好比當初Spring誕生是為解決EJB企業應用開發的眾多問題而提供的一站式輕量級企業應用開發解決方案一樣,隨著使用Spring Cloud公司數量的增加,相信微服務將被Spring Cloud一統江湖。
5. 服務治理
5.1 什麼是服務治理
微服務架構的缺點中最主要的就是由於微服務數量眾多導致維護成本巨大,服務治理為解決此問題而產生的。服務治理的作用是讓維護人員從人工維護中解放出來,由服務自維護,微服務作為服務提供方主動向服務治理中心註冊,服務的消費方通過服務治理中心查詢需要的服務並進行呼叫。
如下圖:
5.2 Spring Cloud Eureka
Spring Cloud Eureka 是對Netflix公司的Eureka的二次封裝,它實現了服務治理的功能,Spring Cloud Eureka提供服務端與客戶端,服務端即是服務註冊中心,客戶端完成服務的註冊與發現。服務端和客戶端均採用Java語言編寫(Eureka支援多語言)。
如下圖顯示了Eureka Server與Eureka Client的關係:
5.3 架構
5.4 實際專案流程圖
6. 負載均衡
6.1 什麼是負載均衡
負載均衡是微服務架構中必須使用的技術,通過負載均衡來實現系統的高可用、叢集擴容等功能。負載均衡可通過硬體裝置及軟體來實現,硬體比如:F5、Array等 ,軟體比如:LVS、Nginx等 。
如下圖是負載均衡的架構圖:
使用者請求先到達負載均衡器(也相當於一個服務),負載均衡器根據負載均衡演算法將請求轉發到微服務。負載均衡演算法有:輪訓、隨機、加權輪訓、加權隨機、地址雜湊等方法,負載均衡器維護一份服務列表,根據負載均衡演算法將請求轉發到相應的微服務上,所以負載均衡可以為微服務叢集分擔請求,降低系統的壓力。
6.2 Spring Cloud Ribbon
Spring Cloud Ribbon是基於客戶端的負載均衡工具,負載均衡分為服務端負載均衡和客戶端負載均衡,3.1小節的圖形指的是服務端負載均衡,客戶端負載均衡與服務端負載均衡的區別在於客戶端要維護一份服務列表,Ribbon從Eureka Server獲取服務列表,Ribbon根據負載均衡演算法直接請求到具體的微服務,中間省去了負載均衡服務。
如下圖是Ribbon負載均衡的流程圖:
(1)在消費微服務中使用Ribbon實現負載均衡,Ribbon先從Eureka Server中獲取服務列表。
(2)Ribbon根據負載均衡的演算法進行負載均衡,將請求轉發到其它微服務。
6.3 實際專案流程圖
7. 容錯保護
7.1 什麼是容錯保護
容錯保護是指微服務在執行過程中出現錯誤並從錯誤中恢復的能力。微服務容錯性不好很容易導致雪崩效應,什麼是雪崩效應?摘自百度百科中的定義:
微服務的雪崩效應表現在服務與服務之間呼叫,當其中一個服務無法提供服務可能導致其它服務也死掉,比如:單點登入服務呼叫使用者資訊服務查詢使用者資訊,由於使用者資訊服務無法提供服務導致單點登入服務一直等待,從而導致使用者登入、使用者退出功能無法使用,像這樣由一個服務所引起的一連串的多個服務無法提供服務即是微服務的雪崩效應。
7.2 Spring Cloud Hystrix
Spring Cloud Hystrix 是基於Netflix的開源框架Hystrix的整合,它實現了斷路器、執行緒隔離、訊號隔離等容錯功能。
下圖是Hystrix斷路器示意圖:
8. 服務閘道器
8.1 什麼是服務閘道器
服務閘道器是在微服務前邊設定一道屏障,請求先到服務閘道器,閘道器會對請求進行過慮、校驗、路由等處理。有了服務閘道器可以提高微服務的安全性,校驗不通過的請求將被拒絕訪問。
前邊介紹的Ribbon客戶端負載均衡技術可以不用經過閘道器,因為通常使用Ribbon完成微服務與微服務之間的內部呼叫,而對那些對外提供服務的微服務,比如:使用者登入、提交訂單等,則必須經過閘道器來保證微服務的安全。
8.2 Spring Cloud Zuul
Spring Cloud Zuul是整合Netflix公司的Zuul開源專案實現的微服務閘道器,它實現了請求路由、負載均衡、校驗過慮等 功能。
8.3 實際專案的流程圖
三、參考資料下載
參考資料中包含了簡單程式碼學習,有興趣朋友可以下載:
連結:https://pan.baidu.com/s/1i1hrwqfUetwsY-AJT4RFPg
提取碼:1mmc
四、參考文章
http://yun.itheima.com/cours