SpringCloud 源碼系列（4）—— 負載均衡 Ribbon（上）

SpringCloud 源碼系列（1）—— 注冊中心 Eureka（上）

SpringCloud 源碼系列（2）—— 注冊中心 Eureka（中）

SpringCloud 源碼系列（3）—— 注冊中心 Eureka（下）

SpringCloud 源碼系列（4）—— 負載均衡 Ribbon（上）

SpringCloud 源碼系列（5）—— 負載均衡 Ribbon（下）

SpringCloud 源碼系列（6）—— 聲明式服務調用 Feign

 

一、負載均衡

1、RestTemplate

在研究 eureka 源碼上篇中，我們在 demo-consumer 消費者服務中定義了用 @LoadBalanced 標記的 RestTemplate，然后使用 RestTemplate 通過服務名的形式來調用遠程服務 demo-producer，然后請求會輪詢到兩個 demo-producer 實例上。

RestTemplate 是 Spring Resources 中一個訪問第三方 RESTful API 接口的網絡請求框架。RestTemplate 是用來消費 REST 服務的，所以 RestTemplate 的主要方法都與 REST 的 Http協議的一些方法緊密相連，例如 HEAD、GET、POST、PUT、DELETE 和 OPTIONS 等方法，這些方法在 RestTemplate 類對應的方法為 headForHeaders()、getForObject()、postForObject()、put() 和 delete() 等。

RestTemplate 本身是不具備負載均衡的能力的，如果 RestTemplate 未使用 @LoadBalanced 標記，就通過服務名的形式來調用，必然會報錯。用 @LoadBalanced 標記后，調用 RestTemplate 的 REST 方法就會通過負載均衡的方式通過一定的策略路由到某個服務實例上，底層負責負載均衡的組件就是 Ribbon。后面我們再來看 @LoadBalanced 是如何讓 RestTemplate 具備負載均衡的能力的。

@SpringBootApplication
public class ConsumerApplication {

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

    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

@RestController
public class DemoController {
    private final Logger logger = LoggerFactory.getLogger(getClass());

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/v1/id")
    public ResponseEntity<String> getId() {
        ResponseEntity<String> result = restTemplate.getForEntity("http://demo-producer/v1/uuid", String.class);
        String uuid = result.getBody();
        logger.info("request id: {}", uuid);
        return ResponseEntity.ok(uuid);
    }
}

2、Ribbon 與負載均衡

① 負載均衡

負載均衡是指將負載分攤到多個執行單元上，負載均衡主要可以分為集中式負載均衡與進程內負載均衡：

• 集中式負載均衡指位於因特網與執行單元之間，並負責把網絡請求轉發到各個執行單元上，比如 Nginx、F5。集中式負載均衡也可以稱為服務端負載均衡。
• 進程內負載均衡是將負載均衡邏輯集成到客戶端上，客戶端維護了一份服務提供者的實例列表，實例列表一般會從注冊中心比如 Eureka 中獲取。有了實例列表，就可以通過負載均衡策略將請求分攤給多個服務提供者，從而達到負載均衡的目的。進程內負載均衡一般也稱為客戶端負載均衡。

Ribbon 是一個客戶端負載均衡器，可以很好地控制 HTTP 和 TCP 客戶端的負載均衡行為。Ribbon 是 Netflix 公司開源的一個負載均衡組件，已經整合到 SpringCloud 生態中，它在 Spring Cloud 生態內是一個不可缺少的組件，少了它，服務便不能橫向擴展。

② Ribbon 模塊

Ribbon 有很多子模塊，官方文檔中說明，目前 Netflix 公司主要用於生產環境的 Ribbon 子模塊如下：

• ribbon-loadbalancer：可以獨立使用或與其他模塊一起使用的負載均衡器 API。
• ribbon-eureka：Ribbon 結合 Eureka 客戶端的 API，為負載均衡器提供動態服務注冊列表信息。
• ribbon-core：Ribbon 的核心API。

③ springcloud 與 ribbon 整合

與 eureka 整合到 springcloud 類似，springcloud 提供了對應的 spring-cloud-starter-netflix-eureka-client(server) 依賴包，ribbon 則整合到了 spring-cloud-starter-netflix-ribbon 中。一般也不需要單獨引入 ribbon 的依賴包，spring-cloud-starter-netflix-eureka-client 中已經依賴了 spring-cloud-starter-netflix-ribbon。因此我們引入了 spring-cloud-starter-netflix-eureka-client 就可以使用 Ribbon 的功能了。

④ Ribbon 與 RestTemplate 整合使用

在 Spring Cloud 構建的微服務系統中，Ribbon 作為服務消費者的負載均衡器，有兩種使用方式，一種是和 RestTemplate 相結合，另一種是和 Feign 相結合。前面已經演示了帶有負載均衡的 RestTemplate 的使用，下面用一張圖來看看 RestTemplate 基於 Ribbon 的遠程調用。

二、RestTemplate 負載均衡

1、@LoadBalanced 注解

以 RestTemplate 為切入點，來看 Ribbon 的負載均衡核心原理。那么首先就要先看看 @LoadBalanced 注解如何讓 RestTemplate 具備負載均衡的能力了。

首先看 @LoadBalanced 這個注解的定義，可以得到如下信息：

• 這個注解使用 @Qualifier 標記，其它地方就可以注入 LoadBalanced 注解的 bean 對象。
• 從注釋中可以了解到，@LoadBalanced 標記的 RestTemplate 或 WebClient 將使用 LoadBalancerClient 來配置 bean 對象。

/**
 * Annotation to mark a RestTemplate or WebClient 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 是 spring-cloud-commons 模塊下 loadbalancer 包下的。

2、RestTemplate  負載均衡自動化配置

在 @LoadBalanced 同包下，有一個 LoadBalancerAutoConfiguration 自動化配置類，從注釋也可以看出，這是客戶端負載均衡 Ribbon 的自動化配置類。

從這個自動化配置類可以得到如下信息：

• 首先要有 RestTemplate 的依賴和定義了 LoadBalancerClient 對象的前提下才會觸發這個自動化配置類，這也對應了前面，RestTemplate 要用 LoadBalancerClient  來配置。
• 接着可以看到這個類注入了帶有 @LoadBalanced 標識的 RestTemplate 對象，就是要對這部分對象增加負載均衡的能力。
• 從 SmartInitializingSingleton 的構造中可以看到，就是在 bean 初始化完成后，用 RestTemplateCustomizer 定制化 RestTemplate。
• 再往下可以看到，RestTemplateCustomizer 其實就是向 RestTemplate 中添加了 LoadBalancerInterceptor 這個攔截器。
• 而 LoadBalancerInterceptor 的構建又需要 LoadBalancerClient 和 LoadBalancerRequestFactory，LoadBalancerRequestFactory 則通過 LoadBalancerClient 和 LoadBalancerRequestTransformer 構造完成。

/**
 * Auto-configuration for Ribbon (client-side load balancing).
 */
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(RestTemplate.class) // 有 RestTemplate 的依賴
@ConditionalOnBean(LoadBalancerClient.class) // 定義了 LoadBalancerClient 的 bean 對象
@EnableConfigurationProperties(LoadBalancerRetryProperties.class)
public class LoadBalancerAutoConfiguration {

    // 注入 @LoadBalanced 標記的 RestTemplate 對象
    @LoadBalanced
    @Autowired(required = false)
    private List<RestTemplate> restTemplates = Collections.emptyList();

    @Autowired(required = false)
    private List<LoadBalancerRequestTransformer> transformers = 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) {
                    // 利用 RestTemplateCustomizer 定制化 restTemplate
                    customizer.customize(restTemplate);
                }
            }
        });
    }

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

    @Configuration(proxyBeanMethods = false)
    @ConditionalOnMissingClass("org.springframework.retry.support.RetryTemplate")
    static class LoadBalancerInterceptorConfig {

        // 創建 LoadBalancerInterceptor 需要 LoadBalancerClient 和 LoadBalancerRequestFactory
        @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());
                // 向 restTemplate 添加 LoadBalancerInterceptor 攔截器
                list.add(loadBalancerInterceptor);
                restTemplate.setInterceptors(list);
            };
        }

    }
}

3、RestTemplate 攔截器 LoadBalancerInterceptor

LoadBalancerAutoConfiguration 自動化配置主要就是給 RestTemplate 添加了一個負載均衡攔截器 LoadBalancerInterceptor。從 setInterceptors 的參數可以看出，攔截器的類型是 ClientHttpRequestInterceptor，如果我們想定制化 RestTemplate，就可以實現這個接口來定制化，然后還可以用 @Order 標記攔截器的先后順序。

public void setInterceptors(List<ClientHttpRequestInterceptor> interceptors) {
    if (this.interceptors != interceptors) {
        this.interceptors.clear();
        this.interceptors.addAll(interceptors);
        // 根據 @Order 注解的順序排序
        AnnotationAwareOrderComparator.sort(this.interceptors);
    }
}

interceptors 攔截器是在 RestTemplate 的父類 InterceptingHttpAccessor 中的， RestTemplate 的類結構如下圖所示。

