什麼是負載均衡器？

假設有一個分散式系統，該系統由在不同計算機上執行的許多服務組成。但是，當用戶數量很大時，通常會為服務建立多個副本。每個副本都在另一臺計算機上執行。此時，出現 “Load Balancer（負載均衡器）”。它有助於在伺服器之間平均分配傳入流量。

伺服器端負載均衡器

傳統上，Load Balancers（例如Nginx、F5）是放置在伺服器端的元件。當請求來自 客戶端 時，它們將轉到負載均衡器，負載均衡器將為請求指定 伺服器。負載均衡器使用的最簡單的演算法是隨機指定。在這種情況下，大多數負載平衡器是用於控制負載平衡的硬體整合軟體。

重點：

• 對客戶端不透明，客戶端不知道伺服器端的服務列表，甚至不知道自己傳送請求的目標地址存在負載均衡器。
• 伺服器端維護負載均衡伺服器，控制負載均衡策略和演算法。

客戶端負載均衡器

當負載均衡器位於 客戶端 時，客戶端得到可用的伺服器列表然後按照特定的負載均衡策略,分發請求到不同的 伺服器 。

重點：

• 對客戶端透明，客戶端需要知道伺服器端的服務列表，需要自行決定請求要傳送的目標地址。
• 客戶端維護負載均衡伺服器，控制負載均衡策略和演算法。
• 目前單獨提供的客戶端實現比較少（ 我用過的只有Ribbon），大部分都是在框架內部自行實現。

Ribbon

簡介

Ribbon是Netflix公司開源的一個客戶單負載均衡的專案，可以自動與 Eureka 進行互動。它提供下列特性：

• 負載均衡
• 容錯
• 以非同步和反應式模型執行多協議 (HTTP, TCP, UDP)
• 快取和批量

Ribbon中的關鍵元件

• ServerList：可以響應客戶端的特定服務的伺服器列表。
• ServerListFilter：可以動態獲得的具有所需特徵的候選伺服器列表的過濾器。
• ServerListUpdater：用於執行動態伺服器列表更新。
• Rule：負載均衡策略，用於確定從伺服器列表返回哪個伺服器。
• Ping：客戶端用於快速檢查伺服器當時是否處於活動狀態。
• LoadBalancer：負載均衡器，負責負載均衡排程的管理。

原始碼分析

LoadBalancerClient

實際應用中，通常將 RestTemplate 和 Ribbon 結合使用，例如：

