1. 在 idea 上運行多個服務(wù)

在上面的遠(yuǎn)程調(diào)用的代碼中是根據(jù)應(yīng)用名稱獲取到了服務(wù)實例列表，從列表中選擇了一個服務(wù)實例，如果說一個服務(wù)對應(yīng)多個實例該怎么分配呢，例如上面的 product-service 配置的是 9090 端口號，如果再想開啟一個product-service 的服務(wù)，那么就需要把原來的服務(wù)停止掉再開啟，接下來演示一下不修改代碼的條件下如何開啟多個服務(wù)：

首先點擊 idea 中的 service 選項

把剛剛啟動的服務(wù)添加到列表

然后再復(fù)制出來一份應(yīng)用

重命名應(yīng)用名稱之后配置端口號：

添加之后再右鍵 9091 的服務(wù)再配置一個 9092 的服務(wù)

然后右鍵把新復(fù)制的服務(wù)都啟動

啟動成功之后注冊中心的 product-service 就有了三個實例

2. 問題引入

在進(jìn)行獲取服務(wù)時發(fā)現(xiàn)每次獲取到的實例并不是均衡的，原因就是每一次從 eureka 中獲取的服務(wù)列表中實例的順序可能是不一樣的，上面的 product-service 服務(wù)的三個端口號是 9090, 9091, 9092，每次獲取到的順序可能不一樣，在之前的代碼中是通過 get(0) 來獲取實例列表中的第一個實例，也就需要對之前寫的代碼進(jìn)行修改

我們期望是按照順序來依次獲取服務(wù)，也就是一個 獲取次數(shù)%實例數(shù) 的關(guān)系，那么首先需要一個計數(shù)器來計算當(dāng)前是第幾次請求，此外還需要固定獲取到的實例列表中的順序（也就是無論后面發(fā)起幾次請求，獲取到的實例列表都是一樣的）

根據(jù)上面的分析來修改一下代碼：

之后再重新啟動服務(wù)進(jìn)行遠(yuǎn)程調(diào)用，實例按照均衡的順序被調(diào)用

在上面的代碼中是把初始化的部分固定了，也是有些不合理的，如果之后再新增實例的話就沒有辦法保持同步

3. 負(fù)載均衡

負(fù)載均衡是高并發(fā)、高可用系統(tǒng)必不可少的關(guān)鍵組件。當(dāng)服務(wù)流量增大時，通常會采用增加機器的方式進(jìn)行擴容，負(fù)載均衡就是用來在多個機器或者其他資源中，按照一定的規(guī)則合理分配負(fù)載。

上面的例子中，只是簡單地對實例進(jìn)行了輪詢，但真實的業(yè)務(wù)場景會更加復(fù)雜。比如根據(jù)機器的配置進(jìn)行負(fù)載分配，配置高的分配的流量高，配置低的分配流量低等。

負(fù)載均衡又可以分為服務(wù)端負(fù)載均衡和客戶端負(fù)載均衡，上面的代碼中就是在客戶端進(jìn)行負(fù)載均衡，來合理的分配訪問服務(wù)器

服務(wù)端負(fù)載均衡就是在服務(wù)端進(jìn)行負(fù)載均衡的算法分配，請求先到達(dá)負(fù)載均衡器，然后通過負(fù)載均衡算法，在多個服務(wù)器之間選擇一個進(jìn)行訪問。

4. Spring Cloud LoadBalancer

Spring Cloud LoadBalancer 用于在微服務(wù)架構(gòu)中實現(xiàn)客戶端負(fù)載均衡，接下來看如何使用：

在原來的 RestTemplate 的 Bean 中加上@LoadBalanced注解

@Configuration
public class BeanConfig {
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

在遠(yuǎn)程調(diào)用的代碼中把 IP 和端口號改為服務(wù)名稱

public OrderInfo selectOrderById(Integer orderId){
    OrderInfo orderInfo = orderMapper.selectOrderById(orderId);
    String url = "http://product-service/product/" + orderInfo.getProductId();
    log.info("遠(yuǎn)程調(diào)用url = {}",url);
    ProductInfo productInfo = restTemplate.getForObject(url, ProductInfo.class);
    orderInfo.setProductInfo(productInfo);
    return orderInfo;
}

然后再去發(fā)起請求

可以看出，請求都被均衡的分配到了每一個服務(wù)上

5. 負(fù)載均衡策略

Spring Cloud LoadBalancer 僅支持兩種負(fù)載均衡策略：輪詢策略和隨機策略，輪詢就是之前演示的按照順序輪流進(jìn)行分配，隨機策略就是隨機分配

官網(wǎng)中給出了切換負(fù)載均衡策略的方式：

Spring Cloud LoadBalancer :: Spring Cloud Commons

這里需要注意的是配置類不能被@Configuration修飾，并且不能超出組件的掃描范圍

把官方給的配置類復(fù)制一下

這里導(dǎo)入的包是 springframework 中的

由于遠(yuǎn)程調(diào)用用的是 RestTemplate ，所以要在 RestTemplate 的配置類中加上@LoadBalancerClient注解，并且指明是對哪個客戶端生效以及采用的負(fù)載均衡策略

配置好之后再去請求就會發(fā)現(xiàn)此時每一個 product-service 被分配的請求是不一樣的，也是達(dá)到了一個隨機的效果

6. 部署到云服務(wù)器

分別把 eureka-server，order-service，product-service 打包，上傳到云服務(wù)器中，然后采用后臺啟動的方式分別啟動這三個服務(wù)，并指定日志輸出路徑：

nohup java -jar eureka-server.jar >logs/eureka.log &

接著，由于需要測試負(fù)載均衡，再開啟兩個 product-service 服務(wù)，指定不同的端口號：

nohup java -jar product-service.jar --server.port=9091>logs/product-9091.log &

到此這篇關(guān)于Spring Cloud LoadBalancer 負(fù)載均衡的文章就介紹到這了,更多相關(guān)Spring Cloud LoadBalancer 負(fù)載均衡內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論