Nacos Feign 客戶端
什麼是 Feign
Feign 是一個聲明式的僞 HTTP 客戶端，它使得寫 HTTP 客戶端變得更簡單。使用 Feign，只需要創建一個接口並註解。它具有可插拔的註解特性，可使用 Feign 註解和 JAX-RS 註解。Feign 支持可插拔的編碼器和解碼器。Feign 默認集成了 Ribbon，Nacos 也很好的兼容了 Feign，默認實現了負載均衡的效果
- Feign 採用的是基於接口的註解
- Feign 整合了 Ribbon
POM
在 hello-spring-cloud-alibaba-consumer 項目中增加 org.springframework.cloud:spring-cloud-starter-openfeign 依賴
是alibaba的feign 不要搞錯了,之前的feign停止維護了,版本自己斟酌一下
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
<version>2.1.3.RELEASE</version>
</dependency>
啓動項
增加@EnableFeignClients
@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
public class HelloSpringCloudAlibabaConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(HelloSpringCloudAlibabaConsumerApplication.class, args);
}
}
service
之後就可以在service層調用了
用法嘛~ 和之前一樣壓根沒變,controller層調用就好
@FeignClient(name = "service-provider")
@Service
public interface TestService {
@RequestMapping(value = "test/echo/{string}",method = RequestMethod.GET)
public String echo(@PathVariable("string") String string);
}
配置負載均衡(默認策略)
負載均衡組要是在做了提供方集羣之後需要配置的,這樣我們能讓,提供方分攤這些壓力,是不是很舒服.
先開起一個提供方,記住名字內容都要一樣
爲了方便測試可以把端口打印出來
同一個地址,由兩個集羣承擔
附：擴展閱讀
服務： 通過預定義接口網絡訪問的提供給客戶端的軟件功能
服務名： 服務提供的標識，通過該標識可以唯一確定其指代的服務
服務分組： 不同的服務可以歸類到同一分組
虛擬集羣： 同一個服務下的所有服務實例組成一個默認集羣，集羣可以被進一步按需求劃分，劃分的單位可以是虛擬集羣
實例： 提供一個或多個服務的具有可訪問網絡地址（IP:Port）的進程
權重： 實例級別的配置。權重爲浮點數。權重越大，分配給該實例的流量越大
健康保護閾值： 爲了防止因過多實例 (Instance)
不健康導致流量全部流向健康實例 (Instance) ，繼而造成流量壓力把健康 健康實例 (Instance) 壓垮並形成雪崩效應，應將健康保護閾值定義爲一個 0 到 1 之間的浮點數。當域名健康實例 (Instance) 佔總服務實例 (Instance) 的比例小於該值時，無論實例 (Instance) 是否健康，都會將這個實例 (Instance) 返回給客戶端。這樣做雖然損失了一部分流量，但是保證了集羣的剩餘健康實例 (Instance) 能正常工作
常見負載均衡策略
負載主機可以提供很多種負載均衡方法，也就是我們常說的調度方法或算法
輪循
Round Robin： 這種方法會將收到的請求循環分配到服務器集羣中的每臺機器，即有效服務器。如果使用這種方式，所有的標記進入虛擬服務的服務器應該有相近的資源容量 以及負載形同的應用程序。如果所有的服務器有相同或者相近的性能那麼選擇這種方式會使服務器負載形同。基於這個前提，輪循調度是一個簡單而有效的分配請求 的方式。然而對於服務器不同的情況，選擇這種方式就意味着能力比較弱的服務器也會在下一輪循環中接受輪循，即使這個服務器已經不能再處理當前這個請求了。 這可能導致能力較弱的服務器超載。
加權輪循
Weighted Round Robin： 這種算法解決了簡單輪循調度算法的缺點：傳入的請求按順序被分配到集羣中服務器，但是會考慮提前爲每臺服務器分配的權重。管理員只是簡單的通過服務 器的處理能力來定義各臺服務器的權重。例如，能力最強的服務器 A 給的權重是 100，同時能力最低的服務器給的權重是 50。這意味着在服務器 B 接收到第一個 請求之前前，服務器 A 會連續的接受到 2 個請求，以此類推。
最少連接數
Least Connection： 以上兩種方法都沒有考慮的是系統不能識別在給定的時間裏保持了多少連接。因此可能發生，服務器 B 服務器收到的連接比服務器 A 少但是它已經超載，因爲 服務器 B 上的用戶打開連接持續的時間更長。這就是說連接數即服務器的負載是累加的。這種潛在的問題可以通過 “最少連接數” 算法來避免：傳入的請求是根據每 臺服務器當前所打開的連接數來分配的。即活躍連接數最少的服務器會自動接收下一個傳入的請求。接本上和簡單輪詢的原則相同：所有擁有虛擬服務的服務器資源 容量應該相近。值得注意的是，在流量率低的配置環境中，各服務器的流量並不是相同的，會優先考慮第一臺服務器。這是因爲，如果所有的服務器是相同的，那麼 第一個服務器優先，直到第一臺服務器有連續的活躍流量，否則總是會優先選擇第一臺服務器。
最少連接數慢啓動時間
Least Connection Slow Start Time： 對最少連接數和帶權重的最小連接數調度方法來說，當一個服務器剛加入線上環境是，可以爲其配置一個時間段，在這段時間內連接數是有限制的而且是緩慢 增加的。這爲服務器提供了一個‘過渡時間’以保證這個服務器不會因爲剛啓動後因爲分配的連接數過多而超載。這個值在 L7 配置界面設置。
加權最少連接
Weighted Least Connection： 如果服務器的資源容量各不相同，那麼 “加權最少連接” 方法更合適：由管理員根據服務器情況定製的權重所決定的活躍連接數一般提供了一種對服務器非常 平衡的利用，因爲他它借鑑了最少連接和權重兩者的優勢。通常，這是一個非常公平的分配方式，因爲它使用了連接數和服務器權重比例；集羣中比例最低的服務器 自動接收下一個請求。但是請注意，在低流量情況中使用這種方法時，請參考 “最小連接數” 方法中的注意事項。
基於代理的自適應負載均衡
Agent Based Adaptive Balancing： 除了上述方法之外，負載主機包含一個自適用邏輯用來定時監測服務器狀態和該服務器的權重。對於非常強大的 “基於代理的自適應負載均衡” 方法來說，負 載主機以這種方式來定時檢測所有服務器負載情況：每臺服務器都必須提供一個包含文件，這個文件包含一個 0~99 的數字用來標明改服務器的實際負載情況 (0 = 空前，99 = 超載，101 = 失敗，102 = 管理員禁用)，而服務器同構 http get 方法來獲取這個文件；同時對集羣中服務器來說，以二進制文件形式提供自身負載情況也是該服務器工作之一，然而，並沒有限制服務器如何計算自身的負載 情況。根據服務器整體負載情況，有兩種策略可以選擇：在常規的操作中，調度算法通過收集的服務器負載值和分配給該服務器的連接數的比例計算出一個權重比 例。因此，如果一個服務器負載過大，權重會通過系統透明的作重新調整。和加權輪循調度方法一樣，不正確的分配可以被記錄下來使得可以有效的爲不同服務器分 配不同的權重。然而，在流量非常低的環境下，服務器報上來的負載值將不能建立一個有代表性的樣本；那麼基於這些值來分配負載的話將導致失控以及指令震盪。 因此，在這種情況下更合理的做法是基於靜態的權重比來計算負載分配。當所有服務器的負載低於管理員定義的下限時，負載主機就會自動切換爲加權輪循方式來分 配請求；如果負載大於管理員定義的下限，那麼負載主機又會切換回自適應方式。
固定權重
Fixed Weighted： 最高權重只有在其他服務器的權重值都很低時才使用。然而，如果最高權重的服務器下降，則下一個最高優先級的服務器將爲客戶端服務。這種方式中每個真實服務器的權重需要基於服務器優先級來配置。
加權響應
Weighted Response： 流量的調度是通過加權輪循方式。加權輪循中所使用的權重是根據服務器有效性檢測的響應時間來計算。每個有效性檢測都會被計時，用來標記它響應成功花 了多長時間。但是需要注意的是，這種方式假定服務器心跳檢測是基於機器的快慢，但是這種假設也許不總是能夠成立。所有服務器在虛擬服務上的響應時間的總和 加在一起，通過這個值來計算單個服務物理服務器的權重；這個權重值大約每 15 秒計算一次。
源 IP 哈希
Source IP Hash： 這種方式通過生成請求源 IP 的哈希值，並通過這個哈希值來找到正確的真實服務器。這意味着對於同一主機來說他對應的服務器總是相同。使用這種方式，你不需要保存任何源 IP。但是需要注意，這種方式可能導致服務器負載不平衡。