淺談SpringCloud之Ribbon詳解

目錄

一、什么是負載均衡

負載均衡：建立在現有網(wǎng)絡(luò )結構之上，它提供了一種廉價(jià)有效透明的方法擴展網(wǎng)絡(luò )設備和服務(wù)器的帶寬、增加吞吐量、加強網(wǎng)絡(luò )數據處理能力、提高網(wǎng)絡(luò )的靈活性和可用性。

現在網(wǎng)站的架構已經(jīng)從C/S模式轉變?yōu)锽/S模式，C/S模式是有一個(gè)專(zhuān)門(mén)的客戶(hù)端，而B(niǎo)/S模式是將瀏覽器作為客戶(hù)端。當用戶(hù)在瀏覽器上輸入一個(gè)網(wǎng)址按下回車(chē)鍵后，就會(huì )產(chǎn)生一個(gè)請求，在遠方的服務(wù)器會(huì )處理這個(gè)請求，根據這個(gè)請求來(lái)生成用戶(hù)想要的頁(yè)面，然后將這個(gè)頁(yè)面響應給瀏覽器，這樣用戶(hù)就能看到他想要看到的東西。我們知道，一臺服務(wù)器處理數據（請求也是一種數據）的能力是有限的，當有大量的用戶(hù)同時(shí)在瀏覽器上輸入網(wǎng)址并按下回車(chē)鍵后，就會(huì )有大量的請求產(chǎn)生，遠方的服務(wù)器就不得不處理這些請求，由于請求數量過(guò)多，服務(wù)器處理的效率就會(huì )變慢，響應時(shí)間就會(huì )變長(cháng)，這樣用戶(hù)就不能在可以忍受的時(shí)間內看到自己想看到的東西，嚴重影響體驗效果。更嚴重一點(diǎn)，如果請求數量超過(guò)了這臺服務(wù)器所能處理的最大請求，服務(wù)器就會(huì )崩潰，直接導致網(wǎng)站癱瘓。

那么，有什么方法能夠解決這個(gè)問(wèn)題呢？答案就是建立一個(gè)集群（就是一群服務(wù)器），通過(guò)集群的力量來(lái)提高服務(wù)端的數據處理能力，因為一臺服務(wù)器的處理能力肯定比不上多臺服務(wù)器的處理能力。

這樣我們在來(lái)描述一下用戶(hù)請求頁(yè)面的過(guò)程：首先用戶(hù)在瀏覽器輸入網(wǎng)址并按下回車(chē)鍵，然后會(huì )產(chǎn)生一個(gè)請求，遠方的服務(wù)器會(huì )處理這個(gè)請求…等等，現在遠方有很多服務(wù)器，到底哪個(gè)服務(wù)器來(lái)處理這個(gè)請求呢，總不能所有的服務(wù)器都處理這個(gè)請求吧。哪個(gè)服務(wù)器處理這個(gè)請求？大家明白了吧，這就是負載均衡所要解決的問(wèn)題?；氐缴线呎埱箜?yè)面的過(guò)程，這個(gè)請求此時(shí)會(huì )被一臺專(zhuān)門(mén)的服務(wù)器來(lái)處理，這臺服務(wù)器其實(shí)就是個(gè)集群的老大，他負責把這個(gè)請求派給下面哪個(gè)小弟（服務(wù)器）來(lái)處理，處理完之后返回頁(yè)面用戶(hù)。當有多個(gè)請求同時(shí)發(fā)生時(shí)，集群的老大可以將請求派給不同的小弟，這樣處理的效率就會(huì )大幅提升，充分發(fā)揮集群的力量，至于哪個(gè)請求到底派給哪個(gè)小弟，這就是調度策略的問(wèn)題了。

二、實(shí)現負載均衡的三種方式

（1）HTTP重定向實(shí)現負載均衡

利用HTTP重定向協(xié)議實(shí)現負載均衡大概工作原理如下圖：

HTTP重定向服務(wù)器是一臺普通的應用服務(wù)器，其唯一個(gè)功能就是根據用戶(hù)的HTTP請求計算出一臺真實(shí)的服務(wù)器地址，并將該服務(wù)器地址寫(xiě)入HTTP重定向響應中（重定向響應狀態(tài)碼為302）返回給用戶(hù)瀏覽器。用戶(hù)瀏覽器在獲取到響應之后，根據返回的信息，重新發(fā)送一個(gè)請求到真實(shí)的服務(wù)器上。如上圖所示，瀏覽器訪(fǎng)問(wèn)，DNS服務(wù)器解析到IP地址為114.100.20.200，即HTTP重定向服務(wù)器的IP地址。重定向服務(wù)器計根據某種負載均衡算法算出真實(shí)的服務(wù)器地址為114.100.20.203并返回給用戶(hù)瀏覽器，用戶(hù)瀏覽器得到返回后重新對114.100.20.203發(fā)起了請求，最后完成訪(fǎng)問(wèn)。
這種負載均衡方案的有點(diǎn)是比較簡(jiǎn)單，缺點(diǎn)是瀏覽器需要兩次請求服務(wù)器才能完成一次訪(fǎng)問(wèn)，性能較差；同時(shí)，重定向服務(wù)器本身的處理能力有可能成為瓶頸，整個(gè)集群的伸縮性規模有限；使用HTTP返回碼302重定向，有可能使搜索引擎判斷為SEO作弊，降低搜索排名。因此實(shí)踐中很少使用這種負載均衡方案來(lái)部署。

