Nacos Feign 客戶端
什么是 Feign
Feign 是一個(gè)聲明式的偽 HTTP 客戶端，它使得寫 HTTP 客戶端變得更簡單。使用 Feign，只需要?jiǎng)?chuàng)建一個(gè)接口并注解。它具有可插拔的注解特性，可使用 Feign 注解和 JAX-RS 注解。Feign 支持可插拔的編碼器和解碼器。Feign 默認(rèn)集成了 Ribbon，Nacos 也很好的兼容了 Feign，默認(rèn)實(shí)現(xiàn)了負(fù)載均衡的效果
- Feign 采用的是基于接口的注解
- Feign 整合了 Ribbon
POM
在 hello-spring-cloud-alibaba-consumer 項(xiàng)目中增加 org.springframework.cloud:spring-cloud-starter-openfeign 依賴
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
Application
通過 @EnableFeignClients 注解開啟 Feign 功能
package com.funtl.spring.cloud.alibaba.consumer;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.openfeign.EnableFeignClients;
@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
public class ConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerApplication.class, args);
}
}
Service
創(chuàng)建業(yè)務(wù)結(jié)構(gòu)，通過 @FeignClient("服務(wù)名") 注解來指定調(diào)用哪個(gè)服務(wù)
package com.funtl.spring.cloud.alibaba.consumer.service;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
@FeignClient(value = "service-provider")
public interface EchoService {
@GetMapping(value = "/echo/{string}")
String echo(@PathVariable("string") String string);
}
Controller
package com.funtl.spring.cloud.alibaba.consumer.controller;
import com.funtl.spring.cloud.alibaba.consumer.service.EchoService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class TestEchoController {
@Autowired
private EchoService echoService;
@GetMapping(value = "/feign/echo/{str}")
public String echo(@PathVariable String str) {
return echoService.echo(str);
}
}
驗(yàn)證是否成功
通過瀏覽器訪問 http://localhost:8080/feign/echo/hi
Hello Nacos Provider hi
配置負(fù)載均衡
- 修改
service-provider服務(wù)的端口號(hào)如 8071，并啟動(dòng)多個(gè)實(shí)例，IDEA 中依次點(diǎn)擊 Run -> Edit Configurations 并勾選 Allow parallel run 以允許 IDEA 多實(shí)例運(yùn)行項(xiàng)目
- 再次啟動(dòng)
service-provider實(shí)例，IDEA Spring Boot 面板可以看到
- Nacos Server 控制臺(tái)可以看到
service-provider有 2 個(gè)實(shí)例
服務(wù)： 通過預(yù)定義接口網(wǎng)絡(luò)訪問的提供給客戶端的軟件功能
服務(wù)名： 服務(wù)提供的標(biāo)識(shí)，通過該標(biāo)識(shí)可以唯一確定其指代的服務(wù)
服務(wù)分組： 不同的服務(wù)可以歸類到同一分組
虛擬集群： 同一個(gè)服務(wù)下的所有服務(wù)實(shí)例組成一個(gè)默認(rèn)集群，集群可以被進(jìn)一步按需求劃分，劃分的單位可以是虛擬集群
實(shí)例： 提供一個(gè)或多個(gè)服務(wù)的具有可訪問網(wǎng)絡(luò)地址（IP:Port）的進(jìn)程
權(quán)重： 實(shí)例級(jí)別的配置。權(quán)重為浮點(diǎn)數(shù)。權(quán)重越大，分配給該實(shí)例的流量越大
健康保護(hù)閾值： 為了防止因過多實(shí)例 (Instance) 不健康導(dǎo)致流量全部流向健康實(shí)例 (Instance) ，繼而造成流量壓力把健康 健康實(shí)例 (Instance) 壓垮并形成雪崩效應(yīng)，應(yīng)將健康保護(hù)閾值定義為一個(gè) 0 到 1 之間的浮點(diǎn)數(shù)。當(dāng)域名健康實(shí)例 (Instance) 占總服務(wù)實(shí)例 (Instance) 的比例小于該值時(shí)，無論實(shí)例 (Instance) 是否健康，都會(huì)將這個(gè)實(shí)例 (Instance) 返回給客戶端。這樣做雖然損失了一部分流量，但是保證了集群的剩余健康實(shí)例 (Instance) 能正常工作
- 在
service-provider項(xiàng)目的EchoController中增加測試方法
@Value("${server.port}")
private String port;
@GetMapping(value = "/lb")
public String lb() {
return "Hello Nacos Provider i am from port: " + port;
}
- 在
service-consumer項(xiàng)目的EchoService中增加測試方法
@GetMapping(value = "/lb")
String lb();
- 在
service-consumer項(xiàng)目的TestEchoController中增加測試方法
@GetMapping(value = "/lb")
public String lb() {
return echoService.lb();
}
- 重啟服務(wù)，通過瀏覽器訪問 http://localhost:8080/lb ，反復(fù)刷新瀏覽器，瀏覽器交替顯示
Hello Nacos Provider i am from port: 8070
Hello Nacos Provider i am from port: 8071
附：擴(kuò)展閱讀
常見負(fù)載均衡策略
負(fù)載主機(jī)可以提供很多種負(fù)載均衡方法，也就是我們常說的調(diào)度方法或算法
輪循
Round Robin： 這種方法會(huì)將收到的請(qǐng)求循環(huán)分配到服務(wù)器集群中的每臺(tái)機(jī)器，即有效服務(wù)器。如果使用這種方式，所有的標(biāo)記進(jìn)入虛擬服務(wù)的服務(wù)器應(yīng)該有相近的資源容量 以及負(fù)載形同的應(yīng)用程序。如果所有的服務(wù)器有相同或者相近的性能那么選擇這種方式會(huì)使服務(wù)器負(fù)載形同?；谶@個(gè)前提，輪循調(diào)度是一個(gè)簡單而有效的分配請(qǐng)求 的方式。然而對(duì)于服務(wù)器不同的情況，選擇這種方式就意味著能力比較弱的服務(wù)器也會(huì)在下一輪循環(huán)中接受輪循，即使這個(gè)服務(wù)器已經(jīng)不能再處理當(dāng)前這個(gè)請(qǐng)求了。 這可能導(dǎo)致能力較弱的服務(wù)器超載。
加權(quán)輪循
Weighted Round Robin： 這種算法解決了簡單輪循調(diào)度算法的缺點(diǎn)：傳入的請(qǐng)求按順序被分配到集群中服務(wù)器，但是會(huì)考慮提前為每臺(tái)服務(wù)器分配的權(quán)重。管理員只是簡單的通過服務(wù) 器的處理能力來定義各臺(tái)服務(wù)器的權(quán)重。例如，能力最強(qiáng)的服務(wù)器 A 給的權(quán)重是 100，同時(shí)能力最低的服務(wù)器給的權(quán)重是 50。這意味著在服務(wù)器 B 接收到第一個(gè) 請(qǐng)求之前前，服務(wù)器 A 會(huì)連續(xù)的接受到 2 個(gè)請(qǐng)求，以此類推。
最少連接數(shù)
Least Connection： 以上兩種方法都沒有考慮的是系統(tǒng)不能識(shí)別在給定的時(shí)間里保持了多少連接。因此可能發(fā)生，服務(wù)器 B 服務(wù)器收到的連接比服務(wù)器 A 少但是它已經(jīng)超載，因?yàn)?服務(wù)器 B 上的用戶打開連接持續(xù)的時(shí)間更長。這就是說連接數(shù)即服務(wù)器的負(fù)載是累加的。這種潛在的問題可以通過 “最少連接數(shù)” 算法來避免：傳入的請(qǐng)求是根據(jù)每 臺(tái)服務(wù)器當(dāng)前所打開的連接數(shù)來分配的。即活躍連接數(shù)最少的服務(wù)器會(huì)自動(dòng)接收下一個(gè)傳入的請(qǐng)求。接本上和簡單輪詢的原則相同：所有擁有虛擬服務(wù)的服務(wù)器資源 容量應(yīng)該相近。值得注意的是，在流量率低的配置環(huán)境中，各服務(wù)器的流量并不是相同的，會(huì)優(yōu)先考慮第一臺(tái)服務(wù)器。這是因?yàn)?，如果所有的服?wù)器是相同的，那么 第一個(gè)服務(wù)器優(yōu)先，直到第一臺(tái)服務(wù)器有連續(xù)的活躍流量，否則總是會(huì)優(yōu)先選擇第一臺(tái)服務(wù)器。
源 IP 哈希
Source IP Hash： 這種方式通過生成請(qǐng)求源 IP 的哈希值，并通過這個(gè)哈希值來找到正確的真實(shí)服務(wù)器。這意味著對(duì)于同一主機(jī)來說他對(duì)應(yīng)的服務(wù)器總是相同。使用這種方式，你不需要保存任何源 IP。但是需要注意，這種方式可能導(dǎo)致服務(wù)器負(fù)載不平衡。
最少連接數(shù)慢啟動(dòng)時(shí)間
Least Connection Slow Start Time： 對(duì)最少連接數(shù)和帶權(quán)重的最小連接數(shù)調(diào)度方法來說，當(dāng)一個(gè)服務(wù)器剛加入線上環(huán)境是，可以為其配置一個(gè)時(shí)間段，在這段時(shí)間內(nèi)連接數(shù)是有限制的而且是緩慢 增加的。這為服務(wù)器提供了一個(gè)‘過渡時(shí)間’以保證這個(gè)服務(wù)器不會(huì)因?yàn)閯倖?dòng)后因?yàn)榉峙涞倪B接數(shù)過多而超載。這個(gè)值在 L7 配置界面設(shè)置。
加權(quán)最少連接
Weighted Least Connection： 如果服務(wù)器的資源容量各不相同，那么 “加權(quán)最少連接” 方法更合適：由管理員根據(jù)服務(wù)器情況定制的權(quán)重所決定的活躍連接數(shù)一般提供了一種對(duì)服務(wù)器非常 平衡的利用，因?yàn)樗梃b了最少連接和權(quán)重兩者的優(yōu)勢。通常，這是一個(gè)非常公平的分配方式，因?yàn)樗褂昧诉B接數(shù)和服務(wù)器權(quán)重比例；集群中比例最低的服務(wù)器 自動(dòng)接收下一個(gè)請(qǐng)求。但是請(qǐng)注意，在低流量情況中使用這種方法時(shí)，請(qǐng)參考 “最小連接數(shù)” 方法中的注意事項(xiàng)。
基于代理的自適應(yīng)負(fù)載均衡
Agent Based Adaptive Balancing： 除了上述方法之外，負(fù)載主機(jī)包含一個(gè)自適用邏輯用來定時(shí)監(jiān)測服務(wù)器狀態(tài)和該服務(wù)器的權(quán)重。對(duì)于非常強(qiáng)大的 “基于代理的自適應(yīng)負(fù)載均衡” 方法來說，負(fù) 載主機(jī)以這種方式來定時(shí)檢測所有服務(wù)器負(fù)載情況：每臺(tái)服務(wù)器都必須提供一個(gè)包含文件，這個(gè)文件包含一個(gè) 0~99 的數(shù)字用來標(biāo)明改服務(wù)器的實(shí)際負(fù)載情況 (0 = 空前，99 = 超載，101 = 失敗，102 = 管理員禁用)，而服務(wù)器同構(gòu) http get 方法來獲取這個(gè)文件；同時(shí)對(duì)集群中服務(wù)器來說，以二進(jìn)制文件形式提供自身負(fù)載情況也是該服務(wù)器工作之一，然而，并沒有限制服務(wù)器如何計(jì)算自身的負(fù)載 情況。根據(jù)服務(wù)器整體負(fù)載情況，有兩種策略可以選擇：在常規(guī)的操作中，調(diào)度算法通過收集的服務(wù)器負(fù)載值和分配給該服務(wù)器的連接數(shù)的比例計(jì)算出一個(gè)權(quán)重比 例。因此，如果一個(gè)服務(wù)器負(fù)載過大，權(quán)重會(huì)通過系統(tǒng)透明的作重新調(diào)整。和加權(quán)輪循調(diào)度方法一樣，不正確的分配可以被記錄下來使得可以有效的為不同服務(wù)器分 配不同的權(quán)重。然而，在流量非常低的環(huán)境下，服務(wù)器報(bào)上來的負(fù)載值將不能建立一個(gè)有代表性的樣本；那么基于這些值來分配負(fù)載的話將導(dǎo)致失控以及指令震蕩。 因此，在這種情況下更合理的做法是基于靜態(tài)的權(quán)重比來計(jì)算負(fù)載分配。當(dāng)所有服務(wù)器的負(fù)載低于管理員定義的下限時(shí)，負(fù)載主機(jī)就會(huì)自動(dòng)切換為加權(quán)輪循方式來分 配請(qǐng)求；如果負(fù)載大于管理員定義的下限，那么負(fù)載主機(jī)又會(huì)切換回自適應(yīng)方式。
固定權(quán)重
Fixed Weighted： 最高權(quán)重只有在其他服務(wù)器的權(quán)重值都很低時(shí)才使用。然而，如果最高權(quán)重的服務(wù)器下降，則下一個(gè)最高優(yōu)先級(jí)的服務(wù)器將為客戶端服務(wù)。這種方式中每個(gè)真實(shí)服務(wù)器的權(quán)重需要基于服務(wù)器優(yōu)先級(jí)來配置。
加權(quán)響應(yīng)
Weighted Response： 流量的調(diào)度是通過加權(quán)輪循方式。加權(quán)輪循中所使用的權(quán)重是根據(jù)服務(wù)器有效性檢測的響應(yīng)時(shí)間來計(jì)算。每個(gè)有效性檢測都會(huì)被計(jì)時(shí)，用來標(biāo)記它響應(yīng)成功花 了多長時(shí)間。但是需要注意的是，這種方式假定服務(wù)器心跳檢測是基于機(jī)器的快慢，但是這種假設(shè)也許不總是能夠成立。所有服務(wù)器在虛擬服務(wù)上的響應(yīng)時(shí)間的總和 加在一起，通過這個(gè)值來計(jì)算單個(gè)服務(wù)物理服務(wù)器的權(quán)重；這個(gè)權(quán)重值大約每 15 秒計(jì)算一次。
