Spring Cloud Commons官方文档链接

云原生运用

Cloud Native是一种运用程序开发风格，鼓舞在持续交给和价值驱动开发领域轻松选用最佳实践。一个相关的规程是构建12要素运用程序，其间开发实践与交给和操作目标坚持一致——例如，经过运用声明性编程、办理和监督。Spring Cloud以许多特定的办法促进了这些类型的开发。起点是一组特性，分布式体系中的一切组件都需求轻松拜访这些特性。

Spring Boot涵盖了许多这些特性，Spring Cloud便是在Spring Boot的基础上构建的。Spring Cloud以两个库的办法供给了更多的特性: Spring Cloud Context和Spring Cloud Commons。Spring Cloud Context为Spring Cloud运用程序的ApplicationContext供给实用程序和特别服务(引导上下文、加密、改写规模和环境端点)。Spring Cloud Commons是一组用于不同Spring Cloud完成(如Spring Cloud Netflix和Spring Cloud Consul)的笼统和公共类。

假如由于“非法密钥巨细”而呈现反常，而且运用Sun的JDK，则需求装置Java加密扩展(JCE)无限强度管辖战略文件。更多信息请拜见以下链接:

Java 6 JCE
Java 7 JCE
Java 8 JCE

Spring Cloud是在非限制性的Apache 2.0许可证下发布的。假如你想对这部分文档有所贡献，或许你发现了一个错误，你能够在{docslink}[github]找到项目的源代码和问题盯梢器。

1.Spring cloud context:运用上下文服务(Application Context Services)

Spring Boot关于怎么运用Spring构建运用程序有着顽固的看法。例如，它具有用于公共装备文件的常规方位，并具有用于公共办理和监督使命的端点(endpoints)。Spring Cloud在此基础上构建，并增加了一些体系中的许多组件会运用或偶尔需求的特性。

1.1.The Bootstrap Application Context(Bootstrap运用程序的上下文)

Spring Cloud运用程序经过创立一个bootstrap上下文来操作，它是主运用程序的 parent context。此上下文负责从外部源加载装备特点，并解密本地外部装备文件中的特点。这两个上下文同享一个Environment，它是任何Spring运用程序的外部特点的来源。默许状况下，bootstrap特点(不是bootstrap.properties，而是在引导阶段加载的特点)是以高优先级增加的，因而它们不能被本地装备掩盖。
bootstrap上下文运用了与主运用程序上下文不同的外部装备定位约好。你能够运用bootstrap.yml来代替application.yml（或.properties），这样能够很好地将bootstrap和主上下文的外部装备分开。下面的列表显现了一个比如。

Example 1. bootstrap.yml

spring:
  application:
    name: foo
  cloud:
    config:
      uri: ${SPRING_CONFIG_URI:http://localhost:8888}

假如您的运用程序需求从服务器上进行任何特定于运用程序的装备，最好是设置spring.application.name（在bootstrap.yml或application.yml中）。要使特点spring.application.name被用作运用程序的上下文ID，你有必要在bootstrap.[properties | yml]中设置它。

假如你想检索特定的装备文件装备，你还应该在bootstrap.[properties|yml]中设置spring.profiles.active。

你能够经过设置spring.cloud.bootstrap.enabled=false（例如，在体系特点中）来彻底禁用引导进程。

1.2. Application Context Hierarchies（运用情境层次结构)

假如您从SpringApplication或SpringApplicationBuilder构建运用程序上下文，那么Bootstrap上下文将作为parent上下文增加到该上下文。Spring的一个特性是，子上下文从其父上下文承继特点源和装备文件，与构建没有Spring Cloud Config的相同上下文相比,main运用程序上下文包含额定的特点源。其他额定的特点源包含:

bootstrap: 假如在bootstrap上下文中发现任何PropertySourceLocators，而且它们有非空的特点，则会呈现一个可选的具有高优先级的CompositePropertySource。一个比如是来自Spring Cloud装备服务器的特点, 有关怎么自界说这个特点源的内容，请参阅自界说Bootstrap特点源。
applicationConfig:[classpath:bootstrap.yml]（假如Spring装备文件处于活动状况，还包含相关文件）。假如你有一个bootstrap.yml（或.properties），这些特点被用来装备bootstrap上下文。然后当它的父类被设置时，它们会被增加到子类上下文中。它们的优先级低于application.yml（或.properties）以及作为创立Spring Boot运用程序进程的正常部分而被增加到子环境中的任何其他特点源。拜见改动Bootstrap特点的方位，了解怎么定制这些特点源的内容。

由于特点源的排序规矩，bootstrap条目具有优先权。然而，请注意这些并不包含来自bootstrap.yml的任何数据，后者的优先级很低，但能够用来设置默许值。

你能够经过设置你创立的任何ApplicationContext的父级上下文来扩展上下文层次结构–例如，经过运用它自己的接口或运用SpringApplicationBuilder的便利办法（parent()、child()和sibling()）。Bootstrap上下文是你自己创立的最高级先人的父级。层次结构中的每个上下文都有它自己的 “Bootstrap”（或许是空的）特点源，以避免不经意地将值从父代向下推广到他们的子代。假如有装备服务器，层次结构中的每个上下文(原则上)也能够有不同的spring.application.name，因而也能够有不同的长途特点源。正常的Spring运用上下文行为规矩适用于特点解析：子上下文的特点经过称号和特点源称号掩盖父上下文的特点。(假如子节点的特点源与父节点同名，则父节点的值不包含在子节点中)。

请注意，SpringApplicationBuilder答应你在整个层次结构中同享一个环境，但这并不是默许的。因而，兄弟情境（尤其是）不需求有相同的装备文件或特点源，虽然它们或许与父级同享共同的值。

1.3. 更改Bootstrap Properties的方位(Changing the Location of Bootstrap Properties)

bootstrap.yml（或.properties）的方位能够经过设置spring.cloud.bootstrap.name（默许：bootstrap）、spring.cloud.bootstrap.location（默许：空）或spring.cloud.bootstrap.additional-location（默许：空）来指定 – 例如，在体系特点中。

这些特点的行为与同名的spring.config.*变体类似。运用spring.cloud.bootstrap.location，会替换默许方位，且只运用指定的方位。要将方位增加到默许方位列表中，能够运用spring.cloud.bootstrap.additional-location。实践上，它们经过在环境中设置这些特点来装备bootstrap ApplicationContext。假如有一个活动的装备文件（从spring.profiles.active或经过你正在构建的上下文中的环境API），该装备文件中的特点也会被加载，与一般的Spring Boot运用程序相同–例如，从bootstrap-development.properties获取开发装备文件。

1.4. 掩盖长途特点的值(Overriding the Values of Remote Properties)

痛过bootstrap上下文增加到你的运用程序中的特点源通常是 “长途 “的(也便是长途的特点装备不会被本地掩盖)（例如，来自Spring Cloud Config Server）。默许状况下，它们不能被本地掩盖。假如你想让你的运用程序用自己的体系特点或装备文件掩盖长途特点，长途特点源有必要经过设置spring.cloud.config.allowOverride=true来颁发它权限 （在本地设置这个是不可的） 。一旦该标志被设置，两个更细化的设置将操控长途特点与体系特点和运用程序本地装备之间的方位。