從 restTemplate.getForEntity("http://demo-producer/v1/uuid", String.class) 這個GET請求進去看看，是如何使用 LoadBalancerInterceptor 的。一步步進去，可以看到最終是進入到 doExecute 這個方法了。

在 doExecute 方法中，首先根據 url、method 創建一個 ClientHttpRequest，然后利用 ClientHttpRequest 來發起請求。

protected <T> T doExecute(URI url, @Nullable HttpMethod method, @Nullable RequestCallback requestCallback,
        @Nullable ResponseExtractor<T> responseExtractor) throws RestClientException {
    ClientHttpResponse response = null;
    try {
        // 創建一個 ClientHttpRequest
        ClientHttpRequest request = createRequest(url, method);
        if (requestCallback != null) {
            requestCallback.doWithRequest(request);
        }
        // 調用 ClientHttpRequest 的 execute() 方法
        response = request.execute();
        // 處理返回結果
        handleResponse(url, method, response);
        return (responseExtractor != null ? responseExtractor.extractData(response) : null);
    }
    catch (IOException ex) {
        // ...
    }
    finally {
        if (response != null) {
            response.close();
        }
    }
}

//////////////////////////////////////

protected ClientHttpRequest createRequest(URI url, HttpMethod method) throws IOException {
    ClientHttpRequest request = getRequestFactory().createRequest(url, method);
    initialize(request);
    if (logger.isDebugEnabled()) {
        logger.debug("HTTP " + method.name() + " " + url);
    }
    return request;
}

InterceptingHttpAccessor 中重寫了父類 HttpAccessor 的 getRequestFactory 方法，父類默認的 requestFactory 是 SimpleClientHttpRequestFactory。

重寫后的 getRequestFactory 方法中，如果攔截器不為空，則基於父類默認的 SimpleClientHttpRequestFactory 和攔截器創建了 InterceptingClientHttpRequestFactory。

public ClientHttpRequestFactory getRequestFactory() {
    List<ClientHttpRequestInterceptor> interceptors = getInterceptors();
    if (!CollectionUtils.isEmpty(interceptors)) {
        ClientHttpRequestFactory factory = this.interceptingRequestFactory;
        if (factory == null) {
            // 傳入 SimpleClientHttpRequestFactory 和 ClientHttpRequestInterceptor 攔截器
            factory = new InterceptingClientHttpRequestFactory(super.getRequestFactory(), interceptors);
            this.interceptingRequestFactory = factory;
        }
        return factory;
    }
    else {
        return super.getRequestFactory();
    }
}

也就是說調用了 InterceptingClientHttpRequestFactory 的 createRequest 方法來創建 ClientHttpRequest。進去可以看到，ClientHttpRequest 的實際類型就是 InterceptingClientHttpRequest。

protected ClientHttpRequest createRequest(URI uri, HttpMethod httpMethod, ClientHttpRequestFactory requestFactory) {
    return new InterceptingClientHttpRequest(requestFactory, this.interceptors, uri, httpMethod);
}

InterceptingClientHttpRequest 的類結構如下：

RestTemplate 的 doExecute 中調用 request.execute() 其實是調用了 InterceptingClientHttpRequest 父類 AbstractClientHttpRequest 中的 execute 方法。一步步進去可以發現最終其實是調用了 InterceptingClientHttpRequest 的 executeInternal 方法。

在 InterceptingClientHttpRequest  的 executeInternal 方法中，創建了 InterceptingRequestExecution 來執行請求。在 InterceptingRequestExecution 的 execute 方法中，會先遍歷執行所有攔截器，然后通過 ClientHttpRequest 發起真正的 http 請求。

protected final ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
    // 創建 InterceptingRequestExecution
    InterceptingRequestExecution requestExecution = new InterceptingRequestExecution();
    // 請求調用
    return requestExecution.execute(this, bufferedOutput);
}

private class InterceptingRequestExecution implements ClientHttpRequestExecution {

    private final Iterator<ClientHttpRequestInterceptor> iterator;

    public InterceptingRequestExecution() {
        // 攔截器迭代器
        this.iterator = interceptors.iterator();
    }

    @Override
    public ClientHttpResponse execute(HttpRequest request, byte[] body) throws IOException {
        if (this.iterator.hasNext()) {
            ClientHttpRequestInterceptor nextInterceptor = this.iterator.next();
            // 利用攔截器攔截處理，並傳入 InterceptingRequestExecution
            return nextInterceptor.intercept(request, body, this);
        }
        else {
            // 攔截器遍歷完后開始發起真正的 http 請求
            HttpMethod method = request.getMethod();
            Assert.state(method != null, "No standard HTTP method");
            ClientHttpRequest delegate = requestFactory.createRequest(request.getURI(), method);
            request.getHeaders().forEach((key, value) -> delegate.getHeaders().addAll(key, value));
            if (body.length > 0) {
                if (delegate instanceof StreamingHttpOutputMessage) {
                    StreamingHttpOutputMessage streamingOutputMessage = (StreamingHttpOutputMessage) delegate;
                    streamingOutputMessage.setBody(outputStream -> StreamUtils.copy(body, outputStream));
                }
                else {
                    StreamUtils.copy(body, delegate.getBody());
                }
            }
            return delegate.execute();
        }
    }
}

進入到 LoadBalancerInterceptor 的 intercept 攔截方法內，可以看到從請求的原始地址中獲取了服務名稱，然后調用了 loadBalancer 的 execute 方法，也就是 LoadBalancerClient。

到這里，其實已經可以想象，loadBalancer.execute 這行代碼就是根據服務名稱去獲取一個具體的實例，然后將原始地址替換為實例的IP地址。那這個 loadBalancer 又是什么呢？

public ClientHttpResponse intercept(final HttpRequest request, final byte[] body, final ClientHttpRequestExecution execution) throws IOException {
    // 原始地址：http://demo-producer/v1/uuid
    final URI originalUri = request.getURI();
    // host 就是服務名：demo-producer
    String serviceName = originalUri.getHost();
    Assert.state(serviceName != null,
            "Request URI does not contain a valid hostname: " + originalUri);
    return this.loadBalancer.execute(serviceName,
            this.requestFactory.createRequest(request, body, execution));
}

4、負載均衡客戶端 LoadBalancerClient

在配置 LoadBalancerInterceptor 時，需要兩個參數，LoadBalancerClient 和 LoadBalancerRequestFactory，LoadBalancerRequestFactory前面已經知道是如何創建的了。LoadBalancerClient 又是在哪創建的呢？通過 IDEA 搜索，可以發現是在 spring-cloud-netflix-ribbon 模塊下的 RibbonAutoConfiguration 中配置的，可以看到 LoadBalancerClient 的實際類型是 RibbonLoadBalancerClient。

配置類的順序是 EurekaClientAutoConfiguration、RibbonAutoConfiguration、LoadBalancerAutoConfiguration，因為使 RestTemplate 具備負載均衡的能力需要 LoadBalancerInterceptor 攔截器，創建 LoadBalancerInterceptor 又需要 LoadBalancerClient，而 LoadBalancerClient 底層要根據服務名獲取某個實例，肯定又需要一個實例庫，比如從配置文件、注冊中心獲取。從這里就可以看出來，RibbonLoadBalancerClient 默認會從 Eureka 注冊中心獲取實例。

@Configuration
@Conditional(RibbonAutoConfiguration.RibbonClassesConditions.class)
@RibbonClients
// 后於 EurekaClientAutoConfiguration 配置
@AutoConfigureAfter(name = "org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration")
// 先於 LoadBalancerAutoConfiguration 配置
@AutoConfigureBefore({ LoadBalancerAutoConfiguration.class,    AsyncLoadBalancerAutoConfiguration.class })
@EnableConfigurationProperties({ RibbonEagerLoadProperties.class, ServerIntrospectorProperties.class })
public class RibbonAutoConfiguration {

    @Autowired(required = false)
    private List<RibbonClientSpecification> configurations = new ArrayList<>();

    @Bean
    @ConditionalOnMissingBean
    public SpringClientFactory springClientFactory() {
        SpringClientFactory factory = new SpringClientFactory();
        factory.setConfigurations(this.configurations);
        return factory;
    }

    @Bean
    @ConditionalOnMissingBean(LoadBalancerClient.class)
    public LoadBalancerClient loadBalancerClient() {
        return new RibbonLoadBalancerClient(springClientFactory());
    }
}

LoadBalancerClient 主要提供了三個接口：

public interface LoadBalancerClient extends ServiceInstanceChooser {

    // 從 LoadBalancer 找一個 Server 來發送請求
    <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException;

    // 從傳入的 ServiceInstance 取 Server 來發送請求  
    <T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> request) throws IOException;

    // 對原始 URI 重構
    URI reconstructURI(ServiceInstance instance, URI original);
}

進入到 RibbonLoadBalancerClient 的 execute 方法中可以看到：

• 首先根據服務名獲取服務對應的負載均衡器 ILoadBalancer。
• 然后從 ILoadBalancer 中根據一定策略選出一個實例 Server。
• 然后將 server、serviceId 等信息封裝到 RibbonServer 中，也就是一個服務實例 ServiceInstance。
• 最后調用了 LoadBalancerRequest 的 apply，並傳入 ServiceInstance，將地址中的服務名替換為真實的IP地址。