@Configuration
public class RibbonConfig {
    @Bean
    @LoadBalanced
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
 

消費者呼叫服務介面：

@Service
public class RibbonService {
    @Autowired
    private RestTemplate restTemplate;
    public String hi(String name) {
        return restTemplate.getForObject("http://service-hi/hi?name="+name,String.class);
    }
}

@LoadBalanced，通過原始碼可以發現這是一個標記註解：

/**
 * Annotation to mark a RestTemplate bean to be configured to use a LoadBalancerClient
 * @author Spencer Gibb
 */
@Target({ ElementType.FIELD, ElementType.PARAMETER, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@Qualifier
public @interface LoadBalanced {
}

通過註釋可以知道@LoadBalanced註解是用來給RestTemplate做標記，方便我們對RestTemplate新增一個LoadBalancerClient，以實現客戶端負載均衡。

根據spring boot的自動配置原理，可以知道同包下的LoadBalancerAutoConfiguration，應該是實現客戶端負載均衡器的自動化配置類。程式碼如下：

@Configuration
@ConditionalOnClass(RestTemplate.class)
@ConditionalOnBean(LoadBalancerClient.class)
@EnableConfigurationProperties(LoadBalancerRetryProperties.class)
public class LoadBalancerAutoConfiguration {

    @LoadBalanced
    @Autowired(required = false)
    private List<RestTemplate> restTemplates = Collections.emptyList();

    @Bean
    public SmartInitializingSingleton loadBalancedRestTemplateInitializerDeprecated(
            final ObjectProvider<List<RestTemplateCustomizer>> restTemplateCustomizers) {
        return () -> restTemplateCustomizers.ifAvailable(customizers -> {
            for (RestTemplate restTemplate : LoadBalancerAutoConfiguration.this.restTemplates) {
                for (RestTemplateCustomizer customizer : customizers) {
                    customizer.customize(restTemplate);
                }
            }
        });
    }

    @Autowired(required = false)
    private List<LoadBalancerRequestTransformer> transformers = Collections.emptyList();

    @Bean
    @ConditionalOnMissingBean
    public LoadBalancerRequestFactory loadBalancerRequestFactory(
            LoadBalancerClient loadBalancerClient) {
        return new LoadBalancerRequestFactory(loadBalancerClient, transformers);
    }

    @Configuration
    @ConditionalOnMissingClass("org.springframework.retry.support.RetryTemplate")
    static class LoadBalancerInterceptorConfig {
        @Bean
        public LoadBalancerInterceptor ribbonInterceptor(
                LoadBalancerClient loadBalancerClient,
                LoadBalancerRequestFactory requestFactory) {
            return new LoadBalancerInterceptor(loadBalancerClient, requestFactory);
        }
    
        @Bean
        @ConditionalOnMissingBean
        public RestTemplateCustomizer restTemplateCustomizer(
                final LoadBalancerInterceptor loadBalancerInterceptor) {
            return restTemplate -> {
                List<ClientHttpRequestInterceptor> list = new ArrayList<>(
                        restTemplate.getInterceptors());
                list.add(loadBalancerInterceptor);
                restTemplate.setInterceptors(list);
            };
        }
    }
    
    @Configuration
    @ConditionalOnClass(RetryTemplate.class)
    public static class RetryAutoConfiguration {

        @Bean
        @ConditionalOnMissingBean
        public LoadBalancedRetryFactory loadBalancedRetryFactory() {
            return new LoadBalancedRetryFactory() {};
        }
    }
    
    @Configuration
    @ConditionalOnClass(RetryTemplate.class)
    public static class RetryInterceptorAutoConfiguration {
        @Bean
        @ConditionalOnMissingBean
        public RetryLoadBalancerInterceptor ribbonInterceptor(
                LoadBalancerClient loadBalancerClient, LoadBalancerRetryProperties properties,
                LoadBalancerRequestFactory requestFactory,
                LoadBalancedRetryFactory loadBalancedRetryFactory) {
            return new RetryLoadBalancerInterceptor(loadBalancerClient, properties,
                    requestFactory, loadBalancedRetryFactory);
        }

        @Bean
        @ConditionalOnMissingBean
        public RestTemplateCustomizer restTemplateCustomizer(
                final RetryLoadBalancerInterceptor loadBalancerInterceptor) {
            return restTemplate -> {
                List<ClientHttpRequestInterceptor> list = new ArrayList<>(
                        restTemplate.getInterceptors());
                list.add(loadBalancerInterceptor);
                restTemplate.setInterceptors(list);
            };
        }
    }
}

從程式碼可以看出，這個類作用主要是使用RestTemplateCustomizer對所有標註了@LoadBalanced的RestTemplate Bean添加了一個LoadBalancerInterceptor攔截器，而這個攔截器的作用就是對請求的URI進行轉換獲取到具體應該請求哪個服務例項。

那再看看新增的攔截器LoadBalancerInterceptor的程式碼，如下：

public class LoadBalancerInterceptor implements ClientHttpRequestInterceptor {

    private LoadBalancerClient loadBalancer;
    private LoadBalancerRequestFactory requestFactory;

    public LoadBalancerInterceptor(LoadBalancerClient loadBalancer, LoadBalancerRequestFactory requestFactory) {
        this.loadBalancer = loadBalancer;
        this.requestFactory = requestFactory;
    }

    public LoadBalancerInterceptor(LoadBalancerClient loadBalancer) {
        // for backwards compatibility
        this(loadBalancer, new LoadBalancerRequestFactory(loadBalancer));
    }

    @Override
    public ClientHttpResponse intercept(final HttpRequest request, final byte[] body,
            final ClientHttpRequestExecution execution) throws IOException {
        final URI originalUri = request.getURI();
        String serviceName = originalUri.getHost();
        Assert.state(serviceName != null, "Request URI does not contain a valid hostname: " + originalUri);
        return this.loadBalancer.execute(serviceName, requestFactory.createRequest(request, body, execution));
    }
}

從程式碼可以看出 LoadBalancerInterceptor 攔截了請求後，通過LoadBalancerClient執行具體的請求傳送。

開啟LoadBalancerClient，發現它是一個介面：

public interface LoadBalancerClient {

    ServiceInstance choose(String serviceId);

    <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException;

    <T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> request) throws IOException;

    URI reconstructURI(ServiceInstance instance, URI original);
}

介面說明：

• ServiceInstance choose(String serviceId)：根據傳入的服務id，從負載均衡器中為指定的服務選擇一個服務例項。
• T execute(String serviceId, LoadBalancerRequest request)：根據傳入的服務id，指定的負載均衡器中的服務例項執行請求。
• T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest request)：根據傳入的服務例項，執行請求。

LoadBalancerClient 有一個唯一的實現類 RibbonLoadBalancerClient，關鍵程式碼如下：

public class RibbonLoadBalancerClient implements LoadBalancerClient {