spring.cloud.config.overrideNone=true:从任何本地特点源重写。
spring.cloud.config.overrideSystemProperties=false：只需体系特点、命令行参数和环境变量（但不是本地装备文件）应掩盖长途设置。

1.5. 定制Bootstrap装备(Customizing the Bootstrap Configuration)

经过在/META-INF/spring.factories中增加名为org.springframework.cloud.bootstrap.BootstrapConfiguration作key的条目，能够将bootstrap上下文设置为你想做的任何事情。这包含一个逗号分隔的Spring @Configuration类列表，用于创立上下文。您期望主运用程序上下文中用于主动装置的任何beans都能够在这里创立。关于ApplicationContextInitializer类型的@Beans有一个特别的契约：假如你想操控发动次序，你能够用@Order注解来标记类（默许次序是最后一个）。

当增加自界说BootstrapConfiguration时，要注意你增加的类不会被@ComponentScanned误入你的 “主 “运用程序上下文，由于那里或许不需求它们。为发动装备类运用一个单独的包名，并保证该称号没有被你的@ComponentScan或@SpringBootApplication注释的装备类所掩盖。

引导进程以向主SpringApplication实例注入初始化程序而完毕（这是正常的Spring Boot发动次序，不管它是作为独立的运用程序运行仍是布置在运用程序服务器中）。首先，从spring.factories中找到的类创立一个bootstrap上下文。然后，在主SpringApplication发动前，将一切ApplicationContextInitializer类型的@Beans增加到主SpringApplication中。

1.6.定制Bootstrap特点源(Customizing the Bootstrap Property Sources)

Bootstrap进程增加的外部装备的默许特点源是Spring Cloud Config Server，但你能够经过向Bootstrap上下文增加PropertySourceLocator类型的bean（经过spring.factories）来增加额定的来源。例如，你能够从不同的服务器或数据库中刺进额定的特点。也便是能够经过此办法来调价额定的装备源。

@Configuration
public class CustomPropertySourceLocator implements PropertySourceLocator {
    @Override
    public PropertySource<?> locate(Environment environment) {
        return new MapPropertySource("customProperty",
                Collections.<String, Object>singletonMap("property.from.sample.custom.source", "worked as intended"));
    }
}

传入的环境是行将创立的ApplicationContext的环境–换句话说，是咱们供给额定特点源的环境。它现已有了正常的Spring Boot供给的特点源，所以你能够运用这些特点源来定位该环境的特定特点源（例如，经过键入spring.application.name，正如默许的Spring Cloud Config Server特点源定位器所做的那样）。

假如你创立了一个包含这个类的jar，然后增加一个包含以下设置的META-INF/factories，自界说特点PropertySource就会呈现在任安在classpath上包含该jar的运用程序中。

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator

1.7.日志装备

假如你运用Spring Boot来装备日志设置。假如你期望它适用于一切事情,你应该把这个装备放在bootstrap.[yml | properties]中，。

为了让Spring Cloud正确地初始化日志装备，你不能运用自界说的前缀。例如，在初始化日志体系时，运用custom.loggin.logpath不会被Spring Cloud辨认。

1.8.环境改动

运用程序监听EnvironmentChangeEvent，并以几种标准的办法对改动做出反响（额定的ApplicationListeners能够以正常的办法增加为@Beans）。当一个EnvironmentChangeEvent被观察届时，它有一个现已改动的关键值的列表，运用程序运用这些值来。

从头绑定上下文中的@ConfigurationPropertiesbeans .
为logging.level.*中的任何特点设置记载器等级。

请注意，Spring Cloud Config Client默许不会对环境中的改动进行轮询。一般来说，咱们不引荐用这种办法来检测改动（虽然你能够用@Scheduled注解来设置）。假如你有一个扩展的客户端运用程序，最好将EnvironmentChangeEvent播送给一切的实例，而不是让它们轮询改动（例如，经过运用Spring Cloud Bus）

EnvironmentChangeEvent涵盖了一大类改写用例，只需你能真正对环境做出改动并发布事情。请注意，这些API是公开的，是Spring核心的一部分）。你能够经过拜访/configprops端点（一个标准的Spring Boot Actuator功用）来验证这些改动是否与@ConfigurationProperties Bean绑定。例如，DataSource能够在运行时改动其maxPoolSize（Spring Boot创立的默许DataSource是一个@ConfigurationProperties Bean）并动态增长容量。从头绑定@ConfigurationProperties并不包含另一大类用例，在这些用例中，你需求对改写进行更多的操控，而且你需求对整个ApplicationContext进行原子式的更改。为了解决这些问题，咱们有@RefreshScope。

spring boot 2.3 Actuator 供给 /actuator/configprops 端点，供给对装备文件特点盯梢功用，便利咱们在 spring boot 运用中，实时的获取装备文件实践加载值。

需求注意的是：configprops Endpoint 会对灵敏字段默许脱敏，默许关键字类会进行脱敏，当然，这个能够自己装备

Spring Boot 2.3 中装备文件特点盯梢_coder吹雪的博客-CSDN博客

1.9. Refresh Scope

当装备发生改动时，被标记为@RefreshScope的Spring@Bean会得到特别处理。这个功用解决了有状况的Bean的问题，这些Bean只需在初始化时才会被注入装备。例如，假如一个DataSource在经过Environment改动数据库URL时有敞开的衔接，你或许期望这些衔接的持有者能够完结他们正在做的事情。然后，下次有东西从池中借用衔接时，它就会得到一个带有新URL的衔接。

有时，甚至有必要对一些只能初始化一次的Bean运用@RefreshScope注解。假如一个Bean是不可改动的，你有必要用@RefreshScope来注解这个Bean，或许在特点键下指定类名：spring.cloud.refresh.extra-refreshable,也便是一些类只能在spring生命周期内初始化一次，那么这种类需求@RefreshScope注解。

假如你有一个归于HikariDataSource的DataSource Bean，它不能被改写。这是 spring.cloud.refresh.never-refreshable 的默许值。假如你需求它被改写，请挑选一个不同的DataSource完成。

改写效果域Bean是懒散的代理，当它们被运用时（即当办法被调用时）就会初始化，效果域作为初始化值的缓存。要强制Bean鄙人一次办法调用时从头初始化，你有必要使其缓存条目失效。

RefreshScope是上下文中的一个Bean，它有一个公共的refreshAll()办法，经过清除目标缓存来改写该规模内的一切Bean。/refresh端点露出了这个功用（经过HTTP或JMX）。要按称号改写单个Bean，也有一个refresh(String)办法。

露出/refresh端点，你需求向你的运用程序增加以下装备:

management:
  endpoints:
    web:
      exposure:
        include: refresh

@RefreshScope（技术上）对@Configuration类起效果，但它或许导致令人惊讶的行为。例如，它并不意味着该类中界说的一切@Bean本身就在@RefreshScope中。具体地说，任何依靠于这些Bean的东西都不能依托它们在改写时被更新，除非它本身也在~中。在这种状况下，它在改写时被重建，其依靠联系被从头注入。在这一点上，它们会从改写的@Configuration中被从头初始化）。

