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