    public ServiceInstance choose(String serviceId) {
        Server server = this.getServer(serviceId);
        return server == null ? null : new RibbonLoadBalancerClient.RibbonServer(serviceId, server, this.isSecure(server, serviceId), this.serverIntrospector(serviceId).getMetadata(server));
    }
    
    public <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException {
        ILoadBalancer loadBalancer = this.getLoadBalancer(serviceId);
        Server server = this.getServer(loadBalancer);
        if (server == null) {
            throw new IllegalStateException("No instances available for " + serviceId);
        } else {
            RibbonLoadBalancerClient.RibbonServer ribbonServer = new RibbonLoadBalancerClient.RibbonServer(serviceId, server, this.isSecure(server, serviceId), this.serverIntrospector(serviceId).getMetadata(server));
            return this.execute(serviceId, ribbonServer, request);
        }
    }
    
    protected Server getServer(String serviceId) {
        return this.getServer(this.getLoadBalancer(serviceId));
    }
    
    protected Server getServer(ILoadBalancer loadBalancer) {
        return loadBalancer == null ? null : loadBalancer.chooseServer("default");
    }
    
    protected ILoadBalancer getLoadBalancer(String serviceId) {
        return this.clientFactory.getLoadBalancer(serviceId);
    }
    
    //省略...

}

負載均衡器

從 RibbonLoadBalancerClient 程式碼可以看出，實際負載均衡的是通過 ILoadBalancer 來實現的。

ILoadBalancer 介面程式碼如下：

public interface ILoadBalancer {

    public void addServers(List<Server> newServers);

    public Server chooseServer(Object key);

    public void markServerDown(Server server);

    public List<Server> getReachableServers();

    public List<Server> getAllServers();
}

介面說明：

• addServers：向負載均衡器中新增一個服務例項集合。
• chooseServer：跟據key，從負載均衡器獲取服務例項。
• markServerDown：用來標記某個服務例項下線。
• getReachableServers：獲取可用的服務例項集合。
• getAllServers()：獲取所有服務例項集合，包括下線的服務例項。

ILoadBalancer 的實現 依賴關係示意圖如下：

• NoOpLoadBalancer：啥都不做
• BaseLoadBalancer：
• 一個負載均衡器的基本實現，其中有一個任意列表，可以將伺服器設定為伺服器池。
• 可以設定一個ping來確定伺服器的活力。
• 在內部，該類維護一個“all”伺服器列表，以及一個“up”伺服器列表，並根據呼叫者的要求使用它們。
• DynamicServerListLoadBalancer：
• 通過動態的獲取伺服器的候選列表的負載平衡器。
• 可以通過篩選標準來傳遞伺服器列表，以過濾不符合所需條件的伺服器。
• ZoneAwareLoadBalancer：
• 用於測量區域條件的關鍵指標是平均活動請求，它根據每個rest客戶機和每個區域聚合。這是區域內未完成的請求總數除以可用目標例項的數量(不包括斷路器跳閘例項)。當在壞區上緩慢發生超時時，此度量非常有效。
• 該負載均衡器將計算並檢查所有可用區域的區域狀態。如果任何區域的平均活動請求已達到配置的閾值，則該區域將從活動伺服器列表中刪除。如果超過一個區域達到閾值，則將刪除每個伺服器上活動請求最多的區域。一旦去掉最壞的區域，將在其餘區域中選擇一個區域，其概率與其例項數成正比。伺服器將使用給定的規則從所選區域返回。對於每個請求，將重複上述步驟。也就是說，每個與區域相關的負載平衡決策都是實時做出的，最新的統計資料可以幫助進行選擇。

那麼在整合Ribbon的時候Spring Cloud預設採用了哪個具體實現呢？我們通過RibbonClientConfiguration配置類，可以知道在整合時預設採用了ZoneAwareLoadBalancer來實現負載均衡器。

@Bean
@ConditionalOnMissingBean
public ILoadBalancer ribbonLoadBalancer(IClientConfig config, ServerList<Server> serverList, ServerListFilter<Server> serverListFilter, IRule rule, IPing ping, ServerListUpdater serverListUpdater) {
    return (ILoadBalancer)(this.propertiesFactory
    .isSet(ILoadBalancer.class, this.name) ? (ILoadBalancer)this.propertiesFactory
    .get(ILoadBalancer.class, config, this.name) : new ZoneAwareLoadBalancer(config, rule, ping, serverList, serverListFilter, serverListUpdater));
}

從這段程式碼 ，也可以看出，負載均衡器所需的主要配置項是IClientConfig, ServerList, ServerListFilter, IRule, IPing, ServerListUpdater。下面逐一分析他們。

IClientConfig

IClientConfig 用於對客戶端或者負載均衡的配置，它的預設實現類為 DefaultClientConfigImpl。

IRule

為LoadBalancer定義“負載均衡策略”的介面。

public interface IRule{

