上一期我們詳細探討了微服務之間的通訊，特別是介紹瞭如何整合Ribbon。簡單來說，透過使用resttemplate類進行RPC呼叫時，我們內部增加了一個攔截器來實現負載均衡。然而，我們並未深入討論具體的負載均衡演算法。因此，本章節的重點是介紹如何從多個副本中選擇合適的節點進行服務呼叫。這將幫助大家更好地理解在微服務架構中如何有效地實現負載均衡。
好的，今天我們依舊會涉及原始碼，但希望大家能把注意力集中在理念層面，而不是深究每個具體的過程呼叫。無需糾結於程式碼的具體行數，因為重要的是理解整體架構和流程，這樣才能更好地掌握主題的實質。
負載均衡演算法
我們首先來探討一下預設情況下Ribbon使用的負載均衡演算法。有些人可能會說它使用輪詢演算法，因為在本地測試時，我們經常會看到輪詢的效果。然而，簡單地依賴這種表面的觀察來回答面試題是有風險的。實際上，忽略了深入理解原始碼可能會導致嚴重的誤解。
儘管實踐是增長知識的一部分，但是在真實的生產環境中，尤其是跨多個資料中心部署的情況下，我們無法簡單地將問題簡化為本地叢集的測試環境。
獲取伺服器ip
我們接著上一篇內容，討論如何選擇伺服器的步驟如下複述：
public <T> T execute(String serviceId, LoadBalancerRequest<T> request, Object hint)
throws IOException {
ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
Server server = getServer(loadBalancer, hint);
if (server == null) {
throw new IllegalStateException("No instances available for " + serviceId);
}
RibbonServer ribbonServer = new RibbonServer(serviceId, server,
isSecure(server, serviceId),
serverIntrospector(serviceId).getMetadata(server));
return execute(serviceId, ribbonServer, request);
}
獲取負載均衡器——ZoneAwareLoadBalancer
我們來看看getServer方法，突然間出現這麼多負載均衡器，應該怎麼處理呢？這時候最好的方法就是檢視自動配置，看看哪些被注入進來了。
中間步驟大家就不用再找了，我已經事先找好了，就在這裡：
這張圖包含兩個關鍵資訊：首先是注入了一個IRule規則，其次是將該IRule規則應用到了ZoneAwareLoadBalancer負載均衡器中。好的，現在我們清楚了接下來的步驟。接下來我們繼續檢視
public Server chooseServer(Object key) {
if (!ENABLED.get() || getLoadBalancerStats().getAvailableZones().size() <= 1) {
logger.debug("Zone aware logic disabled or there is only one zone");
return super.chooseServer(key);
}
Server server = null;
try {
//省略多餘程式碼
Set<String> availableZones = ZoneAvoidanceRule.getAvailableZones(zoneSnapshot, triggeringLoad.get(), triggeringBlackoutPercentage.get());
logger.debug("Available zones: {}", availableZones);
if (availableZones != null && availableZones.size() < zoneSnapshot.keySet().size()) {
String zone = ZoneAvoidanceRule.randomChooseZone(zoneSnapshot, availableZones);
logger.debug("Zone chosen: {}", zone);
if (zone != null) {
BaseLoadBalancer zoneLoadBalancer = getLoadBalancer(zone);
server = zoneLoadBalancer.chooseServer(key);
}
}
} catch (Exception e) {
logger.error("Error choosing server using zone aware logic for load balancer={}", name, e);
}
//省略多餘程式碼
}
如果是在我們本地環境，通常會執行第一個if分支；但如果是在生產環境並配置了多個區域，那麼會執行下面的分支。讓我們一起來看看。
無配置區域情況
讓我們來看看第一種情況，即如果沒有區域或者只有一個區域，負載均衡規則是如何應用的。我們將檢視父類負載均衡器BaseLoadBalancer的程式碼。
public class BaseLoadBalancer extends AbstractLoadBalancer implements
PrimeConnections.PrimeConnectionListener, IClientConfigAware {
private final static IRule DEFAULT_RULE = new RoundRobinRule();
protected IRule rule = DEFAULT_RULE;
public Server chooseServer(Object key) {
if (counter == null) {
counter = createCounter();
}
counter.increment();
if (rule == null) {
return null;
} else {
try {
return rule.choose(key);
} catch (Exception e) {
logger.warn("LoadBalancer [{}]: Error choosing server for key {}", name, key, e);
return null;
}
}
}
void initWithConfig(IClientConfig clientConfig, IRule rule, IPing ping, LoadBalancerStats stats) {
// 省略部分程式碼
setRule(rule);
// 省略部分程式碼
}
}
這裡可以看到是有預設的IRule規則的——RoundRobinRule，但是別衝動，因為我們Spring自動託管的IRule規則還沒用上，不可能這麼簡單的走輪訓。我們可以看到這裡是有設定的地方的。我也抓出來了。
最後讓我們再來看看我們的ZoneAwareLoadBalancer生成構造器，因為在注入時我們是會帶入規則的。以下是相關的程式碼示例：
public ZoneAwareLoadBalancer(IClientConfig clientConfig, IRule rule,
IPing ping, ServerList<T> serverList, ServerListFilter<T> filter,
ServerListUpdater serverListUpdater) {
super(clientConfig, rule, ping, serverList, filter, serverListUpdater);
}
在這裡，當super父類構造器執行完畢後，最終會呼叫BaseLoadBalancer類的initWithConfig方法。我沒有一一追蹤下去，但最後ZoneAvoidanceRule的負載均衡程式碼也相當複雜。不過，你可以將其理解為在沒有區域的情況下類似於輪詢。
配置多區域情況
在這個階段，程式將會執行第二個分支，實際上，主要的程式碼如下所示：
String zone = ZoneAvoidanceRule.randomChooseZone(zoneSnapshot, availableZones);
if (zone != null) {
BaseLoadBalancer zoneLoadBalancer = getLoadBalancer(zone);
server = zoneLoadBalancer.chooseServer(key);
}
目的仍然是選擇一個伺服器，但是限定在當前區域內。關於這部分的詳細討論略去，因為接下來的方法都是關於ZoneAvoidanceRule的負載均衡演算法程式碼。
如何配置其他演算法
在這種情況下，如果我想使用其他負載均衡演算法而不是當前的演算法，應該如何配置呢？實際上，可以檢視注入的原始碼，有兩種方法可以實現這一點。首先，可以透過在配置類中新增一個配置項來指定所需的負載均衡演算法。
if (this.propertiesFactory.isSet(IRule.class, name)) {
return this.propertiesFactory.get(IRule.class, config, name);
}
區域性配置
在這裡可以看到我們也是透過配置檔案來進行配置的，不過配置檔案的方式使我們能夠進行區域性微服務負載均衡的選擇。讓我們先來看一下原始碼：
public PropertiesFactory() {
classToProperty.put(ILoadBalancer.class, "NFLoadBalancerClassName");
classToProperty.put(IPing.class, "NFLoadBalancerPingClassName");
classToProperty.put(IRule.class, "NFLoadBalancerRuleClassName");
classToProperty.put(ServerList.class, "NIWSServerListClassName");
classToProperty.put(ServerListFilter.class, "NIWSServerListFilterClassName");
}
public boolean isSet(Class clazz, String name) {
return StringUtils.hasText(getClassName(clazz, name));
}
在呼叫特定的微服務時，可以根據需要使用相應的負載均衡策略來配置 application.yml 檔案。
#被呼叫的微服務名
mall‐order:
ribbon:
#指定使用Nacos提供的負載均衡策略（優先呼叫同一叢集的例項，基於隨機&權重）
NFLoadBalancerRuleClassName:com.alibaba.cloud.nacos.ribbon.NacosRule
全域性配置
在全域性情況下更為簡單，可以觀察到在自動注入時使用了 @ConditionalOnMissingBean 註解。如果我們在Spring中手動載入了相應的bean，那麼這個註解就不會生效了。
@Bean
public IRule ribbonRule() {
// 指定使用Nacos提供的負載均衡策略（優先呼叫同一叢集的例項，基於隨機權重）
return new NacosRule();
}
相當簡單了，那麼這樣的的話，其實我們也可以進行自定義一個策略的。畢竟照先有的抄下固定實現方法後，自己在實現方法內寫上自己的業務邏輯不就完了。
自定義策略
看起來，對於實現其他的負載均衡演算法策略，有幾個關鍵點。首先，需要繼承 AbstractLoadBalancerRule 父類，並且實現其抽象方法。接下來，我們可以開始編寫我們的實現程式碼：
@Slf4j
public class XiaoYuRandomWithWeightRule extends AbstractLoadBalancerRule {
@Override
public Server choose(Object key) {
//這裡實現自己的邏輯即可
return server;
}
@Override
public void initWithNiwsConfig(IClientConfig clientConfig) {
}
}
OK，剩下的就按照區域性配置或者全域性配置下，讓我們的規則生效即可。
在這裡只講述了演算法規則的配置和自定義方法，實際上負載均衡器的操作也是類似的套路。這裡就不重複演示了。
總結
今天，我們主要補充了上一章關於微服務通訊的內容，並深入探討了負載均衡演算法的重要性。我們首先詳細討論了Ribbon預設使用的負載均衡演算法。儘管在本地測試時可能會觀察到輪詢的效果，但簡單依賴這種表面的觀察是不夠的。在真實的生產環境中，特別是在跨多個資料中心部署時，負載均衡策略的選擇需要更加深入的理解和分析。
我們進一步分析瞭如何透過配置和自定義負載均衡規則來靈活應對各種場景。不論是區域性配置還是全域性配置，我們都能根據具體需求調整負載均衡的行為。同時，我們展示瞭如何透過自定義演算法擴充套件Ribbon的負載均衡能力，以更好地適應特定業務場景的需求。
在接下來的章節中，我們將深入探討OpenFeign元件。我們的重點將是如何使開發人員能夠更多關注業務邏輯程式碼，而不是被迫處理與RPC呼叫相關的繁瑣細節。
我是努力的小雨，一名 Java 服務端碼農，潛心研究著 AI 技術的奧秘。我熱愛技術交流與分享，對開源社群充滿熱情。同時也是一位掘金優秀作者、騰訊雲內容共創官、阿里雲專家博主、華為云云享專家。
💡 我將不吝分享我在技術道路上的個人探索與經驗，希望能為你的學習與成長帶來一些啟發與幫助。
🌟 歡迎關注努力的小雨！🌟