|
此版本仍在开发中，目前尚不被视为稳定版本。如需最新稳定版本，请使用 Spring Cloud Commons 5.0.1！ |
Spring Cloud LoadBalancer
Spring Cloud 提供了其自身的客户端负载均衡抽象及实现。对于负载均衡机制，已添加 ReactiveLoadBalancer 接口，并提供了基于 轮询（Round-Robin） 和 随机（Random） 的两种实现。为了从响应式环境中获取可选择的实例，使用了 ServiceInstanceListSupplier。目前，我们支持一种基于服务发现的 ServiceInstanceListSupplier 实现，该实现通过类路径中可用的 发现客户端（Discovery Client） 从服务发现中检索可用实例。
可以通过将 false 的值设置为 spring.cloud.loadbalancer.enabled 来禁用 Spring Cloud LoadBalancer。 |
即时加载负载均衡器上下文
Spring Cloud LoadBalancer 为每个服务 ID 创建一个独立的 Spring 子上下文。默认情况下，这些上下文在首次对某个服务 ID 进行负载均衡时才会被延迟初始化。
您可以选择提前加载这些上下文。为此，请使用 spring.cloud.loadbalancer.eager-load.clients 属性指定您希望进行提前加载的服务 ID，例如：
spring.cloud-loadbalancer.eager-load.clients[0]=my-first-client
spring.cloud-loadbalancer.eager-load.clients[1]=my-second-client在负载均衡算法之间进行切换
默认使用的 ReactiveLoadBalancer 实现是 RoundRobinLoadBalancer。若要切换到其他实现（针对特定服务或全部服务），您可以使用 自定义负载均衡器配置机制。
例如，以下配置可以通过 @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，要么应位于组件扫描范围之外。 |
Spring Cloud LoadBalancer 集成
为了便于使用 Spring Cloud LoadBalancer，我们提供了 ReactorLoadBalancerExchangeFilterFunction（可与 WebClient 一起使用）以及 BlockingLoadBalancerClient（可与 RestTemplate 和 RestClient 配合使用）。
Spring Cloud LoadBalancer 缓存
除了基本的 ServiceInstanceListSupplier 实现（该实现每次选择实例时都通过 DiscoveryClient 获取实例外），我们还提供了两种缓存实现。
Caffeine后端负载均衡器缓存实现
如果您在类路径中包含 com.github.ben-manes.caffeine:caffeine，将使用基于 Caffeine 的实现。有关如何配置它的信息，请参阅 LoadBalancerCacheConfiguration 部分。
如果您正在使用 Caffeine，还可以通过在 spring.cloud.loadbalancer.cache.caffeine.spec 属性中传递您自己的 Caffeine 配置说明 来重写 LoadBalancer 的默认 Caffeine 缓存设置。
警告：传递您自己的 Caffeine 规范将覆盖任何其他 LoadBalancerCache 设置，包括 通用负载均衡器缓存配置 字段，例如 ttl 和 capacity。
默认负载均衡器缓存实现
如果您在类路径中没有 Caffeine，将自动使用与 spring-cloud-starter-loadbalancer 一起提供的 DefaultLoadBalancerCache。有关如何配置它的信息，请参阅 LoadBalancerCacheConfiguration 部分。
要使用 Caffeine 而非默认缓存，请将 com.github.ben-manes.caffeine:caffeine 依赖添加到类路径中。 |
负载均衡器缓存配置
您可以设置自己的 ttl 值（即写入后多久条目应过期的时间），以 Duration 的格式表示，方法是传入一个符合 Spring Boot String 到 Duration 转换器语法 的 String。
作为 spring.cloud.loadbalancer.cache.ttl 属性的值。
您还可以通过设置 spring.cloud.loadbalancer.cache.capacity 属性的值来设置负载均衡器缓存的初始容量。
默认设置包括 ttl 设为 35 秒，而默认的 initialCapacity 是 256。
您还可以通过将 spring.cloud.loadbalancer.cache.enabled 的值设置为 false 来完全禁用负载均衡器缓存。
虽然基本的、未缓存的实现对于原型设计和测试很有用，但其效率远低于缓存版本，因此我们建议在生产环境中始终使用缓存版本。例如，如果缓存已由 DiscoveryClient 实现（如 EurekaDiscoveryClient）完成，则应禁用负载均衡器的缓存，以避免重复缓存。 |
当您创建自己的配置时，如果使用 CachingServiceInstanceListSupplier，请确保将其放置在直接位于从网络获取实例的提供者之后的层级中，例如 DiscoveryClientServiceInstanceListSupplier，且在任何其他过滤提供者之前。 |
加权负载均衡
为启用加权负载均衡，我们提供了 WeightedServiceInstanceListSupplier。我们使用 WeightFunction 来计算每个实例的权重。默认情况下，我们会尝试从元数据映射中读取并解析权重（键为 weight）。
如果元数据映射中未指定权重，则我们将此实例的权重默认设置为1。
您可以选择以下任一方式对其进行配置：将 spring.cloud.loadbalancer.configurations 的值设置为 weighted，或提供您自己的 ServiceInstanceListSupplier Bean，例如：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withWeighted()
.withCaching()
.build(context);
}
}您还可以通过提供 WeightFunction 来自定义权重计算逻辑。 |
您可以使用此示例配置使所有实例具有随机权重：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withWeighted(instance -> ThreadLocalRandom.current().nextInt(1, 101))
.withCaching()
.build(context);
}
}基于区域的负载均衡
为启用基于区域的负载均衡，我们提供了 ZonePreferenceServiceInstanceListSupplier。我们使用 DiscoveryClient 特定的 zone 配置（例如，eureka.instance.metadata-map.zone）来选择客户端尝试筛选可用服务实例所在的区域。
您还可以通过设置 spring.cloud.loadbalancer.zone 属性的值来覆盖 DiscoveryClient 特定区域的配置。 |
目前，仅 Eureka 发现客户端被配置为设置负载均衡器区域。对于其他发现客户端，请设置 spring.cloud.loadbalancer.zone 属性。更多集成功能即将推出。 |
要确定检索到的 ServiceInstance 所属的区域，我们检查其元数据映射中 "zone" 键对应的值。 |
获取的 ZonePreferenceServiceInstanceListSupplier 过滤器会筛选实例，仅返回位于同一可用区内的实例。如果可用区为 null 或同一可用区内没有实例，则返回所有获取到的实例。
为了使用基于区域的负载均衡方法，您必须在自定义配置中实例化一个ZonePreferenceServiceInstanceListSupplierbean。
我们使用委托来处理 ServiceInstanceListSupplier 个 Bean。我们建议使用一个 DiscoveryClientServiceInstanceListSupplier 委托，将其包装在 CachingServiceInstanceListSupplier 中以利用 负载均衡器缓存机制，然后将生成的 Bean 作为参数传递给 ZonePreferenceServiceInstanceListSupplier 的构造函数。
您可以使用此示例配置来设置它：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withCaching()
.withZonePreference()
.build(context);
}
}负载均衡器实例健康检查
可以为负载均衡器启用定时健康检查。其中 HealthCheckServiceInstanceListSupplier 用于此目的。它会定期验证由委托方 ServiceInstanceListSupplier 提供的实例是否仍然存活，并仅返回健康的实例，除非没有健康实例——此时将返回所有检索到的实例。
此机制在使用 SimpleDiscoveryClient 时特别有用。对于由实际服务注册中心支持的客户端，无需使用它，因为我们查询外部服务发现后已获得健康实例。 |
| 此提供商也推荐用于每个服务实例数量较少的配置，以避免在故障实例上重试调用。 |
| 如果使用任何基于服务发现的提供商，通常无需添加此健康检查机制，因为我们可直接从服务注册中心获取实例的健康状态。 |
该 HealthCheckServiceInstanceListSupplier 依赖于由委托流（delegate flux）提供的更新实例。在极少数情况下，如果您希望使用一个不刷新实例的委托（即使实例列表可能发生变化，例如我们提供的 DiscoveryClientServiceInstanceListSupplier），您可以将 spring.cloud.loadbalancer.health-check.refetch-instances 设置为 true，从而使实例列表由 HealthCheckServiceInstanceListSupplier 进行刷新。您还可以通过修改 spring.cloud.loadbalancer.health-check.refetch-instances-interval 的值来调整重新获取（refetch）间隔，并通过将 spring.cloud.loadbalancer.health-check.repeat-health-check 设置为 false 来禁用额外的健康检查重复执行——因为每次实例重新获取都会触发一次健康检查。 |
HealthCheckServiceInstanceListSupplier 使用以 spring.cloud.loadbalancer.health-check 开头的属性。您可以为调度器设置 initialDelay 和 interval。您可以通过设置 spring.cloud.loadbalancer.health-check.path.default 属性的值来指定健康检查 URL 的默认路径。您还可以通过设置 spring.cloud.loadbalancer.health-check.path.[SERVICE_ID] 属性的值，为任意特定服务设置一个具体值，其中将 [SERVICE_ID] 替换为您服务的正确 ID。如果未指定 [SERVICE_ID]，则默认使用 /actuator/health。如果 [SERVICE_ID] 被设置为 null 或为空，则不会执行健康检查。您还可以通过设置 spring.cloud.loadbalancer.health-check.port 属性的值来自定义健康检查请求的端口；若未设置，则使用服务实例所处的端口。
如果您依赖默认路径（/actuator/health），请确保将 spring-boot-starter-actuator 添加到您合作者的依赖项中，除非您计划自行添加此类端点。 |
默认情况下，healthCheckFlux 会在每次获取到的每个存活的 ServiceInstance 上发出。您可以通过将 spring.cloud.loadbalancer.health-check.update-results-list 的值设置为 false 来修改此行为。如果此属性被设置为 false，则会首先将所有存活实例序列收集到一个列表中，然后才进行发出，从而确保流在设定的健康检查间隔期间不会发出中间值。 |
为了使用健康检查调度器方法，您必须在自定义配置中实例化一个HealthCheckServiceInstanceListSupplierbean。
我们使用委托来处理 ServiceInstanceListSupplier 个 Bean。我们建议在 HealthCheckServiceInstanceListSupplier 的构造函数中传入一个 DiscoveryClientServiceInstanceListSupplier 委托。
您可以使用此示例配置来设置它：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withHealthChecks()
.build(context);
}
}对于非响应式堆栈，请使用 withBlockingHealthChecks() 创建此提供商。您也可以传入自己的 WebClient、RestTemplate 或 RestClient 实例，用于执行检查。 |
HealthCheckServiceInstanceListSupplier 具有基于 Reactor Flux replay() 的自身缓存机制。因此，如果正在使用它，您可能希望跳过用 CachingServiceInstanceListSupplier 包装该提供商。 |
当您创建自己的配置时，HealthCheckServiceInstanceListSupplier，请确保将其放置在直接位于从网络检索实例的提供商之后的层级中，例如，DiscoveryClientServiceInstanceListSupplier，并在任何其他过滤提供商之前。 |
LoadBalancer 的相同实例偏好
您可以以某种方式配置负载均衡器，使其在先前选择的实例可用时优先选择该实例。
为此，您需要使用 SameInstancePreferenceServiceInstanceListSupplier。您可以通过将 spring.cloud.loadbalancer.configurations 的值设置为 same-instance-preference 来配置它，也可以提供您自己的 ServiceInstanceListSupplier Bean —— 例如：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withSameInstancePreference()
.build(context);
}
}这也是 Zookeeper StickyRule 的替代方案。 |
基于请求的粘性会话（Sticky Session）负载均衡器
您可以配置负载均衡器，使其优先选择在请求 Cookie 中提供 instanceId 值的实例。目前，如果请求是通过 ClientRequestContext 或 ServerHttpRequestContext 传递到负载均衡器的，则我们支持此功能，其中 ClientRequestContext 和 ServerHttpRequestContext 分别由 SC 负载均衡器交换过滤器函数和过滤器使用。
为此，您需要使用 RequestBasedStickySessionServiceInstanceListSupplier。您可以通过将 spring.cloud.loadbalancer.configurations 的值设置为 request-based-sticky-session 来配置它，或者提供您自己的 ServiceInstanceListSupplier Bean —— 例如：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withRequestBasedStickySession()
.build(context);
}
}为此功能，最好在将请求转发之前更新所选的服务实例（该实例可能与原始请求 Cookie 中的实例不同，如果该 Cookie 不可用的话）。要做到这一点，请将 spring.cloud.loadbalancer.sticky-session.add-service-instance-cookie 的值设置为 true。
默认情况下，Cookie 的名称为 sc-lb-instance-id。您可以通过修改 spring.cloud.loadbalancer.instance-id-cookie-name 属性的值来更改它。
| 此功能当前仅支持基于 WebClient 的负载均衡。 |
Spring Cloud LoadBalancer 提示
Spring Cloud LoadBalancer 允许您设置 String 个提示，这些提示会传递给负载均衡器（LoadBalancer）内的 Request 对象，并且之后可在支持它们的 ReactiveLoadBalancer 实现中使用。
您可以设置一个默认提示，用于所有服务，方法是设置 spring.cloud.loadbalancer.hint.default 属性的值。您也可以为任意特定服务设置一个具体值，方法是设置 spring.cloud.loadbalancer.hint.[SERVICE_ID] 属性的值，并将 [SERVICE_ID] 替换为您的服务的正确 ID。如果用户未设置提示，则使用 default。
基于提示的负载均衡
我们还提供了一个 HintBasedServiceInstanceListSupplier，它是一种基于提示的实例选择的 ServiceInstanceListSupplier 实现。
HintBasedServiceInstanceListSupplier 检查提示请求头（默认的头名称是 X-SC-LB-Hint，但您可以通过修改 spring.cloud.loadbalancer.hint-header-name 属性的值来更改它），如果找到提示请求头，则使用该头中传入的提示值来筛选服务实例。
如果没有添加提示头，则 HintBasedServiceInstanceListSupplier 会使用 属性中的提示值 来筛选服务实例。
如果未设置提示（无论是通过请求头还是属性），将返回委托提供的所有服务实例。
在过滤过程中，HintBasedServiceInstanceListSupplier 查找其 metadataMap 中的 hint 键下设置有匹配值的服务实例。如果没有找到匹配的实例，则返回委托方提供的所有实例。
您可以使用以下示例配置来设置它：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withCaching()
.withHints()
.build(context);
}
}转换负载均衡的HTTP请求
您可以使用选定的 ServiceInstance 来转换负载均衡的 HTTP 请求。
对于 RestTemplate 和 RestClient，您需要按如下方式实现并定义 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 来指定顺序。
Spring Cloud LoadBalancer 子集
SubsetServiceInstanceListSupplier 实现了一个 确定性子集选择算法，用于在 ServiceInstanceListSupplier 委托类层次结构中选择有限数量的实例。
您可以通过将 spring.cloud.loadbalancer.configurations 的值设置为 subset，或提供您自己的 ServiceInstanceListSupplier Bean 来对其进行配置——例如：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withSubset()
.withCaching()
.build(context);
}
}默认情况下，每个服务实例都会分配一个唯一的instanceId，不同的instanceId值 often 会选择不同的子集。通常你无需关注它。但是，如果你需要多个实例选择同一个子集，可以将其设置为spring.cloud.loadbalancer.subset.instance-id（支持占位符）。 |
默认情况下，子集的大小设置为100。也可以使用spring.cloud.loadbalancer.subset.size设置它。 |
Spring Cloud Loadbalancer Starters
我们还提供一个启动程序，它允许您轻松地在Spring Boot应用程序中添加Spring Cloud LoadBalancer。 要使用它，请在构建文件中为Spring Cloud依赖项添加org.springframework.cloud:spring-cloud-starter-loadbalancer。
| Spring Cloud LoadBalancer Starters包含 Spring Boot 缓存 和 清除程序。 |
传递您自己的Spring Cloud LoadBalancer配置
您还可以使用@LoadBalancerClient注释来传递您自己的负载均衡器客户端配置，传递负载均衡器客户端的名称和配置类，如下所示：
@Configuration
@LoadBalancerClient(value = "stores", configuration = CustomLoadBalancerConfiguration.class)
public class MyConfiguration {
@Bean
@LoadBalanced
public WebClient.Builder loadBalancedWebClientBuilder() {
return WebClient.builder();
}
}为了使您自己在builder()类上进行LoadBalancer配置的工作变得更加容易，我们向该类添加了一个ServiceInstanceListSupplier方法。 |
你也可以通过设置spring.cloud.loadbalancer.configurations属性的值为zone-preference来使用预定义配置，或者设置为ZonePreferenceServiceInstanceListSupplier来使用带缓存的health-check配置，或者设置为HealthCheckServiceInstanceListSupplier来使用带缓存的5配置。本页包含所有可用的预定义 bean 配置及其属性。这些预定义配置可以作为定制点使用，或者直接在项目中使用，如果您更喜欢使用而不是自定义您的 own beans。 |
您可以使用此功能来实例化不同实现的ServiceInstanceListSupplier或ReactorLoadBalancer，由您自己提供，或者我们作为替代方案（例如ZonePreferenceServiceInstanceListSupplier）来覆盖默认设置。
你可以查看一个自定义配置的示例 在这里。
注释 value 参数（如上例中的 1 ），指定要使用给定自定义配置发送请求的服务 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，要么应位于组件扫描范围之外。 |
当您创建自己的配置时，如果使用CachingServiceInstanceListSupplier或HealthCheckServiceInstanceListSupplier，请确保使用其中一个，而不是同时使用两个，并且必须在层次结构中直接位于通过网络检索实例的提供商之后，例如DiscoveryClientServiceInstanceListSupplier，在此之前应放置任何其他筛选提供程序。 |
Spring Cloud LoadBalancer 生命周期
一种可能在使用 Custom LoadBalancer configuration 时有用到注册的 bean 是 LoadBalancerLifecycle。
这些0个beans提供了回调方法，名为1、2和3，您需要实现这些方法以指定在负载均衡前后应采取什么操作。
onStart(Request<RC> request) 接收一个Request对象作为参数。它包含用于选择适当实例的数据，包括下游客户端请求和提示。onStartRequest也接收Request对象，并且另外还接收Response<T>对象。另一方面，提供了一个CompletionContext对象到onComplete(CompletionContext<RES, T, RC> completionContext)方法。它包含LoadBalancerResponse，包括针对该服务实例执行的选定服务实例、对Status的请求和（如果可用）返回给下游客户端的响应，以及（如果出现异常）相应的Throwable。对象。
The supports(Class requestContextClass, Class responseClass,
Class serverTypeClass) method can be used to determine whether the processor in question handles objects of provided types. If not overridden by the user, it returns true.
在前面的方法调用中，RC表示RequestContext类型，RES表示客户端响应类型，以及T表示返回的服务器类型。 |
Spring Cloud Loadbalancer 统计信息
我们提供一个名为MicrometerStatsLoadBalancerLifecycle的LoadBalancerLifecycle bean，它使用Micrometer为负载平衡调用提供统计信息。
要将此 bean 添加到应用程序上下文，请将值设置为 1，并使该值可用（例如，通过向项目添加Spring Boot Actuator）。
MicrometerStatsLoadBalancerLifecycle 注册了以下电表在 MeterRegistry 中：
-
loadbalancer.requests.active: 一个仪表，可让您监控任何服务实例(通过标签提供服务实例数据)的当前活动请求数; -
loadbalancer.requests.success: 一个计时器，测量任何已传递响应给底层客户的负载平衡请求的执行时间; -
loadbalancer.requests.failed: 一个计时器，用于测量任何通过负载均衡处理并最终抛出异常的请求的执行时间； -
loadbalancer.requests.discard: 一个计数器，用于测量丢弃的负载平衡请求的数量，即那些由 LoadBalancer 检索出服务实例来执行请求但没有检索出服务实例的情况。
额外的关于服务实例、请求数据和响应数据的信息会尽可能添加到指标的标签中。
对于使用 WebClient 和 RestClient 支持的负载均衡，我们会在 uri 标签可用时使用 uriTemplate。 |
可能通过将 spring.cloud.loadbalancer.stats.include-path 设置为 false 来禁用在 uri 标签中添加 path。 |
与RestTemplate-based负载平衡一样，我们无法访问uriTemplate。始终在uri标记中使用完整路径。为了防止出现基数过高的问题，如果路径是一个高基数值（例如/orders/{id}，其中id采用大量值），强烈建议通过将spring.cloud.loadbalancer.stats.include-path设置为false来禁用将路径添加到uri标记。 |
对于某些实现，例如 BlockingLoadBalancerClient，请求和响应数据可能不可用，因为我们从参数中建立泛型类型，可能无法确定类型并读取数据。 |
| 摘要报表根据选定的时间间隔计算每个摘要报表类型中包含的度量值。这些摘要报表是在后台生成的，因此报告可能需要几秒钟才能显示。 |
您还可以通过添加MeterFilters进一步配置这些指标的行为（例如，添加发布百分位数和直方图）。 |
配置单个 LoadBalancer 客户端
单个Loadbalancer客户端可以单独配置不同的前缀spring.cloud.loadbalancer.clients.<clientId>.其中clientId是负载均衡器的名称。默认配置值可以在spring.cloud.loadbalancer.命名空间中设置，并将与特定于客户端的值合并，后者优先级更高
spring:
cloud:
loadbalancer:
health-check:
initial-delay: 1s
clients:
myclient:
health-check:
interval: 30s
上述示例将结果为一个合并后的健康检查 @ConfigurationProperties 对象，包含 initial-delay=1s 和 interval=30s。
The per-client configuration properties work for most of the properties, apart from the following global ones:
-
spring.cloud.loadbalancer.enabled- 全局启用或禁用负载平衡 -
0- 全局启用或禁用负载平衡重试。如果在全局上启用它，您可以使用1前缀属性来禁用特定客户端的重试，但反之则不然 -
0-全局启用或禁用LoadBalancer缓存。如果在全局上启用它，您可以通过创建不包含3中的2的1委托层次结构的自定义配置来禁用特定客户端的缓存，但反之则不然。
-
spring.cloud.loadbalancer.stats.micrometer.enabled- 全局启用或禁用LoadBalancer Micrometer指标
对于那些已经使用了映射的属性，在不使用clients关键字的情况下（例如，使用hints、health-check.path）可以为每个客户端指定不同的值，我们保留了这种行为以保持库的向后兼容性。该行为将在下个主要版本中进行修改。 |
从 4.1.0开始，我们在LoadBalancerProperties中引入了callGetWithRequestOnDelegates标志。如果将此标志设置为true，则在实现delegate.get(request)的类上调用ServiceInstanceListSupplier#get(Request request)方法，这些类可从DelegatingServiceInstanceListSupplier继承，但尚未实现该方法，排除CachingServiceInstanceListSupplier和HealthCheckServiceInstanceListSupplier，它们应直接放在实例提供商继承层次结构中，在执行任何基于请求的筛选之前，首先执行从提供商检索实例。默认情况下设置为true。 |
<h1>AOT and Native Image Support</h1>
从 4.0.0 开始，Spring Cloud LoadBalancer 支持 Spring AOT 转换和本机映像。但是，要使用此功能，您需要显式定义您的 LoadBalancerClient 服务 ID。您可以使用 value 或 name @LoadBalancerClient 注释的属性，或者作为 spring.cloud.loadbalancer.eager-load.clients 属性的值。