public <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException {
    return execute(serviceId, request, null);
}

public <T> T execute(String serviceId, LoadBalancerRequest<T> request, Object hint)
        throws IOException {
    // 根據服務名獲取一個負載均衡器 ILoadBalancer
    ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
    // 利用負載均衡器獲取實例 Server
    Server server = getServer(loadBalancer, hint);
    if (server == null) {
        throw new IllegalStateException("No instances available for " + serviceId);
    }
    // 封裝實例信息：RibbonServer 的父類是 ServiceInstance
    RibbonServer ribbonServer = new RibbonServer(serviceId, server,
            isSecure(server, serviceId),
            serverIntrospector(serviceId).getMetadata(server));
    return execute(serviceId, ribbonServer, request);
}

@Override
public <T> T execute(String serviceId, ServiceInstance serviceInstance,
        LoadBalancerRequest<T> request) throws IOException {
    Server server = null;
    if (serviceInstance instanceof RibbonServer) {
        server = ((RibbonServer) serviceInstance).getServer();
    }
    if (server == null) {
        throw new IllegalStateException("No instances available for " + serviceId);
    }

    try {
        // 處理地址，將服務名替換為真實的IP地址
        T returnVal = request.apply(serviceInstance);
        return returnVal;
    } catch (Exception ex) {
        // ...
    }
    return null;
}

這個 LoadBalancerRequest 其實就是 LoadBalancerInterceptor 的 intercept 中創建的一個匿名類，在它的函數式接口內，主要是用裝飾器 ServiceRequestWrapper 將 request 包了一層。

public LoadBalancerRequest<ClientHttpResponse> createRequest(final HttpRequest request, final byte[] body, final ClientHttpRequestExecution execution) {
    return instance -> {
        // 封裝 HttpRequest，ServiceRequestWrapper 重載了 getURI 方法。
        HttpRequest serviceRequest = new ServiceRequestWrapper(request, instance, this.loadBalancer);
        if (this.transformers != null) {
            for (LoadBalancerRequestTransformer transformer : this.transformers) {
                serviceRequest = transformer.transformRequest(serviceRequest, instance);
            }
        }
        // 繼續執行攔截器
        return execution.execute(serviceRequest, body);
    };
}

ServiceRequestWrapper 主要就是重寫了 getURI 方法，在重寫的 getURI 方法內，它用 loadBalancer 對 URI 進行了重構，進去可以發現，就是將原始地址中的服務名替換為 Server 的真實IP、端口地址。

@Override
public URI getURI() {
    // 重構 URI
    URI uri = this.loadBalancer.reconstructURI(this.instance, getRequest().getURI());
    return uri;
}

public URI reconstructURI(ServiceInstance instance, URI original) {
    Assert.notNull(instance, "instance can not be null");
    // 服務名
    String serviceId = instance.getServiceId();
    RibbonLoadBalancerContext context = this.clientFactory.getLoadBalancerContext(serviceId);

    URI uri;
    Server server;
    if (instance instanceof RibbonServer) {
        RibbonServer ribbonServer = (RibbonServer) instance;
        server = ribbonServer.getServer();
        uri = updateToSecureConnectionIfNeeded(original, ribbonServer);
    }
    else {
        server = new Server(instance.getScheme(), instance.getHost(), instance.getPort());
        IClientConfig clientConfig = clientFactory.getClientConfig(serviceId);
        ServerIntrospector serverIntrospector = serverIntrospector(serviceId);
        uri = updateToSecureConnectionIfNeeded(original, clientConfig, serverIntrospector, server);
    }
    // 重構地址
    return context.reconstructURIWithServer(server, uri);
}

reconstructURIWithServer：

public URI reconstructURIWithServer(Server server, URI original) {
    String host = server.getHost();
    int port = server.getPort();
    String scheme = server.getScheme();
    
    if (host.equals(original.getHost()) 
            && port == original.getPort()
            && scheme == original.getScheme()) {
        return original;
    }
    if (scheme == null) {
        scheme = original.getScheme();
    }
    if (scheme == null) {
        scheme = deriveSchemeAndPortFromPartialUri(original).first();
    }

    try {
        StringBuilder sb = new StringBuilder();
        sb.append(scheme).append("://");
        if (!Strings.isNullOrEmpty(original.getRawUserInfo())) {
            sb.append(original.getRawUserInfo()).append("@");
        }
        sb.append(host);
        if (port >= 0) {
            sb.append(":").append(port);
        }
        sb.append(original.getRawPath());
        if (!Strings.isNullOrEmpty(original.getRawQuery())) {
            sb.append("?").append(original.getRawQuery());
        }
        if (!Strings.isNullOrEmpty(original.getRawFragment())) {
            sb.append("#").append(original.getRawFragment());
        }
        URI newURI = new URI(sb.toString());
        return newURI;            
    } catch (URISyntaxException e) {
        throw new RuntimeException(e);
    }
}

5、RestTemplate 負載均衡總結

到這里，我們基本就弄清楚了一個簡單的 @LoadBalanced 注解如何讓 RestTemplate 具備了負載均衡的能力了，這一節來做個小結。

① RestTemplate 如何獲得負載均衡的能力

• 1）首先 RestTemplate 是 spring-web 模塊下一個訪問第三方 RESTful API 接口的網絡請求框架
• 2）在 spring cloud 微服務架構中，用 @LoadBalanced 對 RestTemplate 做個標記，就可以使 RestTemplate 具備負載均衡的能力
• 3）使 RestTemplate 具備負載均衡的核心組件就是 LoadBalancerAutoConfiguration 配置類中向其添加的 LoadBalancerInterceptor 負載均衡攔截器
• 4）RestTemplate 在發起 http 調用前，會遍歷所有攔截器來對 RestTemplate 定制化，LoadBalancerInterceptor 就是在這時將URI中的服務名替換為實例的真實IP地址。定制完成后，就會發起真正的 http 請求。
• 5）LoadBalancerInterceptor 又主要是使用負載均衡客戶端 LoadBalancerClient 來完成URI的重構的，LoadBalancerClient 就可以根據服務名查找一個可用的實例，然后重構URI。

② 核心組件

這里會涉及多個模塊，下面是核心組件的所屬模塊：

spring-web：

• RestTemplate
• InterceptingClientHttpRequest：執行攔截器，並發起最終http調用

spring-cloud-commons：

• @LoadBalanced
• LoadBalancerAutoConfiguration
• LoadBalancerRequestFactory：創建裝飾類 ServiceRequestWrapper 替換原來的 HttpRequest，重載 getURI 方法。
• LoadBalancerInterceptor：負載均衡攔截器
• LoadBalancerClient：負載均衡客戶端接口

spring-cloud-netflix-ribbon：

• RibbonLoadBalancerClient：LoadBalancerClient 的實現類，Ribbon 的負載均衡客戶端
• RibbonAutoConfiguration

ribbon-loadbalancer：

• ILoadBalancer：負載均衡器
• Server：實例

③ 最后再用一張圖把 RestTemplate 這塊的關系捋一下

三、ILoadBalancer 獲取 Server

從前面 RestTemplate 那張圖可以看出，使 RestTemplate 具備負載均衡的能力，最重要的一個組件之一就是 ILoadBalancer，因為要用它來獲取能調用的 Server，有了 Server 才能對原始帶有服務名的 URI 進行重構。這節就來看下 Ribbon 的負載均衡器 ILoadBalancer 是如何創建的以及如何通過它獲取 Server。

1、創建負載均衡器 ILoadBalancer

① SpringClientFactory與上下文

ILoadBalancer 是用 SpringClientFactory 的 getLoadBalancer 方法根據服務名獲取的，從 getInstance 一步步進去可以發現，每個服務都會創建一個 AnnotationConfigApplicationContext，也就是一個應用上下文 ApplicationContext。相當於就是一個服務綁定一個 ILoadBalancer。

public <C> C getInstance(String name, Class<C> type) {
    C instance = super.getInstance(name, type);
    if (instance != null) {
        return instance;
    }
    IClientConfig config = getInstance(name, IClientConfig.class);
    return instantiateWithConfig(getContext(name), type, config);
}

public <T> T getInstance(String name, Class<T> type) {
    // 根據名稱獲取
    AnnotationConfigApplicationContext context = getContext(name);
    if (BeanFactoryUtils.beanNamesForTypeIncludingAncestors(context, type).length > 0) {
        return context.getBean(type);
    }
    return null;
}

protected AnnotationConfigApplicationContext getContext(String name) {
    // contexts => Map<String, AnnotationConfigApplicationContext>
    if (!this.contexts.containsKey(name)) {
        synchronized (this.contexts) {
            if (!this.contexts.containsKey(name)) {
                this.contexts.put(name, createContext(name));
            }
        }
    }
    return this.contexts.get(name);
}

調試看下 AnnotationConfigApplicationContext 上下文，可以看到放入了與這個服務綁定的 ILoadBalancer、IClientConfig、RibbonLoadBalancerContext 等。

