淺談SpringCloud之Ribbon詳解
一、什麼是負載均衡
負載均衡:建立在現有網絡結構之上,它提供瞭一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
現在網站的架構已經從C/S模式轉變為B/S模式,C/S模式是有一個專門的客戶端,而B/S模式是將瀏覽器作為客戶端。當用戶在瀏覽器上輸入一個網址按下回車鍵後,就會產生一個請求,在遠方的服務器會處理這個請求,根據這個請求來生成用戶想要的頁面,然後將這個頁面響應給瀏覽器,這樣用戶就能看到他想要看到的東西。我們知道,一臺服務器處理數據(請求也是一種數據)的能力是有限的,當有大量的用戶同時在瀏覽器上輸入網址並按下回車鍵後,就會有大量的請求產生,遠方的服務器就不得不處理這些請求,由於請求數量過多,服務器處理的效率就會變慢,響應時間就會變長,這樣用戶就不能在可以忍受的時間內看到自己想看到的東西,嚴重影響體驗效果。更嚴重一點,如果請求數量超過瞭這臺服務器所能處理的最大請求,服務器就會崩潰,直接導致網站癱瘓。
那麼,有什麼方法能夠解決這個問題呢?答案就是建立一個集群(就是一群服務器),通過集群的力量來提高服務端的數據處理能力,因為一臺服務器的處理能力肯定比不上多臺服務器的處理能力。
這樣我們在來描述一下用戶請求頁面的過程:首先用戶在瀏覽器輸入網址並按下回車鍵,然後會產生一個請求,遠方的服務器會處理這個請求…等等,現在遠方有很多服務器,到底哪個服務器來處理這個請求呢,總不能所有的服務器都處理這個請求吧。哪個服務器處理這個請求?大傢明白瞭吧,這就是負載均衡所要解決的問題。回到上邊請求頁面的過程,這個請求此時會被一臺專門的服務器來處理,這臺服務器其實就是個集群的老大,他負責把這個請求派給下面哪個小弟(服務器)來處理,處理完之後返回頁面用戶。當有多個請求同時發生時,集群的老大可以將請求派給不同的小弟,這樣處理的效率就會大幅提升,充分發揮集群的力量,至於哪個請求到底派給哪個小弟,這就是調度策略的問題瞭。
二、實現負載均衡的三種方式
(1)HTTP重定向實現負載均衡
利用HTTP重定向協議實現負載均衡大概工作原理如下圖:
HTTP重定向服務器是一臺普通的應用服務器,其唯一個功能就是根據用戶的HTTP請求計算出一臺真實的服務器地址,並將該服務器地址寫入HTTP重定向響應中(重定向響應狀態碼為302)返回給用戶瀏覽器。用戶瀏覽器在獲取到響應之後,根據返回的信息,重新發送一個請求到真實的服務器上。如上圖所示,瀏覽器訪問www.apusapp.com,DNS服務器解析到IP地址為114.100.20.200,即HTTP重定向服務器的IP地址。重定向服務器計根據某種負載均衡算法算出真實的服務器地址為114.100.20.203並返回給用戶瀏覽器,用戶瀏覽器得到返回後重新對114.100.20.203發起瞭請求,最後完成訪問。
這種負載均衡方案的有點是比較簡單,缺點是瀏覽器需要兩次請求服務器才能完成一次訪問,性能較差;同時,重定向服務器本身的處理能力有可能成為瓶頸,整個集群的伸縮性規模有限;使用HTTP返回碼302重定向,有可能使搜索引擎判斷為SEO作弊,降低搜索排名。因此實踐中很少使用這種負載均衡方案來部署。
(2)DNS負載均衡
DNS(Domain Name System)是因特網的一項服務,它作為域名和IP地址相互映射的一個分佈式數據庫,能夠使人更方便的訪問互聯網。人們在通過瀏覽器訪問網站時隻需要記住網站的域名即可,而不需要記住那些不太容易理解的IP地址。在DNS系統中有一個比較重要的的資源類型叫做主機記錄也稱為A記錄,A記錄是用於名稱解析的重要記錄,它將特定的主機名映射到對應主機的IP地址上。如果你有一個自己的域名,那麼要想別人能訪問到你的網站,你需要到特定的DNS解析服務商的服務器上填寫A記錄,過一段時間後,別人就能通過你的域名訪問你的網站瞭。DNS除瞭能解析域名之外還具有負載均衡的功能,下面是利用DNS工作原理處理負載均衡的工作原理圖:
由上圖可以看出,在DNS服務器中應該配置瞭多個A記錄,如:
www.apusapp.com IN A 114.100.20.201;
www.apusapp.com IN A 114.100.20.202;
www.apusapp.com IN A 114.100.20.203;
因此,每次域名解析請求都會根據對應的負載均衡算法計算出一個不同的IP地址並返回,這樣A記錄中配置多個服務器就可以構成一個集群,並可以實現負載均衡。上圖中,用戶請求www.apusapp.com,DNS根據A記錄和負載均衡算法計算得到一個IP地址114.100.20.203,並返回給瀏覽器,瀏覽器根據該IP地址,訪問真實的物理服務器114.100.20.203。所有這些操作對用戶來說都是透明的,用戶可能隻知道www.apusapp.com這個域名。
DNS域名解析負載均衡有如下優點:
1.將負載均衡的工作交給DNS,省去瞭網站管理維護負載均衡服務器的麻煩。
2.技術實現比較靈活、方便,簡單易行,成本低,使用於大多數TCP/IP應用。
3.對於部署在服務器上的應用來說不需要進行任何的代碼修改即可實現不同機器上的應用訪問。
4.服務器可以位於互聯網的任意位置。
5.同時許多DNS還支持基於地理位置的域名解析,即會將域名解析成距離用戶地理最近的一個服務器地址,這樣就可以加速用戶訪問,改善性能。
同時,DNS域名解析也存在如下缺點:
1.目前的DNS是多級解析的,每一級DNS都可能緩存A記錄,當某臺服務器下線之後,即使修改瞭A記錄,要使其生效也需要較長的時間,這段時間,DNS任然會將域名解析到已下線的服務器上,最終導致用戶訪問失敗。
2.不能夠按服務器的處理能力來分配負載。DNS負載均衡采用的是簡單的輪詢算法,不能區分服務器之間的差異,不能反映服務器當前運行狀態,所以其的負載均衡效果並不是太好。
3.可能會造成額外的網絡問題。為瞭使本DNS服務器和其他DNS服務器及時交互,保證DNS數據及時更新,使地址能隨機分配,一般都要將DNS的刷新時間設置的較小,但太小將會使DNS流量大增造成額外的網絡問題。
事實上,大型網站總是部分使用DNS域名解析,利用域名解析作為第一級負載均衡手段,即域名解析得到的一組服務器並不是實際提供服務的物理服務器,而是同樣提供負載均衡服務器的內部服務器,這組內部負載均衡服務器再進行負載均衡,請請求發到真實的服務器上,最終完成請求。
(3)反向代理負載均衡
請求過程:
用戶發來的請求都首先要經過反向代理服務器,服務器根據用戶的請求要麼直接將結果返回給用戶,要麼將請求交給後端服務器處理,再返回給用戶。
反向代理負載均衡
優點:
隱藏後端服務器。與HTTP重定向相比,反向代理能夠隱藏後端服務器,所有瀏覽器都不會與後端服務器直接交互,從而能夠確保調度者的控制權,提升集群的整體性能。
故障轉移。與DNS負載均衡相比,反向代理能夠更快速地移除故障結點。當監控程序發現某一後端服務器出現故障時,能夠及時通知反向代理服務器,並立即將其刪除。
合理分配任務 。HTTP重定向和DNS負載均衡都無法實現真正意義上的負載均衡,也就是調度服務器無法根據後端服務器的實際負載情況分配任務。但反向代理服務器支持手動設定每臺後端服務器的權重。我們可以根據服務器的配置設置不同的權重,權重的不同會導致被調度者選中的概率的不同。
缺點:
調度者壓力過大 。由於所有的請求都先由反向代理服務器處理,那麼當請求量超過調度服務器的最大負載時,調度服務器的吞吐率降低會直接降低集群的整體性能。
制約擴展。當後端服務器也無法滿足巨大的吞吐量時,就需要增加後端服務器的數量,可沒辦法無限量地增加,因為會受到調度服務器的最大吞吐量的制約。
三、Ribbon簡介
Spring Cloud Ribbon是一個基於HTTP和TCP的客戶端負載均衡工具,它基於Netflix Ribbon實現。通過Spring Cloud的封裝,可以讓我們輕松地將面向服務的REST模版請求自動轉換成客戶端負載均衡的服務調用。Spring Cloud Ribbon雖然隻是一個工具類框架,它不像服務註冊中心、配置中心、API網關那樣需要獨立部署,但是它幾乎存在於每一個Spring Cloud構建的微服務和基礎設施中。因為微服務間的調用,API網關的請求轉發等內容,實際上都是通過Ribbon來實現的,包括Feign,它也是基於Ribbon實現的工具。所以,對Spring Cloud Ribbon的理解和使用,對於我們使用Spring Cloud來構建微服務非常重要。
Ribbon是Netflix發佈的負載均衡器,它有助於控制HTTP和TCP的客戶端的行為。為Ribbon配置服務提供者地址後,Ribbon就可基於某種負載均衡算法,自動地幫助服務消費者去請求。Ribbon默認為我們提供瞭很多負載均衡算法,例如輪詢、隨機等。當然,我們也可為Ribbon實現自定義的負載均衡算法。
四、Ribbon的應用
package com.itmuch.cloud.study; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; import org.springframework.cloud.client.loadbalancer.LoadBalanced; import org.springframework.context.annotation.Bean; import org.springframework.web.client.RestTemplate; @EnableDiscoveryClient @SpringBootApplication public class ConsumerMovieApplication { @Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } public static void main(String[] args) { SpringApplication.run(ConsumerMovieApplication.class, args); } }
剩下的在controller中使用restTemplate中使用即可。
五、Ribbon和Feign的區別
(1)啟動類使用的註解不同,Ribbon用的是@RibbonClient,Feign用的是@EnableFeignClients。
(2)服務的指定位置不同,Ribbon是在@RibbonClient註解上聲明,Feign則是在定義抽象方法的接口中使用@FeignClient聲明。
(3)調用方式不同,Ribbon需要自己構建http請求,模擬http請求然後使用RestTemplate發送給其他服務,步驟相當繁瑣。Feign則是在Ribbon的基礎上進行瞭一次改進,采用接口的方式,將需要調用的其他服務的方法定義成抽象方法即可,不需要自己構建http請求。不過要註意的是抽象方法的註解、方法簽名要和提供服務的方法完全一致。
到此這篇關於淺談SpringCloud之Ribbon的文章就介紹到這瞭,更多相關SpringCloud之Ribbon內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- SpringCloud筆記(Hoxton)Netflix之Ribbon負載均衡示例代碼
- spring cloud 集成 ribbon負載均衡的實例代碼
- Java之Springcloud Feign組件詳解
- Spring cloud alibaba之Ribbon負載均衡實現方案
- SpringCloud學習筆記之OpenFeign進行服務調用