Spring Cloud 负载均衡器
Spring Cloud 提供了自己的客户端负载均衡抽象和实现。对于负载均衡机制，新增了 ReactiveLoadBalancer 接口，并为其提供了基于轮询和随机的实现。为了获取可供选择的实例，使用了 ServiceInstanceListSupplier 的响应式版本。目前，我们支持基于服务发现的 ServiceInstanceListSupplier 实现，该实现通过类路径中可用的发现客户端从服务发现中检索可用实例。
可以通过将 spring.cloud.loadbalancer.enabled 的值设置为 false 来禁用 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。要切换到不同的实现，无论是针对特定服务还是所有服务，都可以使用自定义 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 注解，要么应该在组件扫描范围之外。
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 Specification 来覆盖 LoadBalancer 的默认 Caffeine 缓存设置。
警告：传递自定义的 Caffeine 配置将覆盖所有其他负载均衡器缓存设置，包括 通用负载均衡器缓存配置 中的字段，例如 ttl 和 capacity。
默认负载均衡器缓存实现
如果您在类路径中没有 Caffeine，则会使用随 spring-cloud-starter-loadbalancer 自动提供的 DefaultLoadBalancerCache。有关如何配置它的信息，请参阅 LoadBalancerCacheConfiguration 部分。
要使用 Caffeine 替代默认缓存，请将 com.github.ben-manes.caffeine:caffeine 依赖项添加到 classpath 中。
负载均衡器缓存配置
你可以通过传递一个符合 Spring Boot 字符串到 Duration 转换器语法 的 String 来设置自己的 ttl 值（写入后条目应过期的时间），并将其作为 spring.cloud.loadbalancer.cache.ttl 属性的值。你还可以通过设置 spring.cloud.loadbalancer.cache.capacity 属性的值来设置自己的 LoadBalancer 缓存初始容量。
默认设置包括 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 或同一区域内没有实例，则返回所有检索到的实例。
为了使用基于区域的负载均衡方法，你需要在自定义配置中实例化一个 ZonePreferenceServiceInstanceListSupplier bean。
我们使用委托来处理 ServiceInstanceListSupplier bean。我们建议使用 DiscoveryClientServiceInstanceListSupplier 委托，并用 CachingServiceInstanceListSupplier 对其进行包装，以利用 LoadBalancer 缓存机制，然后将生成的 bean 传递给 ZonePreferenceServiceInstanceListSupplier 的构造函数。
你可以使用以下示例配置来进行设置：
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient()
.withCaching()
.withZonePreference()
.build(context);
}
}
负载均衡器的实例健康检查
可以为负载均衡器启用定期健康检查。为此提供了 HealthCheckServiceInstanceListSupplier。它会定期检查由委托的 ServiceInstanceListSupplier 提供的实例是否仍然存活，并且只返回健康的实例，除非没有健康的实例——在这种情况下，它会返回所有检索到的实例。
这种机制在使用 SimpleDiscoveryClient 时特别有用。对于由实际服务注册表支持的客户端来说，这并不是必需的，因为我们在查询外部服务发现后已经获得了健康的实例。
为了避免在出现故障的实例上重试调用，对于每个服务只有少量实例的设置也推荐使用此供应商。
如果使用任何基于服务发现的支持供应商，通常不需要添加此健康检查机制，因为我们直接从服务注册中心检索实例的健康状态。
HealthCheckServiceInstanceListSupplier 依赖于由委托的 flux 提供的更新实例。在极少数情况下，如果您希望使用一个不刷新实例的委托，即使实例列表可能会发生变化（例如我们提供的 DiscoveryClientServiceInstanceListSupplier），您可以将 spring.cloud.loadbalancer.health-check.refetch-instances 设置为 true，以便让 HealthCheckServiceInstanceListSupplier 刷新实例列表。然后，您还可以通过修改 spring.cloud.loadbalancer.health-check.refetch-instances-interval 的值来调整重新获取实例的间隔，并通过将 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，则首先将所有存活的实例序列收集到一个列表中，然后才发出信号，这确保了在属性中设置的健康检查间隔之间，flux 不会发出值。
为了使用健康检查调度器方法，您需要在自定义配置中实例化一个 HealthCheckServiceInstanceListSupplier bean。
我们使用委托来处理 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 的替代方案。
基于请求的负载均衡器粘性会话
你可以设置 LoadBalancer，使其优先选择请求 cookie 中提供的 instanceId 对应的实例。目前，如果请求通过 ClientRequestContext 或 ServerHttpRequestContext 传递给 LoadBalancer，我们支持此功能。这两个上下文由 SC LoadBalancer 的交换过滤器函数和过滤器使用。
为此，你需要使用 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 类型的提示，这些提示会在 Request 对象中传递给 LoadBalancer，并且稍后可以在能够处理这些提示的 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();
}
};
}
如果定义了多个 transformer，它们将按照 Beans 定义的顺序依次应用。或者，你可以使用 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 值通常会选择不同的子集。通常情况下，你不需要关注这一点。但是，如果你需要让多个实例选择相同的子集，可以通过设置 spring.cloud.loadbalancer.subset.instance-id 来实现（该属性支持占位符）。
默认情况下，子集的大小设置为 100。你也可以通过 spring.cloud.loadbalancer.subset.size 来设置它。
Spring Cloud LoadBalancer Starter
我们还提供了一个入门模板，让你能够轻松地在 Spring Boot 应用中添加 Spring Cloud LoadBalancer。要使用它，只需在你的构建文件中将 org.springframework.cloud:spring-cloud-starter-loadbalancer 添加到 Spring Cloud 依赖项中即可。
Spring Cloud LoadBalancer 启动器包含了 Spring Boot 缓存 和 Evictor。
传递您自己的 Spring Cloud LoadBalancer 配置
你也可以使用 @LoadBalancerClient 注解来传递你自己的负载均衡客户端配置，传递负载均衡客户端的名称和配置类，如下所示：
@Configuration
@LoadBalancerClient(value = "stores", configuration = CustomLoadBalancerConfiguration.class)
public class MyConfiguration {
@Bean
@LoadBalanced
public WebClient.Builder loadBalancedWebClientBuilder() {
return WebClient.builder();
}
}
为了让你更容易地处理自己的负载均衡器配置，我们在 ServiceInstanceListSupplier 类中添加了一个 builder() 方法。
你也可以通过将 spring.cloud.loadbalancer.configurations 属性的值设置为 zone-preference 来使用 ZonePreferenceServiceInstanceListSupplier（带缓存），或者设置为 health-check 来使用 HealthCheckServiceInstanceListSupplier（带缓存），以替代默认的预定义配置。
你可以使用这个功能来实例化 ServiceInstanceListSupplier 或 ReactorLoadBalancer 的不同实现，这些实现可以是你自己编写的，也可以是我们提供的替代方案（例如 ZonePreferenceServiceInstanceListSupplier），以覆盖默认的设置。
你可以在这里看到一个自定义配置的示例：基于区域的自定义负载均衡器配置。
注解 value 参数（如上例中的 stores）指定了我们应使用给定自定义配置向其发送请求的服务的服务 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 生命周期
在使用自定义负载均衡器配置时，注册一种可能很有用的 bean 是 LoadBalancerLifecycle。
LoadBalancerLifecycle bean 提供了回调方法，包括 onStart(Request<RC> request)、onStartRequest(Request<RC> request, Response<T> lbResponse) 和 onComplete(CompletionContext<RES, T, RC> completionContext)。你需要实现这些方法来指定在负载均衡之前和之后应该执行的操作。
onStart(Request<RC> request) 方法接收一个 Request 对象作为参数。该对象包含用于选择合适实例的数据，包括下游客户端请求和 hint。onStartRequest 方法也接收 Request 对象，此外还接收 Response<T> 对象作为参数。另一方面，onComplete(CompletionContext<RES, T, RC> completionContext) 方法提供了一个 CompletionContext 对象。该对象包含负载均衡器 Response，包括选中的服务实例、针对该服务实例执行的请求的 Status，以及（如果可用）返回给下游客户端的响应，还有（如果发生了异常）相应的 Throwable。
supports(Class requestContextClass, Class responseClass, Class serverTypeClass) 方法可用于确定处理器是否处理提供的类型的对象。如果用户没有重写此方法，则默认返回 true。
在前面的方法调用中，RC 表示 RequestContext 类型，RES 表示客户端响应类型，T 表示返回的服务器类型。
Spring Cloud LoadBalancer 统计
我们提供了一个名为 MicrometerStatsLoadBalancerLifecycle 的 LoadBalancerLifecycle bean，它使用 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: 一个计数器，用于测量被丢弃的负载均衡请求的数量，即 LoadBalancer 未能检索到用于执行请求的服务实例的请求。
有关服务实例、请求数据和响应数据的附加信息（在可用时）通过标签添加到指标中。
对于基于 WebClient 和 RestClient 的负载均衡，我们在 uri 标签可用时使用 uriTemplate。
可以通过将 spring.cloud.loadbalancer.stats.include-path 设置为 false 来禁用将 path 添加到 uri 标签。
与 RestTemplate 支持的负载均衡一样，我们无法访问 uriTemplate，完整路径始终在 uri 标签中使用。为了避免高基数问题，如果路径是一个高基数值（例如 /orders/{id}，其中 id 取大量值），强烈建议通过将 spring.cloud.loadbalancer.stats.include-path 设置为 false 来禁用将路径添加到 uri 标签。
对于某些实现，例如 BlockingLoadBalancerClient，请求和响应数据可能不可用，因为我们从参数中建立泛型类型，可能无法确定类型并读取数据。
当为某个计量器添加至少一条记录时，计量器会在注册表中注册。
你可以通过添加 MeterFilters 来进一步配置这些指标的行为（例如，添加发布百分位数和直方图）。
配置单个 LoadBalancerClients
可以为每个负载均衡器客户端单独配置不同的前缀 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。
每个客户端的配置属性适用于大多数属性，除了以下全局属性：
-
spring.cloud.loadbalancer.enabled- 全局启用或禁用负载均衡 -
spring.cloud.loadbalancer.retry.enabled- 全局启用或禁用负载均衡重试。如果全局启用，你仍然可以使用以client为前缀的属性为特定客户端禁用重试，但不能反过来操作 -
spring.cloud.loadbalancer.cache.enabled- 全局启用或禁用 LoadBalancer 缓存。如果全局启用，你仍然可以通过创建自定义配置来为特定客户端禁用缓存，该配置不包括ServiceInstanceListSupplier委托层次结构中的CachingServiceInstanceListSupplier，但不能反过来操作 -
spring.cloud.loadbalancer.stats.micrometer.enabled- 全局启用或禁用 LoadBalancer 的 Micrometer 指标
对于那些已经使用映射的属性，您可以在不使用 clients 关键字的情况下为每个客户端指定不同的值（例如，hints、health-check.path），我们保留了这种行为以保持库的向后兼容性。这将在下一个主要版本中进行修改。
从 4.1.0 版本开始，我们在 LoadBalancerProperties 中引入了 callGetWithRequestOnDelegates 标志。如果该标志设置为 true，ServiceInstanceListSupplier#get(Request request) 方法将在未实现该方法的 DelegatingServiceInstanceListSupplier 可分配类中调用 delegate.get(request)，但 CachingServiceInstanceListSupplier 和 HealthCheckServiceInstanceListSupplier 除外，这两个类应直接放置在执行网络实例检索的实例供应商层次结构中，在任何基于请求的过滤之前。默认情况下，该标志设置为 true。
[[-aot-and-native-image-support]] == AOT 和原生镜像支持
自 4.0.0 版本起，Spring Cloud LoadBalancer 支持 Spring AOT 转换和原生镜像。然而，要使用此功能，您需要显式定义您的 LoadBalancerClient 服务 ID。您可以通过使用 @LoadBalancerClient 注解的 value 或 name 属性，或者作为 spring.cloud.loadbalancer.eager-load.clients 属性的值来实现这一点。