它這里為什么要每個服務都綁定一個 ApplicationContext 呢？我猜想應該是因為服務實例列表可以有多個來源，比如可以從 eureka 注冊中心獲取、可以通過代碼配置、可以通過配置文件配置，另外每個服務還可以有很多個性化的配置，有默認的配置、定制的全局配置、個別服務的特定配置等，它這樣做就便於用戶定制每個服務的負載均衡策略。

② Ribbon的飢餓加載

而且這個Ribbon客戶端的應用上下文默認是懶加載的，並不是在啟動的時候就加載上下文，而是在第一次調用的時候才會去初始化。

如果想服務啟動時就初始化，可以指定Ribbon客戶端的具體名稱，在啟動的時候就加載配置項的上下文：

ribbon:
  eager-load:
    enabled: true
    clients: demo-producer,demo-xxx

在 RibbonAutoConfiguration 配置類中可以找到這個飢餓配置，如果開啟了飢餓加載，就會創建 RibbonApplicationContextInitializer 來在啟動時初始化上下文。

@Bean
@ConditionalOnProperty("ribbon.eager-load.enabled")
public RibbonApplicationContextInitializer ribbonApplicationContextInitializer() {
    return new RibbonApplicationContextInitializer(springClientFactory(), ribbonEagerLoadProperties.getClients());
}

public class RibbonApplicationContextInitializer implements ApplicationListener<ApplicationReadyEvent> {
    private final SpringClientFactory springClientFactory;

    // List of Ribbon client names
    private final List<String> clientNames;

    public RibbonApplicationContextInitializer(SpringClientFactory springClientFactory, List<String> clientNames) {
        this.springClientFactory = springClientFactory;
        this.clientNames = clientNames;
    }

    protected void initialize() {
        if (clientNames != null) {
            for (String clientName : clientNames) {
                // 提前初始化上下文
                this.springClientFactory.getContext(clientName);
            }
        }
    }

    @Override
    public void onApplicationEvent(ApplicationReadyEvent event) {
        initialize();
    }
}

③ RibbonClientConfiguration

ILoadBalancer 的創建在哪呢？看 RibbonClientConfiguration，這個配置類提供了 ILoadBalancer 的默認創建方法，ILoadBalancer 的默認實現類為 ZoneAwareLoadBalancer。

public class RibbonClientConfiguration {

    public static final int DEFAULT_CONNECT_TIMEOUT = 1000;

    public static final int DEFAULT_READ_TIMEOUT = 1000;

    public static final boolean DEFAULT_GZIP_PAYLOAD = true;

    @RibbonClientName
    private String name = "client";

    @Autowired
    private PropertiesFactory propertiesFactory;

    @Bean
    @ConditionalOnMissingBean
    public IClientConfig ribbonClientConfig() {
        DefaultClientConfigImpl config = new DefaultClientConfigImpl();
        config.loadProperties(this.name);
        config.set(CommonClientConfigKey.ConnectTimeout, DEFAULT_CONNECT_TIMEOUT);
        config.set(CommonClientConfigKey.ReadTimeout, DEFAULT_READ_TIMEOUT);
        config.set(CommonClientConfigKey.GZipPayload, DEFAULT_GZIP_PAYLOAD);
        return config;
    }

    @Bean
    @ConditionalOnMissingBean
    public IRule ribbonRule(IClientConfig config) {
        if (this.propertiesFactory.isSet(IRule.class, name)) {
            return this.propertiesFactory.get(IRule.class, config, name);
        }
        ZoneAvoidanceRule rule = new ZoneAvoidanceRule();
        rule.initWithNiwsConfig(config);
        return rule;
    }

    @Bean
    @ConditionalOnMissingBean
    public IPing ribbonPing(IClientConfig config) {
        if (this.propertiesFactory.isSet(IPing.class, name)) {
            return this.propertiesFactory.get(IPing.class, config, name);
        }
        return new DummyPing();
    }

    @Bean
    @ConditionalOnMissingBean
    @SuppressWarnings("unchecked")
    public ServerList<Server> ribbonServerList(IClientConfig config) {
        if (this.propertiesFactory.isSet(ServerList.class, name)) {
            return this.propertiesFactory.get(ServerList.class, config, name);
        }
        ConfigurationBasedServerList serverList = new ConfigurationBasedServerList();
        serverList.initWithNiwsConfig(config);
        return serverList;
    }

    @Bean
    @ConditionalOnMissingBean
    public ServerListUpdater ribbonServerListUpdater(IClientConfig config) {
        return new PollingServerListUpdater(config);
    }

    @Bean
    @ConditionalOnMissingBean
    @SuppressWarnings("unchecked")
    public ServerListFilter<Server> ribbonServerListFilter(IClientConfig config) {
        if (this.propertiesFactory.isSet(ServerListFilter.class, name)) {
            return this.propertiesFactory.get(ServerListFilter.class, config, name);
        }
        ZonePreferenceServerListFilter filter = new ZonePreferenceServerListFilter();
        filter.initWithNiwsConfig(config);
        return filter;
    }

    @Bean
    @ConditionalOnMissingBean
    public ILoadBalancer ribbonLoadBalancer(IClientConfig config,
            ServerList<Server> serverList, ServerListFilter<Server> serverListFilter,
            IRule rule, IPing ping, ServerListUpdater serverListUpdater) {
        // 先判斷配置文件中是否配置了負載均衡器
        if (this.propertiesFactory.isSet(ILoadBalancer.class, name)) {
            // 通過反射創建
            return this.propertiesFactory.get(ILoadBalancer.class, config, name);
        }
        return new ZoneAwareLoadBalancer<>(config, rule, ping, serverList,
                serverListFilter, serverListUpdater);
    }
}

可以看到創建 ILoadBalancer 需要 IClientConfig、ServerList<Server>、ServerListFilter<Server>、IRule、IPing、ServerListUpdater，其實這6個接口加上 ILoadBalancer 就是 Ribbon 的核心接口，它們共同定義了 Ribbon 的行為特性。

這7個核心接口和默認實現類如下：

2、客戶端 Ribbon 定制

可以看到在 RibbonClientConfiguration 中創建 IRule、IPing、ServerList<Server>、ServerListFilter<Server>、ILoadBalancer 時，都先通過 propertiesFactory.isSet 判斷是否已配置了對應類型的實現類，沒有才使用默認的實現類。

也就是說針對特定的服務，這幾個類可以自行定制化，也可以通過配置指定其它的實現類。

① 全局策略配置

如果想要全局更改配置，需要加一個配置類，比如像下面這樣：

@Configuration
public class GlobalRibbonConfiguration {

    @Bean
    public IRule ribbonRule() {
        return new RandomRule();
    }

    @Bean
    public IPing ribbonPing() {
        return new NoOpPing();
    }
}

② 基於注解的配置

如果想針對某一個服務定制配置，可以通過 @RibbonClients 來配置特定服務的配置類。

需要先定義一個服務配置類：

@Configuration
public class ProducerRibbonConfiguration {

    @Bean
    public IRule ribbonRule() {
        return new RandomRule();
    }

    @Bean
    public IPing ribbonPing() {
        return new NoOpPing();
    }
}

用 @RibbonClients 注解為服務指定特定的配置類，並排除掉，不讓 Spring 掃描，否則就變成了全局配置了。

@RibbonClients({
    @RibbonClient(name = "demo-producer", configuration = ProducerRibbonConfiguration.class)
})
@ComponentScan(excludeFilters = {
    @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, classes = ProducerRibbonConfiguration.class)
})

③ 配置文件配置

通過配置文件的方式來配置，配置的格式就是 <服務名稱>.ribbon.<屬性>：

demo-producer:
  ribbon:
    # ILoadBalancer
    NFLoadBalancerClassName: com.netflix.loadbalancer.NoOpLoadBalancer
    # IRule
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
    # IPing
    NFLoadBalancerPingClassName:
    # ServerList<Server>
    NIWSServerListClassName:
    # ServerListFilter<Server>
    NIWSServerListFilterClassName:

④ 優先級順序

這幾種配置方式的優先級順序是 配置文件配置 > @RibbonClients 配置 > 全局配置 > 默認配置。

3、ZoneAwareLoadBalancer 選擇 Server

獲取到 ILoadBalancer 后，就要去獲取 Server 了，可以看到，就是用 ILoadBalancer 來獲取 Server。

protected Server getServer(ILoadBalancer loadBalancer, Object hint) {
    if (loadBalancer == null) {
        return null;
    }
    // Use 'default' on a null hint, or just pass it on?
    return loadBalancer.chooseServer(hint != null ? hint : "default");
}

ILoadBalancer  的默認實現類是 ZoneAwareLoadBalancer，進入它的 chooseServer 方法內，如果只配置了一個 zone，就走父類的 chooseServer，否則從多個 zone 中去選擇實例。

public Server chooseServer(Object key) {
    // ENABLED => ZoneAwareNIWSDiscoveryLoadBalancer.enabled 默認 true
    // AvailableZones 配置的只有一個 defaultZone
    if (!ENABLED.get() || getLoadBalancerStats().getAvailableZones().size() <= 1) {
        logger.debug("Zone aware logic disabled or there is only one zone");
        // 走父類獲取 Server 的邏輯
        return super.chooseServer(key);
    }
    
    // 多 zone 邏輯....
}