（2）DNS負載均衡

DNS（Domain Name System）是因特網(wǎng)的一項服務(wù)，它作為域名和IP地址相互映射的一個(gè)分布式數據庫，能夠使人更方便的訪(fǎng)問(wèn)互聯(lián)網(wǎng)。人們在通過(guò)瀏覽器訪(fǎng)問(wèn)網(wǎng)站時(shí)只需要記住網(wǎng)站的域名即可，而不需要記住那些不太容易理解的IP地址。在DNS系統中有一個(gè)比較重要的的資源類(lèi)型叫做主機記錄也稱(chēng)為A記錄，A記錄是用于名稱(chēng)解析的重要記錄，它將特定的主機名映射到對應主機的IP地址上。如果你有一個(gè)自己的域名，那么要想別人能訪(fǎng)問(wèn)到你的網(wǎng)站，你需要到特定的DNS解析服務(wù)商的服務(wù)器上填寫(xiě)A記錄，過(guò)一段時(shí)間后，別人就能通過(guò)你的域名訪(fǎng)問(wèn)你的網(wǎng)站了。DNS除了能解析域名之外還具有負載均衡的功能，下面是利用DNS工作原理處理負載均衡的工作原理圖：

由上圖可以看出，在DNS服務(wù)器中應該配置了多個(gè)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;

因此，每次域名解析請求都會(huì )根據對應的負載均衡算法計算出一個(gè)不同的IP地址并返回，這樣A記錄中配置多個(gè)服務(wù)器就可以構成一個(gè)集群，并可以實(shí)現負載均衡。上圖中，用戶(hù)請求，DNS根據A記錄和負載均衡算法計算得到一個(gè)IP地址114.100.20.203，并返回給瀏覽器，瀏覽器根據該IP地址，訪(fǎng)問(wèn)真實(shí)的物理服務(wù)器114.100.20.203。所有這些操作對用戶(hù)來(lái)說(shuō)都是透明的，用戶(hù)可能只知道www.apusapp.com這個(gè)域名。

DNS域名解析負載均衡有如下優(yōu)點(diǎn)：

1.將負載均衡的工作交給DNS，省去了網(wǎng)站管理維護負載均衡服務(wù)器的麻煩。

2.技術(shù)實(shí)現比較靈活、方便，簡(jiǎn)單易行，成本低，使用于大多數TCP/IP應用。

3.對于部署在服務(wù)器上的應用來(lái)說(shuō)不需要進(jìn)行任何的代碼修改即可實(shí)現不同機器上的應用訪(fǎng)問(wèn)。

4.服務(wù)器可以位于互聯(lián)網(wǎng)的任意位置。

5.同時(shí)許多DNS還支持基于地理位置的域名解析，即會(huì )將域名解析成距離用戶(hù)地理最近的一個(gè)服務(wù)器地址，這樣就可以加速用戶(hù)訪(fǎng)問(wèn)，改善性能。

同時(shí)，DNS域名解析也存在如下缺點(diǎn)：

1.目前的DNS是多級解析的，每一級DNS都可能緩存A記錄，當某臺服務(wù)器下線(xiàn)之后，即使修改了A記錄，要使其生效也需要較長(cháng)的時(shí)間，這段時(shí)間，DNS任然會(huì )將域名解析到已下線(xiàn)的服務(wù)器上，最終導致用戶(hù)訪(fǎng)問(wèn)失敗。

2.不能夠按服務(wù)器的處理能力來(lái)分配負載。DNS負載均衡采用的是簡(jiǎn)單的輪詢(xún)算法，不能區分服務(wù)器之間的差異，不能反映服務(wù)器當前運行狀態(tài)，所以其的負載均衡效果并不是太好。