    public Server choose(Object key);
    
    public void setLoadBalancer(ILoadBalancer lb);
    
    public ILoadBalancer getLoadBalancer();    
}

IRule 的實現 依賴關係示意圖如下：

• BestAvailableRule：選擇具有最低併發請求的伺服器。
• ClientConfigEnabledRoundRobinRule：輪詢。
• RandomRule：隨機選擇一個伺服器。
• RoundRobinRule：輪詢選擇伺服器。
• RetryRule：具備重試機制的輪詢。
• WeightedResponseTimeRule：根據使用平均響應時間去分配一個weight（權重） ，weight越低，被選擇的可能性就越低。
• ZoneAvoidanceRule：根據區域和可用性篩選，再輪詢選擇伺服器。

IPing

定義如何 “ping” 伺服器以檢查其是否存活。

public interface IPing {
    public boolean isAlive(Server server);
}

IPing 的實現 依賴關係示意圖如下：

• PingUrl：真實的去ping 某個url，判斷其是否alive。
• PingConstant：固定返回某服務是否可用，預設返回true，即可用
• NoOpPing：不去ping,直接返回true,即可用。
• DummyPing：繼承抽象類AbstractLoadBalancerPing，認為所以服務都是存活狀態，返回true，即可用。
• NIWSDiscoveryPing：結合eureka使用時，如果Discovery Client線上，則認為心跳檢測通過。

ServerList

定義獲取所有的服務例項清單。

public interface ServerList<T extends Server> {
    public List<T> getInitialListOfServers();
    public List<T> getUpdatedListOfServers();   
}

ServerList 的實現 依賴關係示意圖如下：

• DomainExtractingServerList：代理類，根據傳入的ServerList的值，實現具體的邏輯。
• ConfigurationBasedServerList：從配置檔案中載入伺服器列表。
• DiscoveryEnabledNIWSServerList：從Eureka註冊中心中獲取伺服器列表。
• StaticServerList：通過靜態配置來維護伺服器列表。

ServerListFilter

允許根據過濾配置動態獲得的具有所需特性的候選伺服器列表。

public interface ServerListFilter<T extends Server> {
    public List<T> getFilteredListOfServers(List<T> servers);
}

ServerListFilter 的實現 依賴關係示意圖如下：

• DefaultNIWSServerListFilter：完全繼承自ZoneAffinityServerListFilter。
• ZonePreferenceServerListFilter：EnableZoneAffinity 或 EnableZoneExclusivity 開啟狀態使用，預設關閉。處理基於區域感知的過濾伺服器，過濾掉不和客戶端在相同zone的服務，若不存在相同zone，則不進行過濾。
• ServerListSubsetFilter：伺服器列表篩選器，它將負載平衡器使用的伺服器數量限制為所有伺服器的子集。如果伺服器機群很大(例如數百個)，並且不需要使用每一個機群並將連線儲存在http客戶機的連線池中，那麼這是非常有用的。它還可以通過比較總的網路故障和併發連線來驅逐相對不健康的伺服器。

ServerListUpdater

用於執行動態伺服器列表更新。

public interface ServerListUpdater {

    public interface UpdateAction {
        void doUpdate();
    }

    void start(UpdateAction updateAction);

    void stop();

    String getLastUpdate();

    long getDurationSinceLastUpdateMs();

    int getNumberMissedCycles();

    int getCoreThreads();
}

ServerListUpdater 的實現 依賴關係示意圖如下：

• PollingServerListUpdater：預設的實現策略，會啟動一個定時執行緒池，定時執行更新策略。
• EurekaNotificationServerListUpdater：利用Eureka的事件監聽器來驅動服務列表的更新操作。

參考資料

https://github.com/Netflix/ribbon/wiki

http://tech.lede.com/2018/01/11/rd/server/NetflixRibbon/

http://blog.didispace.com/springcloud-sourcecode-ribbon/

https://www.fangzhipeng.com/springcloud/2017/08/11/Ribbon-resources.html

https://blog.csdn.net/Tincox/article/details/79210309

歡迎掃碼或微信搜尋公眾號《程式設計師果果》關注我，關注有驚喜~

相關推薦