先看下 ZoneAwareLoadBalancer 的類繼承結構，ZoneAwareLoadBalancer 的直接父類是 DynamicServerListLoadBalancer，DynamicServerListLoadBalancer 的父類又是 BaseLoadBalancer。

ZoneAwareLoadBalancer 調用父類的 chooseServer 方法是在 BaseLoadBalancer 中的，進去可以看到，它主要是用 IRule 來選擇實例，最終選擇實例的策略就交給了 IRule 接口。

public Server chooseServer(Object key) {
    if (counter == null) {
        counter = createCounter();
    }
    counter.increment();
    if (rule == null) {
        return null;
    } else {
        try {
            // IRule
            return rule.choose(key);
        } catch (Exception e) {
            logger.warn("LoadBalancer [{}]:  Error choosing server for key {}", name, key, e);
            return null;
        }
    }
}

4、ZoneAvoidanceRule 斷言篩選、輪詢選擇 Server

IRule 的默認實現類是 ZoneAvoidanceRule，先看下 ZoneAvoidanceRule 的繼承結構，ZoneAvoidanceRule 的直接父類是 PredicateBasedRule。

rule.choose 的邏輯在 PredicateBasedRule 中，getPredicate() 返回的是 ZoneAvoidanceRule 創建的一個組合斷言 CompositePredicate，就是用這個斷言來過濾出可用的 Server，並通過輪詢的策略返回一個 Server。

public Server choose(Object key) {
    ILoadBalancer lb = getLoadBalancer();
    // getPredicate() Server斷言 => CompositePredicate
    // RoundRobin 輪詢方式獲取實例
    Optional<Server> server = getPredicate().chooseRoundRobinAfterFiltering(lb.getAllServers(), key);
    if (server.isPresent()) {
        return server.get();
    } else {
        return null;
    }       
}

在初始化 ZoneAvoidanceRule 配置時，創建了 CompositePredicate，可以看到這個組合斷言主要有兩個斷言，一個是斷言 Server 的 zone 是否可用，一個斷言 Server 本身是否可用，例如 Server 無法 ping 通。

public void initWithNiwsConfig(IClientConfig clientConfig) {
    // 斷言 Server 的 zone 是否可用，只有一個 defaultZone 的情況下都是可用的
    ZoneAvoidancePredicate zonePredicate = new ZoneAvoidancePredicate(this, clientConfig);
    // 斷言 Server 是否可用
    AvailabilityPredicate availabilityPredicate = new AvailabilityPredicate(this, clientConfig);
    // 封裝組合斷言
    compositePredicate = createCompositePredicate(zonePredicate, availabilityPredicate);
}

private CompositePredicate createCompositePredicate(ZoneAvoidancePredicate p1, AvailabilityPredicate p2) {
    // 建造者模式創建斷言
    return CompositePredicate.withPredicates(p1, p2)
                         .addFallbackPredicate(p2)
                         .addFallbackPredicate(AbstractServerPredicate.alwaysTrue())
                         .build();
    
}

接着看選擇Server的 chooseRoundRobinAfterFiltering，參數 servers 是通過 ILoadBalancer 獲取的所有實例，可以看到它其實就是返回了 ILoadBalancer 在內存中緩存的服務所有 Server。這個 Server 從哪來的我們后面再來看。

public List<Server> getAllServers() {
    // allServerList => List<Server>
    return Collections.unmodifiableList(allServerList);
}

先對所有實例通過斷言過濾掉不可用的 Server，然后是通過輪詢的方式獲取一個 Server 返回。這就是默認配置下 ILoadBalancer（ZoneAwareLoadBalancer） 通過 IRule（ZoneAvoidanceRule） 選擇 Server 的流程了。

public Optional<Server> chooseRoundRobinAfterFiltering(List<Server> servers, Object loadBalancerKey) {
    // 斷言獲取可用的 Server
    List<Server> eligible = getEligibleServers(servers, loadBalancerKey);
    if (eligible.size() == 0) {
        return Optional.absent();
    }
    // 通過取模的方式輪詢 Server
    return Optional.of(eligible.get(incrementAndGetModulo(eligible.size())));
}

public List<Server> getEligibleServers(List<Server> servers, Object loadBalancerKey) {
    if (loadBalancerKey == null) {
        return ImmutableList.copyOf(Iterables.filter(servers, this.getServerOnlyPredicate()));            
    } else {
        List<Server> results = Lists.newArrayList();
        // 對每個 Server 斷言
        for (Server server: servers) {
            if (this.apply(new PredicateKey(loadBalancerKey, server))) {
                results.add(server);
            }
        }
        return results;            
    }
}

private int incrementAndGetModulo(int modulo) {
    for (;;) {
        int current = nextIndex.get();
        // 模運算取余數
        int next = (current + 1) % modulo;
        // CAS 更新 nextIndex
        if (nextIndex.compareAndSet(current, next) && current < modulo)
            return current;
    }
}

四、Ribbon 整合 Eureka Client 拉取Server列表

前面在通過 IRule 選擇 Server 的時候，首先通過 lb.getAllServers() 獲取了所有的 Server，那這些 Server 從哪里來的呢，這節就來看下。

1、ILoadBalancer 初始化

ILoadBalancer 的默認實現類是 ZoneAwareLoadBalancer，先從 ZoneAwareLoadBalancer 的構造方法進去看看都做了些什么事情。

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

可以看到，ZoneAwareLoadBalancer 直接調用了父類 DynamicServerListLoadBalancer 的構造方法，DynamicServerListLoadBalancer 先調用父類 BaseLoadBalancer 初始化，然后又做了一些剩余的初始化工作。

public ZoneAwareLoadBalancer(IClientConfig clientConfig, IRule rule,
                             IPing ping, ServerList<T> serverList, ServerListFilter<T> filter,
                             ServerListUpdater serverListUpdater) {
    // DynamicServerListLoadBalancer
    super(clientConfig, rule, ping, serverList, filter, serverListUpdater);
}

public DynamicServerListLoadBalancer(IClientConfig clientConfig, IRule rule, IPing ping,
                                     ServerList<T> serverList, ServerListFilter<T> filter,
                                     ServerListUpdater serverListUpdater) {
    // BaseLoadBalancer
    super(clientConfig, rule, ping);
    this.serverListImpl = serverList;
    this.filter = filter;
    this.serverListUpdater = serverListUpdater;
    if (filter instanceof AbstractServerListFilter) {
        ((AbstractServerListFilter) filter).setLoadBalancerStats(getLoadBalancerStats());
    }
    // 剩余的一些初始化
    restOfInit(clientConfig);
}

