負載均衡

生產(chǎn)環(huán)境相對是?較惡劣的, 我們需要對服務(wù)的流量進?更加精細的控制. Nacos?持多種負載均衡策略, 包括權(quán)重, 同機房, 同地域, 同環(huán)境等.

服務(wù)下線

當某?個節(jié)點上接?的性能較差時, 我們可以第?時間對該節(jié)點進?下線.

操作步驟: 服務(wù)詳情 -> 下線

點擊下線后, 再次請求接?, 會發(fā)現(xiàn)該服務(wù)沒有請求進來了。再次單擊上線, 該節(jié)點會繼續(xù)收到請求。

下線之前

下線端口號為9091的服務(wù)進程之后：

權(quán)重配置

除了下線之外, 我們也可以配置這個節(jié)點的流量權(quán)重。

配置權(quán)重

操作步驟: 找到對應(yīng)節(jié)點 ->編輯 -> 在彈出的窗?修改權(quán)重值。

下面修改端口號為9091的服務(wù)進程的權(quán)重為0.1

觀察結(jié)果：

我們可以看到，三個服務(wù)實例接收到的請求次數(shù)幾乎一樣多，這是為什么呢？明明我們已經(jīng)配置了權(quán)重且比例稍微比較大，按理說應(yīng)該能看到現(xiàn)象。

是因為我們使用了LoadBalance，它本來就是負責負載均衡的，此時就不會使用Nacos的權(quán)重屬性進行負載均衡。

我們可以參考一下文章：

解決辦法

開啟Nacos負載均衡策略

application.properties

spring.cloud.loadbalancer.nacos.enabled=true

application.yml

spring:
  cloud:
    loadbalancer:
      nacos:
        enabled: true

觀察結(jié)果：

由此我們可以看到，我們設(shè)置的權(quán)重生效了。

常見問題

修改權(quán)重時, 可能會報錯：

報錯信息為：

caused: errCode: 500, errMsg: do metadata operation failed ;caused:com.alibaba.nacos.consistency.exception.ConsistencyException: The Raft Group[naming_instance_metadata] did not find the Leader node;caused: The Raft Group[naming_instance_metadata] did not find the Leader node;

原因: Nacos 采? raft 算法來計算 Leader, 并且會記錄前?次啟動的集群地址, 當服務(wù)器 IP 改變時會導致 raft 記錄的集群地址失效, 導致選 Leader 出現(xiàn)問題. (?絡(luò)環(huán)境發(fā)?變化時, IP地址也會發(fā)?變化)

解決辦法: 刪除 Nacos 根?錄下 data ?件夾下的 protocol ?件夾即可。

同集群優(yōu)先訪問

Nacos把同?個機房內(nèi)的實例, 劃分為?個集群. 所以同集群優(yōu)先訪問, 在?定程度上也可以理解為同房優(yōu)先訪問.微服務(wù)架構(gòu)中, ?個服務(wù)通常有多個實例共同提供服務(wù), 這些實例可以部署在不同的機器上, 這些機器可以分布在不同的機房, ?如product-service：

實例1: 分布在上海機房實例2: 分布在上海機房實例3: 分布在北京機房實例4: 分布在北京機房

微服務(wù)訪問時, 應(yīng)盡量訪問同機房的實例. 當本機房內(nèi)實例不可?時, 才訪問其他機房的實例。

?如order-service 在上海機房, product-service 在北京和上海機房都有實例, 那我們希望可以優(yōu)先訪問上海機房, 如果上海機房沒有實例, 或者實例不可?, 再訪問北京機房的實例. 通常情況下, 因為同?個機房的機器屬于?個局域?, 局域?訪問速度更快?點.

給實例配置集群名稱

1. 配置集群名稱

給order-service和端口號為9090的product-service配置 SH 集群名稱。

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 110.41.51.65:10020
        cluster-name: SH #集群名稱: 上海集群

給端口號為9091的product-service 和 端口號為9092的product-service配置 BJ 集群名稱。

開啟Nacos負載均衡策略

同權(quán)重配置

spring:
  cloud:
    nacos:
      loadbalancer:
        nacos:
          enabled: true

多次訪問“http://127.0.0.1:8080/order/1”

觀察結(jié)果：

我們前面配置order-service集群為 SH，配置端口號為9090的product-service集群為 SH，配置端口號為9091的product-service集群為 BJ，配置端口號為9092的product-service集群為 BJ。

上面的結(jié)果可以看到，請求都發(fā)送到了端口號為9090的product-service集群，與預期符合。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論