3.可能會(huì )造成額外的網(wǎng)絡(luò )問(wèn)題。為了使本DNS服務(wù)器和其他DNS服務(wù)器及時(shí)交互，保證DNS數據及時(shí)更新，使地址能隨機分配，一般都要將DNS的刷新時(shí)間設置的較小，但太小將會(huì )使DNS流量大增造成額外的網(wǎng)絡(luò )問(wèn)題。
事實(shí)上，大型網(wǎng)站總是部分使用DNS域名解析，利用域名解析作為第一級負載均衡手段，即域名解析得到的一組服務(wù)器并不是實(shí)際提供服務(wù)的物理服務(wù)器，而是同樣提供負載均衡服務(wù)器的內部服務(wù)器，這組內部負載均衡服務(wù)器再進(jìn)行負載均衡，請請求發(fā)到真實(shí)的服務(wù)器上，最終完成請求。

（3）反向代理負載均衡

請求過(guò)程：

用戶(hù)發(fā)來(lái)的請求都首先要經(jīng)過(guò)反向代理服務(wù)器，服務(wù)器根據用戶(hù)的請求要么直接將結果返回給用戶(hù)，要么將請求交給后端服務(wù)器處理，再返回給用戶(hù)。

反向代理負載均衡

優(yōu)點(diǎn)：

隱藏后端服務(wù)器。與HTTP重定向相比，反向代理能夠隱藏后端服務(wù)器，所有瀏覽器都不會(huì )與后端服務(wù)器直接交互，從而能夠確保調度者的控制權，提升集群的整體性能。

故障轉移。與DNS負載均衡相比，反向代理能夠更快速地移除故障結點(diǎn)。當監控程序發(fā)現某一后端服務(wù)器出現故障時(shí)，能夠及時(shí)通知反向代理服務(wù)器，并立即將其刪除。

合理分配任務(wù) 。HTTP重定向和DNS負載均衡都無(wú)法實(shí)現真正意義上的負載均衡，也就是調度服務(wù)器無(wú)法根據后端服務(wù)器的實(shí)際負載情況分配任務(wù)。但反向代理服務(wù)器支持手動(dòng)設定每臺后端服務(wù)器的權重。我們可以根據服務(wù)器的配置設置不同的權重，權重的不同會(huì )導致被調度者選中的概率的不同。
缺點(diǎn)：

調度者壓力過(guò)大 。由于所有的請求都先由反向代理服務(wù)器處理，那么當請求量超過(guò)調度服務(wù)器的最大負載時(shí)，調度服務(wù)器的吞吐率降低會(huì )直接降低集群的整體性能。

制約擴展。當后端服務(wù)器也無(wú)法滿(mǎn)足巨大的吞吐量時(shí)，就需要增加后端服務(wù)器的數量，可沒(méi)辦法無(wú)限量地增加，因為會(huì )受到調度服務(wù)器的最大吞吐量的制約。

三、Ribbon簡(jiǎn)介

Spring Cloud Ribbon是一個(gè)基于HTTP和TCP的客戶(hù)端負載均衡工具，它基于Netflix Ribbon實(shí)現。通過(guò)Spring Cloud的封裝，可以讓我們輕松地將面向服務(wù)的REST模版請求自動(dòng)轉換成客戶(hù)端負載均衡的服務(wù)調用。Spring Cloud Ribbon雖然只是一個(gè)工具類(lèi)框架，它不像服務(wù)注冊中心、配置中心、API網(wǎng)關(guān)那樣需要獨立部署，但是它幾乎存在于每一個(gè)Spring Cloud構建的微服務(wù)和基礎設施中。因為微服務(wù)間的調用，API網(wǎng)關(guān)的請求轉發(fā)等內容，實(shí)際上都是通過(guò)Ribbon來(lái)實(shí)現的，包括Feign，它也是基于Ribbon實(shí)現的工具。所以，對Spring Cloud Ribbon的理解和使用，對于我們使用Spring Cloud來(lái)構建微服務(wù)非常重要。

Ribbon是Netflix發(fā)布的負載均衡器，它有助于控制HTTP和TCP的客戶(hù)端的行為。為Ribbon配置服務(wù)提供者地址后，Ribbon就可基于某種負載均衡算法，自動(dòng)地幫助服務(wù)消費者去請求。Ribbon默認為我們提供了很多負載均衡算法，例如輪詢(xún)、隨機等。當然，我們也可為Ribbon實(shí)現自定義的負載均衡算法。

四、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）啟動(dòng)類(lèi)使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。

（2）服務(wù)的指定位置不同，Ribbon是在@RibbonClient注解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。

（3）調用方式不同，Ribbon需要自己構建http請求，模擬http請求然后使用RestTemplate發(fā)送給其他服務(wù)，步驟相當繁瑣。Feign則是在Ribbon的基礎上進(jìn)行了一次改進(jìn)，采用接口的方式，將需要調用的其他服務(wù)的方法定義成抽象方法即可，不需要自己構建http請求。不過(guò)要注意的是抽象方法的注解、方法簽名要和提供服務(wù)的方法完全一致。

到此這篇關(guān)于淺談SpringCloud之Ribbon的文章就介紹到這了,更多相關(guān)SpringCloud之Ribbon內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！