1.10. Encryption and Decryption

Spring Cloud有一个环境预处理程序，用于在本地解密特点值。它遵循与Spring Cloud装备服务器相同的规矩，并经过encrypt.具有相同的外部装备。因而，你能够运用{cipher} 办法的加密值，只需有一个有效的密钥，它们就会在主运用程序上下文取得环境设置之前被解密。要在运用程序中运用加密功用，你需求在classpath中包含Spring Security RSA（Maven坐标：org.springframework.security:spring-security-rsa），而且你还需求在JVM中运用全强度的JCE扩展。

假如你因 “密钥巨细不合法 “而呈现反常，而且你运用Sun的JDK，你需求装置Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files。更多信息请拜见以下链接。`

Java 6 JCE
Java 7 JCE
Java 8 JCE

将这些文件解压到你所运用的JRE/JDK x64/x86的哪个版别的JDK/jre/lib/security文件夹中。

1.11. Endpoints

关于Spring Boot Actuator运用程序，有一些额定的办理端点可用。你能够运用:

POST到/actuator/env来更新环境并从头绑定@ConfigurationProperties和日志等级。要启用这个端点，你有必要设置management.endpoint.env.post.enabled=true。
/actuator/refresh从头加载发动带上下文并改写@RefreshScopeBean。
/actuator/restart关闭ApplicationContext并从头发动它（默许状况下禁用）。
/actuator/pause和/actuator/resume用于调用生命周期办法（ApplicationContext上的stop()和start()）。

假如你禁用了/actuator/restart端点，那么/actuator/pause和/actuator/resume端点也会被禁用，由于它们只是/actuator/restart的一种特别状况。

2.Spring Cloud Commons: 通用笼统

比如服务发现、负载平衡和断路器等模式合适于一个通用的笼统层，能够被一切的Spring Cloud客户端消费，与完成无关（例如，用Eureka或Consul发现）。

2.1.@EnableDiscoveryClient注解

Spring Cloud Commons供给了@EnableDiscoveryClient注解。Spring cloud会去寻觅META-INF/spring.factories中完成了DiscoveryClient和ReactiveDiscoveryClient接口的类。
自界说的discovery客户端需求在spring.factories中org.springframework.cloud.client.discovery.EnableDiscoveryClientkey下向增加一个对应自界说的类全称号。
DiscoveryClient完成的比如包含Spring Cloud Netflix Eureka、Spring Cloud Consul Discovery和Spring Cloud Zookeeper Discovery。

Spring Cloud默许供给堵塞式和反响式服务发现客户端。你能够经过设置spring.cloud.discovery.blocking.enabled=false或spring.cloud.discovery.reactive.enabled=false来轻松禁用堵塞式和/或反响式客户端。要彻底禁用服务发现，你只需求设置spring.cloud.discovery.enabled=false。

默许状况下，DiscoveryClient的完成会主动将本地Spring Boot服务器与长途发现服务器进行注册。这种行为能够经过在@EnableDiscoveryClient中设置autoRegister=false来禁用。

@EnableDiscoveryClient不再需求了。你能够在classpath上放置一个DiscoveryClient完成，以使Spring Boot运用程序在服务发现服务器注册。

2.1.1.健康目标

Commons主动装备了以下Spring Boot健康目标。

DiscoveryClientHealthIndicator

该健康目标是根据当时注册的DiscoveryClient完成。

要彻底禁用，请设置spring.cloud.discovery.client.health-indicator.enabled=false。
要禁用描述字段，请设置spring.cloud.discovery.client.health-indicator.include-description=false。否则，它能够作为发生的HealthIndicator的描述冒出来。
要禁用服务检索，请设置spring.cloud.discovery.client.health-indicator.use-services-query=false。默许状况下，该目标会调用客户端的getServices办法。在有许多注册服务的布置中，每次查看时检索一切服务的本钱或许太高。这将越过服务检索，去运用客户端的勘探办法(todo)。

发现复合健康目标(DiscoveryCompositeHealthContributor)

这个复合健康目标是根据一切注册的DiscoveryHealthIndicatorBean。要禁用，请设置spring.cloud.discovery.client.composite-indicator.enabled=false。

2.1.2.对DiscoveryClient实例进行排序

DiscoveryClient接口扩展了Ordered。这在运用多个发现客户端时非常有用，由于它答应你界说回来的发现客户端的次序，类似于你能够对Spring运用程序加载的Bean进行排序。默许状况下，任何DiscoveryClient的次序都被设置为0。假如你想为你的自界说DiscoveryClient完成设置一个不同的次序，你只需求掩盖getOrder()办法，使其回来合适你的设置的值即可。除此之外，你还能够运用特点来设置Spring Cloud供给的DiscoveryClient完成的次序，其间包含ConsulDiscoveryClient、EurekaDiscoveryClient和ZookeeperDiscoveryClient。为了做到这一点，你只需将spring.cloud.{clientIdentifier}.discovery.order（或eureka.client.order,）特点设置为所需值。

2.1.3.SimpleDiscoveryClient

假如在classpath中没有服务注册表支撑的DiscoveryClient，将运用SimpleDiscoveryClient实例，该实例运用特点来获取服务和实例的信息。
关于可用实例的信息应经过以下格局的特点传递：spring.cloud.discovery.client.simple.instances.service1[0].uri=http://s11:8080，其间spring.cloud.discovery.client.simple.instances是通用前缀，然后service1代表有关服务的 ID，而[0]表明实例的索引号（如示例中可见，索引以0开端），然后uri的值是实例可用的实践 URI。

2.2. ServiceRegistry

Commons现在供给了一个ServiceRegistry接口，供给了register(Registration)和deregister(Registration)等办法，让你供给自界说的注册服务。注册是一个标记性的接口。
下面的比如显现了运用中的ServiceRegistry:

@Configuration
@EnableDiscoveryClient(autoRegister=false)
public class MyConfiguration {
    private ServiceRegistry registry;
    public MyConfiguration(ServiceRegistry registry) {
        this.registry = registry;
    }
    // called through some external process, such as an event or a custom actuator endpoint
    public void register() {
        Registration registration = constructRegistration();
        this.registry.register(registration);
    }
}

每个ServiceRegistry的完成都有自己的Registry完成。

ZookeeperRegistration used with ZookeeperServiceRegistry
EurekaRegistration used with EurekaServiceRegistry
ConsulRegistration used with ConsulServiceRegistry
NacosRegistration used with NacosServiceRegistry

假如你正在运用ServiceRegistry接口，你将需求自己去完成ServiceRegistry。

2.2.1.服务注册处主动注册

默许状况下，ServiceRegistry完成会主动注册正在运行的服务。要禁用该行为，你能够设置。*@EnableDiscoveryClient(autoRegister=false)来永久地禁用主动注册。*spring.cloud.service-registry.auto-registration.enabled=false以经过装备禁用该行为。

服务注册处主动注册事情

当一个服务主动注册时，有两个事情将被触发。第一个事情，称为InstancePreRegisteredEvent，在服务被注册之前被触发。第二个事情，称为InstanceRegisteredEvent，在服务被注册后被触发。你能够注册一个ApplicationListener（s）来监听这些事情并作出反响。

假如spring.cloud.service-registry.auto-registration.enabled特点被设置为false，这些事情将不会被触发。

2.2.2. 服务注册处履行器端点

Spring Cloud Commons供给了一个/service-registry履行器端点。这个端点依靠于Spring运用上下文中的一个注册Bean。用GET办法调用/service-registry会回来注册的状况。运用JSON体对同一端点进行POST，将当时注册的状况改为新值。JSON主体有必要包含带有首选值的status字段。关于更新状况时答应的值和回来的状况值，请拜见您运用的ServiceRegistry完成的文档。例如，Eureka支撑的状况有：UP,DOWN,OUT_OF_SERVICE和UNKNOWN。

2.3. 作为负载均衡器客户端的Spring RestTemplate

你能够装备一个RestTemplate来运用一个负载平衡客户端。为了创立一个负载平衡的RestTemplate，创立一个RestTemplate @Bean，并运用@LoadBalanced限定词，如下例所示：

@Configuration
public class MyConfiguration {
    @LoadBalanced
    @Bean
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
public class MyClass {
    @Autowired
    private RestTemplate restTemplate;
    public String doOtherStuff() {
        String results = restTemplate.getForObject("http://stores/stores", String.class);
        return results;
    }
}

RestTemplate Bean不再经过主动装备创立。个人运用程序有必要创立它。

URI需求运用一个虚拟主机名（即服务名，而不是主机名）。BlockingLoadBalancerClient是用来创立一个完好的物理地址。

要运用负载平衡的RestTemplate，你需求在你的classpath中具有一个负载均衡器的完成。在你的项目中增加Spring Cloud LoadBalancer发动器，以便运用它。

2.4. 作为负载均衡器客户端的Spring WebClient

你能够将WebClient装备为主动运用一个负载平衡客户端。要创立一个负载平衡的WebClient，请创立一个WebClient.Builder @Bean并运用@LoadBalanced限定词，如下所示。

@Configuration
public class MyConfiguration {
    @Bean
    @LoadBalanced
    public WebClient.Builder loadBalancedWebClientBuilder() {
        return WebClient.builder();
    }
}
public class MyClass {
    @Autowired
    private WebClient.Builder webClientBuilder;
    public Mono<String> doOtherStuff() {
        return webClientBuilder.build().get().uri("http://stores/stores")
                        .retrieve().bodyToMono(String.class);
    }
}

URI需求运用一个虚拟主机名（即服务名，而不是主机名）。Spring Cloud LoadBalancer用于创立一个完好的物理地址。

假如你想运用@LoadBalanced WebClient.Builder，你需求在classpath中具有一个负载均衡器完成。咱们主张你在项目中增加Spring Cloud LoadBalancer start。然后，鄙人面运用ReactiveLoadBalancer。

2.4.1. 重试失利的恳求

负载均衡的RestTemplate能够被装备为重试失利的恳求。默许状况下，这种逻辑是禁用的。关于非反响式版别（运用RestTemplate），你能够经过在运用程序的classpath中增加Spring Retry来启用它。关于反响式版别（运用WebTestClient），你需求设置spring.cloud.loadbalancer.retry.enabled=true。

当然假如你想在classpath上禁用Spring Retry或Reactive Retry的重试逻辑，你能够设置spring.cloud.loadbalancer.retry.enabled=false。

关于非反响式完成，假如你想在重试中完成BackOffPolicy，你需求创立一个LoadBalancedRetryFactory类型的bean，并重载createBackOffPolicy()办法。

这里说一下BackOffPolicy: 重试的回退战略，在事务逻辑履行发生反常时。假如需求重试，咱们或许需求等一段时刻(或许服务器过于繁忙，假如一直不距离重试或许拖垮服务器)，当然这段时刻能够是0，也能够是固定的，能够是随机的（拜见tcp的拥塞操控算法中的回退战略）。

关于反响式完成，你只需求将spring.cloud.loadbalancer.retry.backoff.enabled设置为false，就能够启用。

你能够设置：

spring.cloud.loadbalancer.retry.maxRetriesOnSameServiceInstance– 指示在同一个服务实例上应重试多少次恳求（对每个选定的实例单独计算）。
spring.cloud.loadbalancer.retry.maxRetriesOnNextServiceInstance– 指示恳求应在新挑选的服务实例上重试多少次。
spring.cloud.loadbalancer.retry.retryableStatusCodes– 始终重试失利恳求的状况代码。

关于反响式完成，你能够额定设置。-spring.cloud.loadbalancer.retry.backoff.minBackoff– 设置最小回退时刻（默许为5毫秒） –spring.cloud.loadbalancer.retry.backoff.minBackoff– 设置最大回退时刻（默许为最大长值毫秒） –spring.cloud.loadbalancer.retry.backoff.jitter– 设置用于计算每次调用实践回退时刻的抖动（默许为0.5）。

关于反响式的完成，你也能够完成你自己的LoadBalancerRetryPolicy，以便对负载平衡的调用重试有更详细的操控。

除了前缀为spring.cloud.loadbalancer.clients.<clientId>.*，其间clientId是负载均衡器的称号外，单个负载均衡器客户端能够单独装备与上述相同的特点。

关于负载均衡重试，默许状况下，咱们用RetryAwareServiceInstanceListSupplierBean包裹ServiceInstanceListSupplier Bean，以挑选与之前挑选的实例不同的实例（假如有的话）。您能够经过将spring.cloud.loadbalancer.retry.avoidPreviousInstance的值设置为false来禁用这种行为。

@Configuration
public class MyConfiguration {
    @Bean
    LoadBalancedRetryFactory retryFactory() {
        return new LoadBalancedRetryFactory() {
            @Override
            public BackOffPolicy createBackOffPolicy(String service) {
                return new ExponentialBackOffPolicy();
            }
        };
    }
}

假如你想为你的重试功用增加一个或多个RetryListener完成，你需求创立一个LoadBalancedRetryListenerFactory类型的bean，并回来你想为给定服务运用的RetryListener数组，如下例所示:

@Configuration
public class MyConfiguration {
    @Bean
    LoadBalancedRetryListenerFactory retryListenerFactory() {
        return new LoadBalancedRetryListenerFactory() {
            @Override
            public RetryListener[] createRetryListeners(String service) {
                return new RetryListener[]{new RetryListener() {
                    @Override
                    public <T, E extends Throwable> boolean open(RetryContext context, RetryCallback<T, E> callback) {
                        //TODO Do you business...
                        return true;
                    }
                    @Override
                     public <T, E extends Throwable> void close(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
                        //TODO Do you business...
                    }
                    @Override
                    public <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
                        //TODO Do you business...
                    }
                }};
            }
        };
    }
}

2.5. 多个RestTemplate目标

假如你想要一个没有负载均衡的RestTemplate，能够创立一个RestTemplateBean并注入它。要拜访负载均衡的RestTemplate，在你创立@Bean时运用@LoadBalanced注解，如下例所示:

@Configuration
public class MyConfiguration {
    @LoadBalanced
    @Bean
    RestTemplate loadBalanced() {
        return new RestTemplate();
    }
    @Primary
    @Bean
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
public class MyClass {
@Autowired
private RestTemplate restTemplate;
    @Autowired
    @LoadBalanced
    private RestTemplate loadBalanced;
    public String doOtherStuff() {
        return loadBalanced.getForObject("http://stores/stores", String.class);
    }
    public String doStuff() {
        return restTemplate.getForObject("http://example.com", String.class);
    }
}

注意在前面的比如中，在一般的RestTemplate声明上运用了@Primary注解，以消除不合格的@Autowired注入的歧义。

假如你看到比如java.lang.IllegalArgumentException: Can not set org.springframework.web.client.RestTemplate field com.my.app.Foo.restTemplate to com.sun.proxy.$Proxy89，尝试注入RestOperations或设置spring.aop.proxyTargetClass=true。

2.6. 多个WebClient目标

假如你想要一个没有负载均衡的WebClient，能够创立一个WebClientBean并注入它。要拜访负载均衡的WebClient，请在创立@Bean时运用@LoadBalanced注解，如下例所示。

@Configuration
public class MyConfiguration {
    @LoadBalanced
    @Bean
    WebClient.Builder loadBalanced() {
        return WebClient.builder();
    }
    @Primary
    @Bean
    WebClient.Builder webClient() {
        return WebClient.builder();
    }
}
public class MyClass {
    @Autowired
    private WebClient.Builder webClientBuilder;
    @Autowired
    @LoadBalanced
    private WebClient.Builder loadBalanced;
    public Mono<String> doOtherStuff() {
        return loadBalanced.build().get().uri("http://stores/stores")
                        .retrieve().bodyToMono(String.class);
    }
    public Mono<String> doStuff() {
        return webClientBuilder.build().get().uri("http://example.com")
                        .retrieve().bodyToMono(String.class);
    }
}

2.7. 作为负载均衡器客户端的Spring WebFlux WebClient

Spring WebFlux能够与反响式和非反响式的WebClient装备一起工作，如主题所述。

运用ReactorLoadBalancerExchangeFilterFunction的Spring WebFlux WebClient

load-balancer-exchange-filter-functionload-balancer-exchange-filter-function。

2.8. 疏忽网络接口

有时，疏忽某些命名的网络接口是很有用的，这样它们就能够被扫除在服务发现注册之外（例如，在Docker容器中运行时）。能够设置一个正则表达式列表，使所需的网络接口被疏忽。下面的装备疏忽了docker0接口和一切以veth开头的接口。

Example 2. application.yml

spring:
  cloud:
    inetutils:
      ignoredInterfaces:
        - docker0
        - veth.*

你也能够经过运用正则表达式列表强制只运用指定的网络地址，如下例所示:

Example 3. bootstrap.yml

spring:
  cloud:
    inetutils:
      preferredNetworks:
        - 192.168
        - 10.0

你也能够强制只运用站点本地地址，如下例所示:

Example 4. application.yml

spring:
  cloud:
    inetutils:
      useOnlySiteLocalInterfaces: true

关于什么是站点-本地地址的更多细节，请拜见Inet4Address.html.isSiteLocalAddress()。

2.9. HTTP客户端工厂

Spring Cloud Commons供给了用于创立Apache HTTP客户端（ApacheHttpClientFactory）和OK HTTP客户端（OkHttpClientFactory）的bean。只需当OK HTTPjar在classpath上时才会创立OkHttpClientFactoryBean。此外，Spring Cloud Commons还供给了用于创立两种客户端所运用的衔接办理器的bean。

ApacheHttpClientConnectionManagerFactory用于Apache HTTP客户端，OkHttpClientConnectionPoolFactory用于OK HTTP客户端。假如你想自界说HTTP客户端鄙人游项目中的创立办法，你能够供给你自己对这些Bean的完成。此外，假如你供给一个HttpClientBuilder或OkHttpClient.Builder类型的bean，默许工厂会运用这些构建器作为回来给下流项目的构建器的基础。你也能够经过将spring.cloud.httpclientfactories.apache.enabled或spring.cloud.httpclientfactories.ok.enabled设置为false来禁用这些 bean 的创立。

2.10. 启用的功用

Spring Cloud Commons供给了一个/features履行器端点。这个端点回来classpath上可用的特性以及它们是否被启用。回来的信息包含功用类型、称号、版别和供货商。

2.10.1. Feature types

有两种类型的 “特征”：笼统的和命名的。

笼统特征是指界说了一个接口或笼统类的特征，而且创立了一个完成，例如DiscoveryClient、LoadBalancerClient或LockService。笼统类或接口被用来在上下文中找到该类型的Bean。显现的版别是bean.getClass().getPackage().getImplementationVersion()。

命名的特性是指没有它们完成的特定类的特性。这些特性包含 “Circuit Breaker”、”API Gateway”、”Spring Cloud Bus “和其他。这些特性需求一个称号和一个bean类型。

2.10.2. 声明特征

任何模块都能够声明恣意数量的HasFeaturebeans，正如下面的比如所示:

@Bean
public HasFeatures commonsFeatures() {
  return HasFeatures.abstractFeatures(DiscoveryClient.class, LoadBalancerClient.class);
}
@Bean
public HasFeatures consulFeatures() {
  return HasFeatures.namedFeatures(
    new NamedFeature("Spring Cloud Bus", ConsulBusAutoConfiguration.class),
    new NamedFeature("Circuit Breaker", HystrixCommandAspect.class));
}
@Bean
HasFeatures localFeatures() {
  return HasFeatures.builder()
      .abstractFeature(Something.class)
      .namedFeature(new NamedFeature("Some Other Feature", Someother.class))
      .abstractFeature(Somethingelse.class)
      .build();
}

这些beans中的每一个都应该放在一个有适当维护的@Configuration中。

2.11. Spring Cloud兼容性验证

由于一些用户在设置Spring Cloud运用程序时遇到了问题，咱们决议增加一个兼容性验证机制。假如你现在的设置不符合Spring Cloud的要求，它就会中止，并供给一份报告，说明到底是哪里出了问题。

现在，咱们会验证哪个版别的Spring Boot被增加到你的classpath中。

报告的比如:

***************************
APPLICATION FAILED TO START
***************************
Description:
Your project setup is incompatible with our requirements due to following reasons:
- Spring Boot [2.1.0.RELEASE] is not compatible with this Spring Cloud release train
Action:
Consider applying the following actions:
- Change Spring Boot version to one of the following versions [1.2.x, 1.3.x] .
You can find the latest Spring Boot versions here [https://spring.io/projects/spring-boot#learn].
If you want to learn more about the Spring Cloud Release train compatibility, you can visit this page [https://spring.io/projects/spring-cloud#overview] and check the [Release Trains] section.

为了禁用该功用，请将spring.cloud.compatibility-verifier.enabled设置为false。假如你想掩盖兼容的Spring Boot版别，只需将spring.cloud.compatibility-verifier.compatible-boot-versions特点设为逗号分隔的兼容Spring Boot版别列表。

3. Spring Cloud LoadBalancer

Spring Cloud供给了自己的客户端负载均衡器的笼统和完成。关于负载平衡机制，增加了ReactiveLoadBalancer接口，并为其供给了Round-Robin-based和Round的完成。为了从反响式服务实例中取得挑选，咱们运用了ServiceInstanceListSupplier。现在咱们支撑根据服务发现的ServiceInstanceListSupplier的完成，它运用classpath中的发现客户端从服务发现中检索可用的实例。

能够经过将spring.cloud.loadbalancer.enabled的值设置为false来禁用Spring Cloud LoadBalancer。

3.1. 负载平衡算法之间的切换

默许运用的ReactiveLoadBalancer完成是RoundRobinLoadBalancer。要切换到不同的完成，不管是对挑选的服务仍是一切的服务，你都能够运用自界说LoadBalancer装备机制。

例如，能够经过@LoadBalancerClient注解传递以下装备，以切换到运用RandomLoadBalancer:

public class CustomLoadBalancerConfiguration {
    @Bean
    ReactorLoadBalancer<ServiceInstance> randomLoadBalancer(Environment environment,
            LoadBalancerClientFactory loadBalancerClientFactory) {
        String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
        return new RandomLoadBalancer(loadBalancerClientFactory
                .getLazyProvider(name, ServiceInstanceListSupplier.class),
                name);
    }
}

作为@LoadBalancerClient或@LoadBalancerClients装备参数传递的类不该该用@Configuration来注解，或许是在组件扫描规模之外。

3.2. Spring Cloud LoadBalancer的集成

为了便利运用Spring Cloud LoadBalancer，咱们供给了可用于WebClient的ReactorLoadBalancerExchangeFilterFunction和可用于RestTemplate的BlockingLoadBalancerClient。你能够在以下章节看到更多的信息和运用实例:

Spring RestTemplate as a Load Balancer Client
Spring WebClient as a Load Balancer Client
Spring WebFlux WebClient withReactorLoadBalancerExchangeFilterFunction

3.3. Spring Cloud LoadBalancer 缓存

除了每次需求挑选实例时经过DiscoveryClient检索实例的根本ServiceInstanceListSupplier完成之外，咱们还供给了两种缓存完成。

3.3.1. Caffeine-backed LoadBalancer缓存完成

假如你的classpath中有com.github.ben-manes.caffeine:caffeine，将运用根据Caffeine的完成。有关怎么装备的信息，请参阅LoadBalancerCacheConfiguration部分。

假如你运用Caffeine，你也能够经过在spring.cloud.loadbalancer.cache.caffeine.spec特点中传递你自己的Caffeine Specification来掩盖LoadBalancer的默许Caffeine缓存设置。

WARN: 传递您自己的Caffeine标准将掩盖任何其他LoadBalancerCache设置，包含一般LoadBalancer Cache装备字段，如ttl和容量(capacity)。

3.3.2. 默许的LoadBalancer Cache完成

假如你的classpath中没有Caffeine，将运用spring-cloud-starter-loadbalancer主动顺便的DefaultLoadBalancerCache。请参阅LoadBalancerCacheConfiguration部分，了解怎么装备它的信息。

3.3.3. 负载均衡器缓存装备

您能够经过传递符合Spring Boot String到Duration转化语法的String，来设置您自己的ttl值（写入后条目应过期的时刻），以Duration表明。作为pring.cloud.loadbalancer.cache.ttl特点的值。您还能够经过设置spring.cloud.loadbalancer.cache.capacity特点的值来设置您自己的LoadBalancer缓存初始容量。

默许设置包含ttl设置为35秒，默许初始容量(initialCapacity)为256。

你也能够经过将spring.cloud.loadbalancer.cache.enabled的值设置为false来彻底禁用loadBalancer缓存。

虽然根本的、非缓存的完成关于原型规划和测试很有用，但它的功率远低于缓存版别，因而咱们主张在生产中始终运用缓存版别。假如缓存现已由DiscoveryClient完成完结，例如EurekaDiscoveryClient，则应禁用负载平衡器缓存以防止双重缓存。

3.4. 根据区域的负载平衡

为了完成根据区域的负载平衡，咱们供给ZonePreferenceServiceInstanceListSupplier。咱们运用DiscoveryClient特定的区域装备（例如，eureka.instance.metadata-map.zone）来挑选客户端企图过滤可用服务实例的区域。

你也能够经过设置spring.cloud.loadbalancer.zone特点的值来重写DiscoveryClient特定的区域设置。

现在，只需Eureka发现客户端被用来设置LoadBalancer区域。关于其他发现客户端，设置spring.cloud.loadbalancer.zone特点。更多的东西很快就会呈现。

为了确定一个被检索的服务实例的区域，咱们查看metadata map中 “zone “键下的值。

ZonePreferenceServiceInstanceListSupplier过滤检索到的实例，只回来同一区域内的实例。假如区域是空的或在同一区域内没有实例，它将回来一切检索到的实例。

为了运用根据分区的负载平衡办法，你有必要在custom configuration中实例化一个ZonePreferenceServiceInstanceListSupplierBean。

咱们运用托付来处理ServiceInstanceListSupplierBean。咱们主张在ZonePreferenceServiceInstanceListSupplier的结构函数中传递一个DiscoveryClientServiceInstanceListSupplier托付，并反过来用CachingServiceInstanceListSupplier包装后者，以运用LoadBalancer缓存机制(LoadBalancer caching mechanism)。

你能够运用这个样本装备来设置它:

public class CustomLoadBalancerConfiguration {
    @Bean
    public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
            ConfigurableApplicationContext context) {
        return ServiceInstanceListSupplier.builder()
                    .withDiscoveryClient()
                    .withZonePreference()
                    .withCaching()
                    .build(context);
    }
}

3.5. 负载平衡器的实例健康查看

咱们能够为LoadBalancer启用预定的健康查看。HealthCheckServiceInstanceListSupplier便是为此供给的。它定期查看由托付的ServiceInstanceListSupplier供给的实例是否仍然活着，而且只回来健康的实例，除非没有–那么它将回来一切检索到的实例。

这个机制在运用SimpleDiscoveryClient时特别有用。关于由实践的服务注册中心支撑的客户端，没有必要运用，由于咱们在查询外部ServiceDiscovery后现已得到了健康的实例。也便是说咱们假如用的其他替他供给的自界说客户端，里面现已做处理了。

这个supplier也被引荐用于每个服务有少数实例的设置，以避免在失利的实例上重试调用。

假如运用任何由服务发现支撑的供货商，通常不需求增加这种健康查看机制，由于咱们直接从服务注册中心检索实例的健康状况。

HealthCheckServiceInstanceListSupplier依靠于具有由delegate flux供给的更新实例。在极少数状况下，当你想运用一个即使实例列表(远端)发生改动也没改写实例(本地)的托付（如咱们供给的DiscoveryClientServiceInstanceListSupplier）时，你能够将spring.cloud.loadbalancer.health-check.refetch-instances设置为true，让HealthCheckServiceInstanceListSupplier改写实例列表。然后，您还能够经过修正HealthCheckServiceInstanceListSupplier的值来调整改写距离，并挑选经过将spring.cloud.loadbalancer.health-check.repeat-health-check设置为false来禁用额定的健康查看重复，由于每次实例改写也将触发一次健康查看。

假如你依靠默许路径（/actuator/health），请保证将spring-boot-starter-actuator增加到你的合作者的依靠项中，除非你打算自己增加这样一个端点。

为了运用健康查看调度器办法，你有必要在custom configuration中实例化一个HealthCheckServiceInstanceListSupplierBean。

咱们运用托付来处理ServiceInstanceListSupplierBean。咱们主张在HealthCheckServiceInstanceListSupplier的结构函数中传递一个DiscoveryClientServiceInstanceListSupplier托付。

你能够运用这个示例装备来设置它:

public class CustomLoadBalancerConfiguration {
    @Bean
    public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
            ConfigurableApplicationContext context) {
        return ServiceInstanceListSupplier.builder()
                    .withDiscoveryClient()
                    .withHealthChecks()
                    .build(context);
        }
    }

关于非反响堆栈，用withBlockingHealthChecks()创立这个供货商。你也能够传递你自己的WebClient或RestTemplate实例来用于查看。

HealthCheckServiceInstanceListSupplier有自己的根据Reactor Flux replay()的缓存机制。因而，假如正在运用它，你或许想越过能够用CachingServiceInstanceListSupplier来包装该供货商。

3.6. LoadBalancer的相同实例偏好

你能够将LoadBalancer设置成这样一种办法，即假如之前挑选的实例可用，它就会优先挑选该实例。

为此，您需求运用SameInstancePreferenceServiceInstanceListSupplier。你能够经过将spring.cloud.loadbalancer.configurations的值设置为same-instance-preference或供给你自己的ServiceInstanceListSupplierBean 来装备它 – 例如:

public class CustomLoadBalancerConfiguration {
    @Bean
    public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
            ConfigurableApplicationContext context) {
        return ServiceInstanceListSupplier.builder()
                    .withDiscoveryClient()
                    .withSameInstancePreference()
                    .build(context);
        }
    }

这也是ZookeeperStickyRule的代替品。

3.7. 根据恳求的LoadBalancer粘性会话

你能够将LoadBalancer设置成这样一种办法，即它更倾向于运用恳求cookie中供给的instanceId的实例。假如恳求是经过ClientRequestContext或ServerHttpRequestContext传递给LoadBalancer的，咱们现在支撑这种办法，SC LoadBalancer交换过滤功用和过滤器。

为此，你需求运用RequestBasedStickySessionServiceInstanceListSupplier。你能够经过将spring.cloud.loadbalancer.configurations的值设置为request-based-sticky-session或供给你自己的ServiceInstanceListSupplierBean 来装备它 – 例如:

public class CustomLoadBalancerConfiguration {
    @Bean
    public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
            ConfigurableApplicationContext context) {
        return ServiceInstanceListSupplier.builder()
                    .withDiscoveryClient()
                    .withRequestBasedStickySession()
                    .build(context);
        }
    }

为了完成这一功用，在向前发送恳求之前，更新所选的服务实例（假如该实例不可用，它能够与原始恳求 cookie 中的实例不同）对错常有用的。要做到这一点，请将spring.cloud.loadbalancer.sticky-session.add-service-instance-cookie的值设置为true。

默许状况下，cookie的称号是sc-lb-instance-id。你能够经过改动spring.cloud.loadbalancer.instance-id-cookie-name特点的值来修正它。

该功用现在支撑由WebClient支撑的负载平衡。

3.8. Spring Cloud LoadBalancer提示

Spring Cloud LoadBalancer让你设置字符串提示，这些提示在Request目标中传递给LoadBalancer，今后能够在ReactiveLoadBalancer完成中运用，这些完成能够处理它们。

您能够经过设置spring.cloud.loadbalancer.hint.default特点的值为一切服务设置一个默许提示。您还能够经过设置spring.cloud.loadbalancer.hint.[SERVICE_ID]特点的值为任何给定的服务设置一个特定的值，用您的服务的正确ID 代替 [SERVICE_ID]。假如用户没有设置提示，则运用默许值。

3.9. 根据Hint的负载平衡

咱们还供给了一个HintBasedServiceInstanceListSupplier，它是一个ServiceInstanceListSupplier完成，用于根据提示的实例挑选。

HintBasedServiceInstanceListSupplier查看提示恳求头（默许头名是X-SC-LB-Hint，但你能够经过改动spring.cloud.loadbalancer.hint-header-name特点的值来修正它），假如它找到一个提示恳求头，则运用头中传递的提示值来过滤服务实例。

假如没有增加提示头，HintBasedServiceInstanceListSupplier运用来自特点的提示值来过滤服务实例。

假如没有设置提示，不管是经过头仍是经过特点，都会回来由托付人供给的一切服务实例。

在过滤时，HintBasedServiceInstanceListSupplier会寻觅在其metadataMap中的提示键下设置有匹配值的服务实例。假如没有找到匹配的实例，就会回来该托付人供给的一切实例。

public class CustomLoadBalancerConfiguration {
    @Bean
    public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
            ConfigurableApplicationContext context) {
        return ServiceInstanceListSupplier.builder()
                    .withDiscoveryClient()
                    .withHints()
                    .withCaching()
                    .build(context);
    }
}

3.10. 转化负载平衡的HTTP恳求

你能够运用选定的ServiceInstance来转化负载平衡的HTTP恳求。

关于RestTemplate，你需求完成并界说LoadBalancerRequestTransformer，如下所示。

@Bean
public LoadBalancerRequestTransformer transformer() {
    return new LoadBalancerRequestTransformer() {
        @Override
        public HttpRequest transformRequest(HttpRequest request, ServiceInstance instance) {
            return new HttpRequestWrapper(request) {
                @Override
                public HttpHeaders getHeaders() {
                    HttpHeaders headers = new HttpHeaders();
                    headers.putAll(super.getHeaders());
                    headers.add("X-InstanceId", instance.getInstanceId());
                    return headers;
                }
            };
        }
    };
}

关于WebClient，你需求完成和界说LoadBalancerClientRequestTransformer，如下所示。

@Bean
public LoadBalancerClientRequestTransformer transformer() {
    return new LoadBalancerClientRequestTransformer() {
        @Override
        public ClientRequest transformRequest(ClientRequest request, ServiceInstance instance) {
            return ClientRequest.from(request)
                    .header("X-InstanceId", instance.getInstanceId())
                    .build();
        }
    };
}

假如界说了多个转化器，它们将依照界说Bean的次序来运用。别的，你能够运用LoadBalancerRequestTransformer.DEFAULT_ORDER或LoadBalancerClientRequestTransformer.DEFAULT_ORDER来指定次序。

3.11. Spring Cloud LoadBalancer Starter

咱们还供给了一个发动器，答应你在Spring Boot运用中轻松增加Spring Cloud LoadBalancer。为了运用它，只需在构建文件中将org.springframework.cloud:spring-cloud-starter-loadbalancer增加到你的Spring Cloud依靠项中。

Spring Cloud LoadBalancer starter includesSpring Boot CachingandEvictor.

3.12. 传递你自己的Spring Cloud LoadBalancer装备

你也能够运用@LoadBalancerClient注解来传递你自己的负载均衡器客户端装备，传递负载均衡器客户端的称号和装备类，如下所示:

@Configuration
@LoadBalancerClient(value = "stores", configuration = CustomLoadBalancerConfiguration.class)
public class MyConfiguration {
    @Bean
    @LoadBalanced
    public WebClient.Builder loadBalancedWebClientBuilder() {
        return WebClient.builder();
    }
}

为了使你自己的LoadBalancer装备工作愈加容易，咱们在ServiceInstanceListSupplier类中增加了一个builder()办法。

您还能够运用咱们的代替预界说装备来代替默许装备，办法是将spring.cloud.loadbalancer.configuration特点的值设置为zone-preference，以运用带缓存的ZonePreferenceServiceInstanceListSupplier，或设置为health-check，以运用带缓存的HealthCheckServiceInstanceListSupplier。

你能够运用这个功用来实例化ServiceInstanceListSupplier或ReactorLoadBalancer的不同完成，能够由你来写，也能够由咱们供给代替计划（例如ZonePreferenceServiceInstanceListSupplier）来掩盖默许设置。

你能够在这里看到一个自界说装备的比如。

注释值参数（上面比如中的商铺）指定了咱们应该用给定的自界说装备发送恳求的服务的服务ID。

你也能够经过@LoadBalancerClients注解传递多个装备（用于多个负载均衡器客户端），如下例所示。

@Configuration
@LoadBalancerClients({@LoadBalancerClient(value = "stores", configuration = StoresLoadBalancerClientConfiguration.class), @LoadBalancerClient(value = "customers", configuration = CustomersLoadBalancerClientConfiguration.class)})
public class MyConfiguration {
    @Bean
    @LoadBalanced
    public WebClient.Builder loadBalancedWebClientBuilder() {
        return WebClient.builder();
    }
}

你作为@LoadBalancerClient或@LoadBalancerClients装备参数传递的类不该该用@Configuration来注解，或许是在组件扫描规模之外。

3.13. Spring Cloud LoadBalancer 生命周期

运用Custom LoadBalancer configuration注册的一种Bean类型或许是LoadBalancerLifecycle。

LoadBalancerLifecycleBean供给了回调办法，名为onStart(Request<RC> request)、onStartRequest(Request<RC> request, Response<T> lbResponse)和onComplete(CompletionContext<RES, T, RC> completionContext)，你应该完成这些办法来指定在负载均衡之前和之后应该采取什么行动。

onStart(Request<RC> request)接收一个Request目标作为参数。它包含用于挑选适当实例的数据，包含下流客户端的恳求和提示。onStartRequest也承受Request目标，此外，还承受Response目标作为参数。另一方面，completionContext目标被供给给onComplete(completionContext<RES, T, RC> completionContext)办法。它包含了LoadBalancer的呼应，包含选定的服务实例、针对该服务实例履行的恳求的状况和（假如有）回来给下流客户端的呼应，以及（假如发生了反常）相应的Throwable。

supports(Class requestContextClass, Class responseClass, Class serverTypeClass)办法能够用来确定有关的处理器是否处理所供给类型的目标。假如没有被用户重写，它将回来true。

在前面的办法调用中，RC表明RequestContext类型，RES表明客户端呼应类型，而T表明回来的服务器类型。

3.14. Spring Cloud LoadBalancer计算

咱们供给了一个名为MicrometerStatsLoadBalancerLifecycle的LoadBalancerLifecycleBean，它运用Micrometer来为负载均衡调用供给计算数据。

为了让这个Bean增加到你的运用上下文中，请将spring.cloud.loadbalancer.stats.micrometer.enabled的值设置为true，并有一个MeterRegistry可用（例如，经过增加Spring Boot Actuator到你的项目）。

MicrometerStatsLoadBalancerLifecycle在MeterRegistry中注册了以下外表:

loadbalancer.requests.active: 一个答应你监控每一个服务实例的当时活动恳求数的外表（服务实例数据可经过标签取得）。
loadbalancer.requests.success: 一个计时器，用于丈量每一个负载均衡恳求的履行时刻，这些恳求最终将呼应传递给了底层客户端
loadbalancer.requests.failed: 衡量任何以反常完毕的负载均衡恳求的履行时刻的计时器。
loadbalancer.requests.discard:衡量被丢掉的负载均衡恳求数量的计数器，即负载均衡器没有检索到运行该恳求的服务实例的恳求。

关于服务实例、恳求数据和呼应数据的额定信息在任何时候都会经过标签增加到衡量中。

关于一些完成，如BlockingLoadBalancerClient，恳求和呼应数据或许不可用，由于咱们从参数中建立了通用类型，或许无法确定类型和读取数据。

当至少有一条记载被增加到某一外表上时，该外表才被登记在注册表上。

你能够经过增加MeterFilters进一步装备这些目标的行为（例如，增加发布百分比和柱状图）。

3.15. 装备单个LoadBalancerClients

单个负载均衡器客户端能够用不同的前缀spring.cloud.loadbalancer.clients.<clientId>进行单独装备，其间 clientId 是负载均衡器的称号。默许装备值能够在spring.cloud.loadbalancer. namespace中设置，并将与客户机特定值优先兼并。

Example 5. application.yml

spring:
  cloud:
    loadbalancer:
      health-check:
        initial-delay: 1s
      clients:
        myclient:
          health-check:
            interval: 30s
YAML 仿制 全屏

上述比如将发生一个兼并的健康查看@ConfigurationProperties目标，初始延迟=1s，距离=30s。

除了以下大局特点外，每个客户的装备特点对大部分特点都有效:

spring.cloud.loadbalancer.enabled– 大局启用或禁用负载平衡
spring.cloud.loadbalancer.retry.enabled– 大局启用或禁用负载均衡重试。假如你在大局规模内启用它，你仍然能够运用客户端前缀特点禁用特定客户端的重试，但不能反过来。
spring.cloud.loadbalancer.cache.enabled– 大局启用或禁用LoadBalancer的缓存。假如你大局启用它，你仍然能够经过创立一个自界说装备，在ServiceInstanceListSupplier托付层次结构中不包含CachingServiceInstanceListSupplier来禁用特定客户端的缓存，但反过来就不可了。
spring.cloud.loadbalancer.stats.micrometer.enabled– 大局启用或禁用LoadBalancer Micrometer目标

关于现已运用地图的特点，你能够在不运用client关键字的状况下为每个客户指定不同的值（例如，hints，health-check.path），咱们保留了这种行为，以便坚持库的向后兼容。它将鄙人一个主要版别中被修正。

Spring Cloud Commons文档翻译(非转译)