Feign 是壹個聲明式的偽 HTTP 客戶端，它使得寫 HTTP 客戶端變得更簡單。使用 Feign，只需要創建壹個接口並註解。它具有可插拔的註解特性，可使用 Feign 註解和 JAX-RS 註解。Feign 支持可插拔的編碼器和解碼器。Feign 默認集成了 Ribbon，Nacos 也很好的兼容了 Feign，默認實現了負載均衡的效果
在 hello-spring-cloud-alibaba-consumer 項目中增加 org.springframework.cloud:spring-cloud-starter-openfeign 依賴
通過 @EnableFeignClients 註解開啟 Feign 功能
創建業務結構，通過 @FeignClient("服務名") 註解來指定調用哪個服務
通過瀏覽器訪問 http://localhost:8080/feign/echo/hi
負載主機可以提供很多種負載均衡方法，也就是我們常說的調度方法或算法
Round Robin： 這種方法會將收到的請求循環分配到服務器集群中的每臺機器，即有效服務器。如果使用這種方式，所有的標記進入虛擬服務的服務器應該有相近的資源容量 以及負載形同的應用程序。如果所有的服務器有相同或者相近的性能那麽選擇這種方式會使服務器負載形同。基於這個前提，輪循調度是壹個簡單而有效的分配請求 的方式。然而對於服務器不同的情況，選擇這種方式就意味著能力比較弱的服務器也會在下壹輪循環中接受輪循，即使這個服務器已經不能再處理當前這個請求了。 這可能導致能力較弱的服務器超載。
Weighted Round Robin： 這種算法解決了簡單輪循調度算法的缺點：傳入的請求按順序被分配到集群中服務器，但是會考慮提前為每臺服務器分配的權重。管理員只是簡單的通過服務 器的處理能力來定義各臺服務器的權重。例如，能力最強的服務器 A 給的權重是 100，同時能力最低的服務器給的權重是 50。這意味著在服務器 B 接收到第壹個 請求之前前，服務器 A 會連續的接受到 2 個請求，以此類推。
Least Connection： 以上兩種方法都沒有考慮的是系統不能識別在給定的時間裏保持了多少連接。因此可能發生，服務器 B 服務器收到的連接比服務器 A 少但是它已經超載，因為 服務器 B 上的用戶打開連接持續的時間更長。這就是說連接數即服務器的負載是累加的。這種潛在的問題可以通過 “最少連接數” 算法來避免：傳入的請求是根據每 臺服務器當前所打開的連接數來分配的。即活躍連接數最少的服務器會自動接收下壹個傳入的請求。接本上和簡單輪詢的原則相同：所有擁有虛擬服務的服務器資源 容量應該相近。值得註意的是，在流量率低的配置環境中，各服務器的流量並不是相同的，會優先考慮第壹臺服務器。這是因為，如果所有的服務器是相同的，那麽 第壹個服務器優先，直到第壹臺服務器有連續的活躍流量，否則總是會優先選擇第壹臺服務器。
Source IP Hash： 這種方式通過生成請求源 IP 的哈希值，並通過這個哈希值來找到正確的真實服務器。這意味著對於同壹主機來說他對應的服務器總是相同。使用這種方式，妳不需要保存任何源 IP。但是需要註意，這種方式可能導致服務器負載不平衡。
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 秒計算壹次。