public BaseLoadBalancer(IClientConfig config, IRule rule, IPing ping) {
    // createLoadBalancerStatsFromConfig => LoadBalancerStats 統計
    initWithConfig(config, rule, ping, createLoadBalancerStatsFromConfig(config));

看 BaseLoadBalancer 的 initWithConfig，主要做了如下的初始化：

• 設置 IPing 和 IRule，ping 的間隔時間是 30 秒，setPing 會啟動一個后台定時任務，然后每隔30秒運行一次 PingTask 任務。
• 設置了 ILoadBalancer 的 統計器 LoadBalancerStats，對 ILoadBalancer 的 Server 狀態進行統計，比如連接失敗、成功、熔斷等信息。
• 在啟用 PrimeConnections 請求預熱的情況下，創建 PrimeConnections 來預熱客戶端 與 Server 的鏈接。默認是關閉的。
• 最后是注冊了一些監控、開啟請求預熱。

void initWithConfig(IClientConfig clientConfig, IRule rule, IPing ping, LoadBalancerStats stats) {
    this.config = clientConfig;
    String clientName = clientConfig.getClientName();
    this.name = clientName;
    // ping 間隔時間，默認30秒
    int pingIntervalTime = Integer.parseInt(""
            + clientConfig.getProperty(
                    CommonClientConfigKey.NFLoadBalancerPingInterval,
                    Integer.parseInt("30")));
    // 沒看到用的地方                
    int maxTotalPingTime = Integer.parseInt(""
            + clientConfig.getProperty(
                    CommonClientConfigKey.NFLoadBalancerMaxTotalPingTime,
                    Integer.parseInt("2")));
    // 設置 ping 間隔時間，並重新設置了 ping 任務
    setPingInterval(pingIntervalTime);
    setMaxTotalPingTime(maxTotalPingTime);

    // 設置 IRule、IPing
    setRule(rule);
    setPing(ping);

    setLoadBalancerStats(stats);
    rule.setLoadBalancer(this);
    if (ping instanceof AbstractLoadBalancerPing) {
        ((AbstractLoadBalancerPing) ping).setLoadBalancer(this);
    }
    logger.info("Client: {} instantiated a LoadBalancer: {}", name, this);
    
    // PrimeConnections，請求預熱，默認關閉
    // 作用主要用於解決那些部署環境(如讀EC2)在實際使用實時請求之前，從防火牆連接/路徑進行預熱（比如先加白名單、初始化等等動作比較耗時，可以用它先去打通）。
    boolean enablePrimeConnections = clientConfig.get(
            CommonClientConfigKey.EnablePrimeConnections, DefaultClientConfigImpl.DEFAULT_ENABLE_PRIME_CONNECTIONS);
    if (enablePrimeConnections) {
        this.setEnablePrimingConnections(true);
        PrimeConnections primeConnections = new PrimeConnections(
                this.getName(), clientConfig);
        this.setPrimeConnections(primeConnections);
    }
    // 注冊一些監控
    init();
}

protected void init() {
    Monitors.registerObject("LoadBalancer_" + name, this);
    // register the rule as it contains metric for available servers count
    Monitors.registerObject("Rule_" + name, this.getRule());
    // 默認關閉
    if (enablePrimingConnections && primeConnections != null) {
        primeConnections.primeConnections(getReachableServers());
    }
}

再看下 DynamicServerListLoadBalancer 的初始化，核心的初始化邏輯在 restOfInit 中，主要就是做了兩件事情：

• 開啟動態更新 Server 的特性，比如實例上線、下線、故障等，要能夠更新 ILoadBalancer 的 Server 列表。
• 然后就全量更新一次本地的 Server 列表。

void restOfInit(IClientConfig clientConfig) {
    boolean primeConnection = this.isEnablePrimingConnections();
    // turn this off to avoid duplicated asynchronous priming done in BaseLoadBalancer.setServerList()
    this.setEnablePrimingConnections(false);
    
    // 開啟動態更新 Server 的特性
    enableAndInitLearnNewServersFeature();

    // 更新 Server 列表
    updateListOfServers();
    
    // 開啟請求預熱的情況下，對可用的 Server 進行預熱
    if (primeConnection && this.getPrimeConnections() != null) {
        this.getPrimeConnections()
                .primeConnections(getReachableServers());
    }
    this.setEnablePrimingConnections(primeConnection);
    LOGGER.info("DynamicServerListLoadBalancer for client {} initialized: {}", clientConfig.getClientName(), this.toString());
}

2、全量更新Server列表

先看下 updateListOfServers() 是如何更新 Server 列表的，進而看下 ILoadBalancer 是如何存儲 Server 的。

• 首先使用 ServerList 獲取所有的 Server 列表，在 RibbonClientConfiguration 中配置的是 ConfigurationBasedServerList，但和 eureka 集合和，就不是 ConfigurationBasedServerList 了，這塊下一節再來看。
• 然后使用 ServerListFilter 對 Server 列表過濾，其默認實現類是 ZonePreferenceServerListFilter，它主要是過濾出當前 Zone（defaultZone）下的 Server。
• 最后就是更新所有 Server 列表，先是設置 Server alive，然后調用父類（BaseLoadBalancer）的 setServersList 來更新Server列表，這說明 Server 是存儲在 BaseLoadBalancer 里的。

public void updateListOfServers() {
    List<T> servers = new ArrayList<T>();
    if (serverListImpl != null) {
        // 從 ServerList 獲取所有 Server 列表
        servers = serverListImpl.getUpdatedListOfServers();
        LOGGER.debug("List of Servers for {} obtained from Discovery client: {}", getIdentifier(), servers);

        if (filter != null) {
            // 用 ServerListFilter 過濾 Server
            servers = filter.getFilteredListOfServers(servers);
            LOGGER.debug("Filtered List of Servers for {} obtained from Discovery client: {}", getIdentifier(), servers);
        }
    }
    // 更新所有 Server 到本地緩存
    updateAllServerList(servers);
}

protected void updateAllServerList(List<T> ls) {
    if (serverListUpdateInProgress.compareAndSet(false, true)) {
        try {
            for (T s : ls) {
                s.setAlive(true); // 設置 Server alive
            }
            setServersList(ls);
            // 強制初始化 Ping
            super.forceQuickPing();
        } finally {
            serverListUpdateInProgress.set(false);
        }
    }
}

public void setServersList(List lsrv) {
    // BaseLoadBalancer
    super.setServersList(lsrv);
    
    // 將 Server 更新到 LoadBalancerStats 統計中 ....
}

接着看父類的 setServersList，可以看出，存儲所有 Server 的數據結構 allServerList 是一個加了 synchronized 的線程安全的容器，setServersList 就是直接將得到的 Server 列表替換  allServerList。

public void setServersList(List lsrv) {
    Lock writeLock = allServerLock.writeLock();
    ArrayList<Server> newServers = new ArrayList<Server>();
    // 加寫鎖
    writeLock.lock();
    try {
        // for 循環將 lsrv 中的 Server 轉移到 allServers
        ArrayList<Server> allServers = new ArrayList<Server>();
        for (Object server : lsrv) {
            if (server == null) {
                continue;
            }
            if (server instanceof String) {
                server = new Server((String) server);
            }
            if (server instanceof Server) {
                logger.debug("LoadBalancer [{}]:  addServer [{}]", name, ((Server) server).getId());
                allServers.add((Server) server);
            } else {
                throw new IllegalArgumentException("Type String or Server expected, instead found:" + server.getClass());
            }
        }
        
        boolean listChanged = false;
        // allServerList => volatile List<Server> allServerList = Collections.synchronizedList(new ArrayList<Server>())
        if (!allServerList.equals(allServers)) {
            listChanged = true;
            // 服務列表變更監聽器 ServerListChangeListener， 發出服務變更通知...
        }
        
        // 啟用了服務預熱，開始 Server 預熱...
        
        // 直接替換
        allServerList = allServers;
        if (canSkipPing()) {
            for (Server s : allServerList) {
                s.setAlive(true);
            }
            upServerList = allServerList;
        } else if (listChanged) {
            forceQuickPing();
        }
    } finally {
        // 釋放寫鎖
        writeLock.unlock();
    }
}

前面 chooseRoundRobinAfterFiltering 獲取所有 Server 時就是返回的這個 allServerList列表。

public List<Server> getAllServers() {
    return Collections.unmodifiableList(allServerList);
}

3、Eureka Ribbon 客戶端配置

獲取 Server 的組件是 ServerList，RibbonClientConfiguration 中配置的默認實現類是 ConfigurationBasedServerList。ConfigurationBasedServerList 默認是從配置文件中獲取，可以像下面這樣配置服務實例地址，多個 Server 地址用逗號隔開。

demo-producer:
  ribbon:
    listOfServers: http://10.215.0.92:8010,http://10.215.0.92:8011

但是和 eureka-client 結合后，也就是引入 spring-cloud-starter-netflix-eureka-client 的客戶端依賴，它會幫我們引入 spring-cloud-netflix-eureka-client 依賴，這個包中有一個 RibbonEurekaAutoConfiguration 自動化配置類，它通過 @RibbonClients 注解定義了全局的 Ribbon 客戶端配置類 為 EurekaRibbonClientConfiguration

@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties
@ConditionalOnRibbonAndEurekaEnabled
@AutoConfigureAfter(RibbonAutoConfiguration.class)
@RibbonClients(defaultConfiguration = EurekaRibbonClientConfiguration.class)
public class RibbonEurekaAutoConfiguration {

}

進入 EurekaRibbonClientConfiguration  可以看到：

• IPing 的默認實現類為 NIWSDiscoveryPing。
• ServerList 的默認實現類為 DomainExtractingServerList，但是 DomainExtractingServerList 在構造時又傳入了一個類型為 DiscoveryEnabledNIWSServerList 的 ServerList。看名字大概也可以看出，DiscoveryEnabledNIWSServerList 就是從 EurekaClient 獲取 Server 的組件。

@Configuration(proxyBeanMethods = false)
public class EurekaRibbonClientConfiguration {
    @Value("${ribbon.eureka.approximateZoneFromHostname:false}")
    private boolean approximateZoneFromHostname = false;

    @RibbonClientName
    private String serviceId = "client";
    @Autowired
    private PropertiesFactory propertiesFactory;

    @Bean
    @ConditionalOnMissingBean
    public IPing ribbonPing(IClientConfig config) {
        if (this.propertiesFactory.isSet(IPing.class, serviceId)) {
            return this.propertiesFactory.get(IPing.class, config, serviceId);
        }
        NIWSDiscoveryPing ping = new NIWSDiscoveryPing();
        ping.initWithNiwsConfig(config);
        return ping;
    }

    @Bean
    @ConditionalOnMissingBean
    public ServerList<?> ribbonServerList(IClientConfig config,
            Provider<EurekaClient> eurekaClientProvider) {
        if (this.propertiesFactory.isSet(ServerList.class, serviceId)) {
            return this.propertiesFactory.get(ServerList.class, config, serviceId);
        }
        DiscoveryEnabledNIWSServerList discoveryServerList = new DiscoveryEnabledNIWSServerList(config, eurekaClientProvider);
        DomainExtractingServerList serverList = new DomainExtractingServerList(discoveryServerList, config, this.approximateZoneFromHostname);
        return serverList;
    }
}

4、從 DiscoveryClient 獲取Server列表

DynamicServerListLoadBalancer 中通過 ServerList 的 getUpdatedListOfServers 方法全量獲取服務列表，在 eureka-client 環境下，ServerList 默認實現類為 DomainExtractingServerList，那就先看下它的 getUpdatedListOfServers 方法。

可以看出，DomainExtractingServerList 先用 DomainExtractingServerList 獲取服務列表，然后根據 Ribbon 客戶端配置重新構造 Server 對象返回。獲取服務列表的核心在 DiscoveryEnabledNIWSServerList 中。

@Override
public List<DiscoveryEnabledServer> getUpdatedListOfServers() {
    // list => DiscoveryEnabledNIWSServerList
    List<DiscoveryEnabledServer> servers = setZones(this.list.getUpdatedListOfServers());
    return servers;
}

private List<DiscoveryEnabledServer> setZones(List<DiscoveryEnabledServer> servers) {
    List<DiscoveryEnabledServer> result = new ArrayList<>();
    boolean isSecure = this.ribbon.isSecure(true);
    boolean shouldUseIpAddr = this.ribbon.isUseIPAddrForServer();
    // 根據客戶端配置重新構造 DomainExtractingServer 返回
    for (DiscoveryEnabledServer server : servers) {
        result.add(new DomainExtractingServer(server, isSecure, shouldUseIpAddr, this.approximateZoneFromHostname));
    }
    return result;
}

先看下 DiscoveryEnabledNIWSServerList  的構造初始化：

• 主要是傳入了 Provider<EurekaClient> 用來獲取 EurekaClient
• 另外還設置了客戶端名稱 clientName ，以及 vipAddresses 也是客戶端名稱，這個后面會用得上。

public DiscoveryEnabledNIWSServerList(IClientConfig clientConfig, Provider<EurekaClient> eurekaClientProvider) {
    this.eurekaClientProvider = eurekaClientProvider;
    initWithNiwsConfig(clientConfig);
}

@Override
public void initWithNiwsConfig(IClientConfig clientConfig) {
    // 客戶端名稱，就是服務名稱
    clientName = clientConfig.getClientName();
    // vipAddresses 得到的也是客戶端名稱
    vipAddresses = clientConfig.resolveDeploymentContextbasedVipAddresses();
    
    // 其它的一些配置....
}

接着看獲取實例的 getUpdatedListOfServers，可以看到它的核心邏輯就是根據服務名從 EurekaClient 獲取 InstanceInfo 實例列表，然后封裝 Server 信息返回。

public List<DiscoveryEnabledServer> getUpdatedListOfServers(){
    return obtainServersViaDiscovery();
}

private List<DiscoveryEnabledServer> obtainServersViaDiscovery() {
    List<DiscoveryEnabledServer> serverList = new ArrayList<DiscoveryEnabledServer>();
    if (eurekaClientProvider == null || eurekaClientProvider.get() == null) {
        return new ArrayList<DiscoveryEnabledServer>();
    }
    // 得到 EurekaClient，實際類型是 CloudEurekaClient，其父類是 DiscoveryClient
    EurekaClient eurekaClient = eurekaClientProvider.get();
    if (vipAddresses!=null){
        // 分割 vipAddresses，默認就是服務名稱
        for (String vipAddress : vipAddresses.split(",")) {
            // 根據服務名稱從 EurekaClient 獲取實例信息
            List<InstanceInfo> listOfInstanceInfo = eurekaClient.getInstancesByVipAddress(vipAddress, isSecure, targetRegion);
            for (InstanceInfo ii : listOfInstanceInfo) {
                if (ii.getStatus().equals(InstanceStatus.UP)) {
                    // ...
                    // 根據實例信息 InstanceInfo 創建 Server
                    DiscoveryEnabledServer des = createServer(ii, isSecure, shouldUseIpAddr);
                    serverList.add(des);
                }
            }
            if (serverList.size()>0 && prioritizeVipAddressBasedServers){
                break; // if the current vipAddress has servers, we dont use subsequent vipAddress based servers
            }
        }
    }
    return serverList;
}

注意這里的 vipAddress 其實就是服務名：

最后看 EurekaClient 的 getInstancesByVipAddress，到這里就很清楚了，其實就是從 DiscoveryClient 的本地應用 Applications 中根據服務名取出所有的實例列表。

這里就和 Eureka 源碼那塊銜接上了，eureka-client 全量抓取注冊表以及每隔30秒增量抓取注冊表，都是合並到本地的 Applications 中。Ribbon 與 Eureka 結合后，Ribbon 獲取 Server 就從 DiscoveryClient 的 Applications 中獲取 Server 列表了。

public List<InstanceInfo> getInstancesByVipAddress(String vipAddress, boolean secure, String region) {
    // ...
    Applications applications;
    if (instanceRegionChecker.isLocalRegion(region)) {
        // 取本地應用 Applications
        applications = this.localRegionApps.get();
    } else {
        applications = remoteRegionVsApps.get(region);
        if (null == applications) {
            return Collections.emptyList();
        }
    }

    if (!secure) {
        // 返回服務名對應的實例
        return applications.getInstancesByVirtualHostName(vipAddress);
    } else {
        return applications.getInstancesBySecureVirtualHostName(vipAddress);
    }
}

5、定時更新Server列表

DynamicServerListLoadBalancer 初始化時，有個方法還沒說，就是 enableAndInitLearnNewServersFeature()。這個方法只是調用 ServerListUpdater 啟動了一個 UpdateAction，這個 UpdateAction 又只是調用了一下 updateListOfServers 方法，就是前面講解過的全量更新 Server 的邏輯。

public void enableAndInitLearnNewServersFeature() {
    serverListUpdater.start(updateAction);
}

protected final ServerListUpdater.UpdateAction updateAction = new ServerListUpdater.UpdateAction() {
    @Override
    public void doUpdate() {
        // 調用 updateListOfServers
        updateListOfServers();
    }
};

ServerListUpdater 的默認實現類是 PollingServerListUpdater，看下它的 start 方法：

其實就是以固定的頻率，每隔30秒調用一下 updateListOfServers 方法，將 DiscoveryClient 中 Applications 中緩存的實例同步到 ILoadBalancer 中的 allServerList 列表中。

public synchronized void start(final UpdateAction updateAction) {
    if (isActive.compareAndSet(false, true)) {
        final Runnable wrapperRunnable = new Runnable() {
            @Override
            public void run() {
                // ...
                try {
                    // 執行一次 updateListOfServers
                    updateAction.doUpdate();
                    // 設置最后更新時間
                    lastUpdated = System.currentTimeMillis();
                } catch (Exception e) {
                    logger.warn("Failed one update cycle", e);
                }
            }
        };
        
        // 固定頻率調度
        scheduledFuture = getRefreshExecutor().scheduleWithFixedDelay(
                wrapperRunnable,
                initialDelayMs, // 默認 1000
                refreshIntervalMs, // 默認 30 * 1000
                TimeUnit.MILLISECONDS
        );
    } else {
        logger.info("Already active, no-op");
    }
}

6、判斷Server是否存活

在創建 ILoadBalancer 時，IPing 還沒有看過是如何工作的。在初始化的時候，可以看到，主要就是設置了當前的 ping，然后重新設置了一個調度任務，默認每隔30秒調度一次 PingTask 任務。

public void setPing(IPing ping) {
    if (ping != null) {
        if (!ping.equals(this.ping)) {
            this.ping = ping;
            // 設置 Ping 任務
            setupPingTask();
        }
    } else {
        this.ping = null;
        // cancel the timer task
        lbTimer.cancel();
    }
}

void setupPingTask() {
    // ...
    // 創建一個定時調度器
    lbTimer = new ShutdownEnabledTimer("NFLoadBalancer-PingTimer-" + name, true);
    // pingIntervalTime 默認為 30 秒，每隔30秒調度一次 PingTask
    lbTimer.schedule(new PingTask(), 0, pingIntervalSeconds * 1000);
    // 立即發起以 Ping
    forceQuickPing();
}

ShutdownEnabledTimer 可以簡單了解下，它是繼承自 Timer 的，它在創建的時候向 Runtime 注冊了一個回調，在 jvm 關閉的時候來取消 Timer 的執行，進而釋放資源。

public class ShutdownEnabledTimer extends Timer {
    private static final Logger LOGGER = LoggerFactory.getLogger(ShutdownEnabledTimer.class);

    private Thread cancelThread;
    private String name;

    public ShutdownEnabledTimer(String name, boolean daemon) {
        super(name, daemon);
        this.name = name;
        // 取消定時器的線程
        this.cancelThread = new Thread(new Runnable() {
            public void run() {
                ShutdownEnabledTimer.super.cancel();
            }
        });

        LOGGER.info("Shutdown hook installed for: {}", this.name);
        // 向 Runtime 注冊一個鈎子，在 jvm 關閉時，調用 cancelThread 取消定時任務
        Runtime.getRuntime().addShutdownHook(this.cancelThread);
    }

    @Override
    public void cancel() {
        super.cancel();
        LOGGER.info("Shutdown hook removed for: {}", this.name);
        try {
            Runtime.getRuntime().removeShutdownHook(this.cancelThread);
        } catch (IllegalStateException ise) {
            LOGGER.info("Exception caught (might be ok if at shutdown)", ise);
        }

    }
}

再來看下 PingTask，PingTask 核心邏輯就是遍歷 allServers 列表，使用 IPingStrategy 和 IPing 來判斷 Server 是否存活，並更新 Server 的狀態，以及將所有存活的 Server 更新到 upServerList 中，upServerList 緩存了所有存活的 Server。

class PingTask extends TimerTask {
    public void run() {
        try {
            // pingStrategy => SerialPingStrategy
            new Pinger(pingStrategy).runPinger();
        } catch (Exception e) {
            logger.error("LoadBalancer [{}]: Error pinging", name, e);
        }
    }
}

class Pinger {
    private final IPingStrategy pingerStrategy;

    public Pinger(IPingStrategy pingerStrategy) {
        this.pingerStrategy = pingerStrategy;
    }

    public void runPinger() throws Exception {
        if (!pingInProgress.compareAndSet(false, true)) { 
            return; // Ping in progress - nothing to do
        }

        Server[] allServers = null;
        boolean[] results = null;

        Lock allLock = null;
        Lock upLock = null;
        
        try {
            allLock = allServerLock.readLock();
            allLock.lock();
            // 加讀鎖，取出 allServerList 中的 Server
            allServers = allServerList.toArray(new Server[allServerList.size()]);
            allLock.unlock();

            int numCandidates = allServers.length;
            // 使用 IPingStrategy 和 IPing 對所有 Server 發起 ping 請求
            results = pingerStrategy.pingServers(ping, allServers);

            final List<Server> newUpList = new ArrayList<Server>();
            final List<Server> changedServers = new ArrayList<Server>();

            for (int i = 0; i < numCandidates; i++) {
                boolean isAlive = results[i];
                Server svr = allServers[i];
                boolean oldIsAlive = svr.isAlive();
                // 設置 alive 是否存活
                svr.setAlive(isAlive);

                // 實例變更
                if (oldIsAlive != isAlive) {
                    changedServers.add(svr);
                    logger.debug("LoadBalancer [{}]:  Server [{}] status changed to {}",  name, svr.getId(), (isAlive ? "ALIVE" : "DEAD"));
                }

                // 添加存活的 Server
                if (isAlive) {
                    newUpList.add(svr);
                }
            }
            upLock = upServerLock.writeLock();
            upLock.lock();
            // 更新 upServerList，upServerList 只保存了存活的 Server
            upServerList = newUpList;
            upLock.unlock();
            // 通知變更
            notifyServerStatusChangeListener(changedServers);
        } finally {
            pingInProgress.set(false);
        }
    }
}

IPingStrategy 的默認實現類是 SerialPingStrategy，進入可以發現它只是遍歷所有 Server，然后用 IPing 判斷 Server 是否存活。

private static class SerialPingStrategy implements IPingStrategy {
    @Override
    public boolean[] pingServers(IPing ping, Server[] servers) {
        int numCandidates = servers.length;
        boolean[] results = new boolean[numCandidates];

        for (int i = 0; i < numCandidates; i++) {
            results[i] = false;
            try {
                if (ping != null) {
                    // 使用 IPing 判斷 Server 是否存活
                    results[i] = ping.isAlive(servers[i]);
                }
            } catch (Exception e) {
                logger.error("Exception while pinging Server: '{}'", servers[i], e);
            }
        }
        return results;
    }
}

在集成 eureka-client 后，IPing默認實現類是 NIWSDiscoveryPing，看它的 isAlive 方法，其實就是判斷對應 Server 的實例 InstanceInfo 的狀態是否是 UP 狀態，UP狀態就表示 Server 存活。

public boolean isAlive(Server server) {
    boolean isAlive = true;
    if (server!=null && server instanceof DiscoveryEnabledServer){
        DiscoveryEnabledServer dServer = (DiscoveryEnabledServer)server;                
        InstanceInfo instanceInfo = dServer.getInstanceInfo();
        if (instanceInfo!=null){                    
            InstanceStatus status = instanceInfo.getStatus();
            if (status!=null){
                // 判斷Server對應的實例狀態是否是 UP
                isAlive = status.equals(InstanceStatus.UP);
            }
        }
    }
    return isAlive;
}

7、一張圖總結 Ribbon 核心原理

① Ribbon 核心工作原理總結

• 首先，Ribbon 的7個核心接口共同定義了 Ribbon 的行為特性，它們就是 Ribbon 的核心骨架。
• 使用 Ribbon 來對客戶端做負載均衡，基本的用法就是用 @LoadBalanced 注解標注一個 RestTemplate 的 bean 對象，之后在 LoadBalancerAutoConfiguration 配置類中會對帶有 @LoadBalanced 注解的 RestTemplate 添加 LoadBalancerInterceptor 攔截器。
• LoadBalancerInterceptor 會攔截 RestTemplate 的 HTTP 請求，將請求綁定進 Ribbon 負載均衡的生命周期，然后使用 LoadBalancerClient 的 execute 方法來處理請求。
• LoadBalancerClient 首先會得到一個 ILoadBalancer，再使用它去得到一個 Server，這個 Server 就是具體某一個實例的信息封裝。得到 Server 之后，就用 Server 的 IP 和端口重構原始 URI。
• ILoadBalancer 最終在選擇實例的時候，會通過 IRule 均衡策略來選擇一個 Server。
• ILoadBalancer 的父類 BaseLoadBalancer 中有一個 allServerList 列表緩存了所有 Server，Ribbon 中 Server 的來源就是 allServerList。
• 在加載Ribbon客戶端上下文時，ILoadBalancer 會用 ServerList 從 DiscoveryClient 的 Applications 中獲取客戶端對應的實例列表，然后使用 ServerListFilter 過濾，最后更新到 allServerList 中。
• ILoadBalancer 還會開啟一個后台任務 ServerListUpdater ，每隔30秒運行一次，用 ServerList 將 DiscoveryClient 的 Applications 中的實例列表同步到 allServerList 中。
• ILoadBalancer 還會開啟一個后台任務 PingTask，每隔30秒運行一次，用 IPing 判斷 Server 的存活狀態，EurekaClient 環境下，就是判斷 InstanceInfo 的狀態是否為 UP。

② 下面用一張圖來總結下 Ribbon 這塊獲取Server的核心流程以及對應的核心接口間的關系。

8、Ribbon 脫離 Eureka 使用

在默認情況下，Ribbon 客戶端會從 EurekaClient 獲取服務列表，其實就是間接從注冊中心讀取服務注冊信息列表，來達到動態負載均衡的功能。但如果不想從 EurekaClient 讀取，可以禁用 Ribbon 的 Eureka 功能。
在 Ribbon 中禁用Eureka功能，可以做如下配置：

ribbon:
  eureka:
    enabled: false

那 ribbon.eureka.enabled 是如何控制禁用 Eureka 的呢？看 RibbonEurekaAutoConfiguration：

@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties
@ConditionalOnRibbonAndEurekaEnabled
@AutoConfigureAfter(RibbonAutoConfiguration.class)
@RibbonClients(defaultConfiguration = EurekaRibbonClientConfiguration.class)
public class RibbonEurekaAutoConfiguration {

}

這個配置類通過 @RibbonClients 指定了默認的客戶端配置類為 EurekaRibbonClientConfiguration，但生效的前提是 @ConditionalOnRibbonAndEurekaEnabled，進去可以看到這個條件注解就是判斷 Ribbon Eureka 是否啟用了，就可以設置 ribbon.eureka.enabled=false 來禁用 RIbbon Eureka。

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
// 條件類 OnRibbonAndEurekaEnabledCondition
@Conditional(ConditionalOnRibbonAndEurekaEnabled.OnRibbonAndEurekaEnabledCondition.class)
public @interface ConditionalOnRibbonAndEurekaEnabled {

    class OnRibbonAndEurekaEnabledCondition extends AllNestedConditions {

        OnRibbonAndEurekaEnabledCondition() {
            super(ConfigurationPhase.REGISTER_BEAN);
        }
        
        // 引入了類：DiscoveryEnabledNIWSServerList 
        @ConditionalOnClass(DiscoveryEnabledNIWSServerList.class)
        // 存在bean對象：SpringClientFactory
        @ConditionalOnBean(SpringClientFactory.class)
        // ribbon.eureka.enabled=true
        @ConditionalOnProperty(value = "ribbon.eureka.enabled", matchIfMissing = true)
        static class Defaults {

        }

        // 存在bean對象：EurekaClient
        @ConditionalOnBean(EurekaClient.class)
        static class EurekaBeans {

        }
        
        // eureka.client.enabled=true
        @ConditionalOnProperty(value = "eureka.client.enabled", matchIfMissing = true)
        @ConditionalOnDiscoveryEnabled
        static class OnEurekaClientEnabled {

        }
    }
}

如果想從其它地方獲取服務列表，可以自定義接口實現 ServerList<Server> 來獲取，也可以在配置文件中設置地址列表：

<client-name>:
  ribbon:
    listOfServers: http://10.215.0.92:8010,http://10.215.0.92:8011