SpringCloud.Honxton 版本, 全新负载均衡器Loadbalancer
SpringCloud.Honxton 版本, 全新负载均衡器Loadbalancer
- SpringCloud.Honxton 版本, 全新负载均衡器Loadbalancer
- 前置说明
- 初步分析
- 负载均衡器的自动装配
- 服务列表的获取以及负载均衡的实现
- 总结
- 和ribbon的对比
SpringCloud.Honxton 版本, 全新负载均衡器Loadbalancer
前置说明
源码分析的版本为Honxton.Release. 为什么选这个版本呢? 是因为springcloud在这个版本才加入自己的负载均衡器. 不过springcloud为了兼容性,会在ribbon依赖引入时, 优先使用ribbon.
主要的依赖, 也可以直接下载我之前的 sample-springcloud 项目, 里面有 h版本的分支demo, 链接放到评论区
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-ribbonartifactId>
dependency>
初步分析
首先这个是在H版本才出现, 这个组件的目的根据官方文档所说就是: 提供自己而定客户端一遍负载均衡器抽象和实现. 主要是额外增加响应式的负载均衡器接口以及默认 的轮询实现(从这可以看出, 其负载均衡策略目前只有轮询, 所以暂时不建议从ribbon切换过来, 毕竟ribbon的负载均衡策略还是很丰富的).
那么, 一个负载均衡器怎么自动装配的肯定是我们需要关注的, 以及它服务列表来源, 以及怎么负载均衡和什么时候进行负载均衡. 接下来我们就这三个问题进行分析.
负载均衡器的自动装配
(本次源码基于阻塞式的客户端)在负载均衡器的自动装配类中, 主要是这三个 common/LoadBalancerAutoConfiguration , loadbalancer/LoadBalancerAutoConfiguration , BlockingLoadBalancerClientAutoConfiguration
那么我们一个个分析, 首先是common下的LoadBalancerAutoConfiguration自动配置类, 这个类的主要作用是提供LoadBalancerRequestFactory, 这个主要是用于生产LoadBalancerRequest,这个类具体的作用在下面分析
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(RestTemplate.class)
@ConditionalOnBean(LoadBalancerClient.class)
@EnableConfigurationProperties(LoadBalancerRetryProperties.class)
public class LoadBalancerAutoConfiguration {
// 提供工厂类
@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 {
// 提供resttemplate 拦截器, 这里的方法名请忽略ribbon, 因为这是commons包, 不可能和任何的实现有关系, 而且也没有和ribbon相关的条件装配, 应该是springcloud忘记改名字了.
// 这个类的作用就是连接restrtemplate 和 loadBalancerClient的纽带
@Bean
public LoadBalancerInterceptor ribbonInterceptor(
LoadBalancerClient loadBalancerClient,
LoadBalancerRequestFactory requestFactory) {
return new LoadBalancerInterceptor(loadBalancerClient, requestFactory);
}
// 将拦截器应用到RestTemplate中去
@Bean
@ConditionalOnMissingBean
public RestTemplateCustomizer restTemplateCustomizer(
final LoadBalancerInterceptor loadBalancerInterceptor) {
return restTemplate -> {
List<ClientHttpRequestInterceptor> list = new ArrayList<>(
restTemplate.getInterceptors());
list.add(loadBalancerInterceptor);
restTemplate.setInterceptors(list);
};
}
}
.... 其他方法省略
}
// 这个接口就是一个请求动作
public interface LoadBalancerRequest<T> {
T apply(ServiceInstance instance) throws Exception;
}
// LoadBalancerRequest 的工厂
public class LoadBalancerRequestFactory {
public LoadBalancerRequest<ClientHttpResponse> createRequest(
final HttpRequest request, final byte[] body,
final ClientHttpRequestExecution execution) {
return instance -> {
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); //具体的请求执行, 因为这里涉及restTemplate的源码了, 所以不在本文范围
};
}
}
接下来是loadbalancer依赖下的自动配置类, LoadBalancerAutoConfiguration ,
,BlockingLoadBalancerClientAutoConfiguration, 前一个的作用是提供LoadBalancerClientFactory, 后一个是为了提供BlockingLoadBalancerClient
@Configuration(proxyBeanMethods = false)
@LoadBalancerClients
@AutoConfigureBefore({ ReactorLoadBalancerClientAutoConfiguration.class,
LoadBalancerBeanPostProcessorAutoConfiguration.class,
ReactiveLoadBalancerAutoConfiguration.class })
public class LoadBalancerAutoConfiguration {
// 提供ReactiveLoadBalancer 负载均衡器
@Bean
public LoadBalancerClientFactory loadBalancerClientFactory() {
LoadBalancerClientFactory clientFactory = new LoadBalancerClientFactory();
clientFactory.setConfigurations(
this.configurations.getIfAvailable(Collections::emptyList));
return clientFactory;
}
}
public class LoadBalancerClientFactory
extends NamedContextFactory<LoadBalancerClientSpecification>
implements ReactiveLoadBalancer.Factory<ServiceInstance> {
// 如果自己设置了@LoadBalancerClient, 那么会从对应的子上下文中去获取, 否则就走defautl的配置
@Override
public ReactiveLoadBalancer<ServiceInstance> getInstance(String serviceId) {
return getInstance(serviceId, ReactorServiceInstanceLoadBalancer.class);
}
}
@Configuration(proxyBeanMethods = false)
@LoadBalancerClients
@AutoConfigureAfter(LoadBalancerAutoConfiguration.class)
@AutoConfigureBefore({
org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration.class,
AsyncLoadBalancerAutoConfiguration.class })
public class BlockingLoadBalancerClientAutoConfiguration {
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(RestTemplate.class)
@Conditional(OnNoRibbonDefaultCondition.class)
protected static class BlockingLoadbalancerClientConfig {
// 提供一个负载均衡的客户端
@Bean
@ConditionalOnBean(LoadBalancerClientFactory.class)
@Primary
public BlockingLoadBalancerClient blockingLoadBalancerClient(
LoadBalancerClientFactory loadBalancerClientFactory) {
// loadBalancerClientFactory
return new BlockingLoadBalancerClient(loadBalancerClientFactory);
}
}
// 阻塞的负载均衡客户端
public class BlockingLoadBalancerClient implements LoadBalancerClient {
private final LoadBalancerClientFactory loadBalancerClientFactory;
@Override
public <T> T execute(String serviceId, LoadBalancerRequest<T> request)
throws IOException {
// 获取serviceId 对应的服务实例
ServiceInstance serviceInstance = choose(serviceId);
if (serviceInstance == null) {
throw new IllegalStateException("No instances available for " + serviceId);
}
return execute(serviceId, serviceInstance, request);
}
@Override
public <T> T execute(String serviceId, ServiceInstance serviceInstance,
LoadBalancerRequest<T> request) throws IOException {
try {
return request.apply(serviceInstance); // 回调, 这个在上面讲过了, 其实就是调用restTemplate的方法去请求远程了
}
catch (IOException iOException) {
throw iOException;
}
catch (Exception exception) {
ReflectionUtils.rethrowRuntimeException(exception);
}
return null;
}
@Override
public ServiceInstance choose(String serviceId) {
// 获取负载均衡器
ReactiveLoadBalancer<ServiceInstance> loadBalancer = loadBalancerClientFactory
.getInstance(serviceId);
if (loadBalancer == null) {
return null;
}
Response<ServiceInstance> loadBalancerResponse = Mono.from(loadBalancer.choose())
.block();
if (loadBalancerResponse == null) {
return null;
}
return loadBalancerResponse.getServer();
}
}
springcloud实现的自动配置类真的是太长了 虽然我们用的时候很简单, 但是其实每个配置, 每个依赖都会影响自动装配的bean是哪个, 所以这里面的一些bean需要十分的了解 , 后面会对上面的各种bean进行串联分析.
服务列表的获取以及负载均衡的实现
从上面的一大堆装配的类, 那么其中提供服务列表的类就是ServiceInstanceListSupplier ,这个类其实是在LoadBalancerClientConfiguration这个类中提供的, 而这个类其实是通过 @LoadBalancerClient注解进行导入的, 所以在上面自动配置类里面没有发现这个配置类.
@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties
@ConditionalOnDiscoveryEnabled
public class LoadBalancerClientConfiguration {
@Configuration(proxyBeanMethods = false)
@ConditionalOnBlockingDiscoveryEnabled
@Order(REACTIVE_SERVICE_INSTANCE_SUPPLIER_ORDER + 1)
public static class BlockingSupportConfiguration {
@Bean
@ConditionalOnBean(DiscoveryClient.class)
@ConditionalOnMissingBean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
// 这个接口,我想看过我前一篇文章的人应该比较熟悉了,就是获取服务列表的springcloud的抽象接口
DiscoveryClient discoveryClient, Environment env,
ApplicationContext context) {
DiscoveryClientServiceInstanceListSupplier delegate = new DiscoveryClientServiceInstanceListSupplier(
discoveryClient, env);
ObjectProvider<LoadBalancerCacheManager> cacheManagerProvider = context
.getBeanProvider(LoadBalancerCacheManager.class);
if (cacheManagerProvider.getIfAvailable() != null) {
return new CachingServiceInstanceListSupplier(delegate,
cacheManagerProvider.getIfAvailable());
}
return delegate;
}
}
}
所以服务列表的获取就是通过DiscoveryClient(具体实现可以是EurekaDiscoveryClient), 那么具体的负载实现在哪个类实现呢?其实也是在上面的配置类中有的RoundRobinLoadBalancer
public class RoundRobinLoadBalancer implements ReactorServiceInstanceLoadBalancer {
private ObjectProvider<ServiceInstanceListSupplier> serviceInstanceListSupplierProvider;
// 负载均衡
public Mono<Response<ServiceInstance>> choose(Request request) {
if (serviceInstanceListSupplierProvider != null) {
// 这个就是上面提供到服务实例列表提供者, 这里调用它的get进行获取
ServiceInstanceListSupplier supplier = serviceInstanceListSupplierProvider
.getIfAvailable(NoopServiceInstanceListSupplier::new);
return supplier.get() // 调用get,下面会讲到
.next() // 获取第一个
.map(this::getInstanceResponse); // 将服务列表转换为一个实例,也就是调用取模方法
}
ServiceInstanceSupplier supplier = this.serviceInstanceSupplier
.getIfAvailable(NoopServiceInstanceSupplier::new);
return supplier.get().collectList().map(this::getInstanceResponse);
}
// 取模获取一个服务实例
private Response<ServiceInstance> getInstanceResponse(
List<ServiceInstance> instances) {
if (instances.isEmpty()) {
return new EmptyResponse();
}
int pos = Math.abs(this.position.incrementAndGet());
// 取模进行轮询
ServiceInstance instance = instances.get(pos % instances.size());
return new DefaultResponse(instance);
}
}
// 服务列表获取实现
public class DiscoveryClientServiceInstanceListSupplier
implements ServiceInstanceListSupplier {
private final String serviceId;
private final Flux<ServiceInstance> serviceInstances;
public DiscoveryClientServiceInstanceListSupplier(DiscoveryClient delegate,
Environment environment) {
this.serviceId = environment.getProperty(PROPERTY_NAME);
this.serviceInstances = Flux
.defer(() -> Flux.fromIterable(delegate.getInstances(serviceId))) //defer是延迟到订阅时才加载, fromIterable就是通过discoveryClient去获取对应serviceId的服务实例列表
.subscribeOn(Schedulers.boundedElastic());
}
public DiscoveryClientServiceInstanceListSupplier(ReactiveDiscoveryClient delegate,
Environment environment) {
this.serviceId = environment.getProperty(PROPERTY_NAME);
this.serviceInstances = delegate.getInstances(serviceId);
}
// 这里就是get的实现
@Override
public Flux<List<ServiceInstance>> get() {
return serviceInstances.collectList()//这里主要是将已发射的对象变成list
.flux(); // 这里就是转换mono转换 flux
// 这里需要说明一下, 看上去这里好像做了多余的操作,就是将delegate.getInstances(serviceId)获取的list一直转来转去,
// 其实是因为当前分析的是阻塞的服务提供列表, 如果是响应式负载均衡器, 那么服务端就不会一次性发送过来, 而是可能一下发2,3个一下2,3个,
// 所以这里在获取到2,3后就封装成一个list, 供后去的负载均衡使用.
// 想了解响应式的服务发现客户端, 具体可以看一下`ReactiveDiscoveryClient`这个接口和对应的实现类
}
}
总结
其实到这基本讲完了, 最后再来理一下思路
首先是服务列表来源 ,主要是DiscoveryClientServiceInstanceListSupplier这个类的get方法, 负载均衡算法是在RoundRobinLoadBalancer的getInstanceResponse方法, 然后和RestTemplate结合的是通过LoadBalancerInterceptor, 这些就是核心的类了.
分析就到这了, 可能讲的有点乱, 不过大体的思路已经给出, 然后后面会补个uml图, 希望读者有发现我讲的有问题可以在下面评论提出,我会虚心接受的.
和ribbon的对比
ribbon 的服务列表 DomainExtractingServerList,
ribbon 的负载均衡客户端 RibbonLoadBalancerClient
ribbon 的负载均衡器 ILoadBalancer 规则 IRule
其实可以看到负载均衡的实现都大相径庭, 不过目前Loadbalancer的负载均衡算法只有轮询,所以可以再等等,或者自己去实现丰富的负载均衡算法. 不过ribbon不好的地方在于ribbon自己也会维护一个服务列表, 这样相当于eureka client维护一套服务列表, ribbon维护一套, 那么这样服务下线后, ribbon的服务列表刷新的时间会很久, 因为无论是eureka还是ribbon都是定时去刷新的; 而Loadbalancer的实现,通过DiscoveryClientServiceInstanceListSupplier,直接将discoveryClient封装进去了,所以相对来说一致性会高很多