一.介绍下测试用到的服务
从Eureka注册中心中可以可以看出有EUREKA-CLIENT和RIBBON-CLIENT的服务,其中EUREKA-CLIENT有两个节点作为服务提供者,而RIBBON-CLIENT则是服务消费者,通过RestTemplate来消费EUREKA-CLIENT的服务。
下面代码就是简单实现Ribbon负载均衡的配置类:
@Configuration
public class RibbonConfig {
@Bean
@LoadBalanced
RestTemplate getRestTemlate() {
return new RestTemplate();
}
}
这样简单的通过一个@LoadBalanced注解在RestTemplate上 ,在RestTemplate 远程调用的时候,就会出现负载均衡的效果。
二.一步一步理清Ribbon负载均衡的逻辑
@Configuration
@ConditionalOnClass(RestTemplate.class)
@ConditionalOnBean(LoadBalancerClient.class)
@EnableConfigurationProperties(LoadBalancerRetryProperties.class)
public class LoadBalancerAutoConfiguration {
/**
* 这段代码的作用是将有用@LoadBalanced注解的RestTemplate注入
*/
@LoadBalanced
@Autowired(required = false)
private List<RestTemplate> restTemplates = Collections.emptyList();
}
分析以上代码:
@ConfigurationProperties("spring.cloud.loadbalancer.retry")
public class LoadBalancerRetryProperties {
private boolean enabled = true;
/**
* Returns true if the load balancer should retry failed requests.
* @return True if the load balancer should retry failed requests; false otherwise.
*/
public boolean isEnabled() {
return this.enabled;
}
@Bean
@ConditionalOnMissingBean
public LoadBalancerRequestFactory loadBalancerRequestFactory(
LoadBalancerClient loadBalancerClient) {
return new LoadBalancerRequestFactory(loadBalancerClient, this.transformers);
}
接下去断点进入LoadBalancerAutoConfiguration 类中的静态内部类LoadBalancerInterceptorConfig的ribbonInterceptor方法,可以看出这是为了实例化出LoadBalancerInterceptor 拦截器
@Configuration
@ConditionalOnMissingClass("org.springframework.retry.support.RetryTemplate")
static class LoadBalancerInterceptorConfig {
@Bean
public LoadBalancerInterceptor ribbonInterceptor(
LoadBalancerClient loadBalancerClient,
LoadBalancerRequestFactory requestFactory) {
return new LoadBalancerInterceptor(loadBalancerClient, requestFactory);
}
继续跟断点,进入了loadBalancedRestTemplateInitializerDeprecated方法,可以看出这个方法里主要的逻辑代码是customizer.customize(restTemplate)
@Bean
public SmartInitializingSingleton loadBalancedRestTemplateInitializerDeprecated(
final ObjectProvider<List<RestTemplateCustomizer>> restTemplateCustomizers) {
return () -> restTemplateCustomizers.ifAvailable(customizers -> {
for (RestTemplate restTemplate : LoadBalancerAutoConfiguration.this.restTemplates) {
for (RestTemplateCustomizer customizer : customizers) {
customizer.customize(restTemplate);
}
}
});
}
继续Debug,断点进入LoadBalancerAutoConfiguration类中的静态内部类LoadBalancerInterceptorConfig:
@Configuration
@ConditionalOnMissingClass("org.springframework.retry.support.RetryTemplate")
static class LoadBalancerInterceptorConfig {
@Bean
@ConditionalOnMissingBean
public RestTemplateCustomizer restTemplateCustomizer(
final LoadBalancerInterceptor loadBalancerInterceptor) {
return restTemplate -> {
List<ClientHttpRequestInterceptor> list = new ArrayList<>(
restTemplate.getInterceptors());
list.add(loadBalancerInterceptor);
restTemplate.setInterceptors(list);
};
}
}
通过 list.add(loadBalancerInterceptor)和restTemplate.setInterceptors(list)两段代码可以看出,这是要给restTemplate加上loadBalancerInterceptor拦截器。
那么接下来看看loadBalancerInterceptor拦截器里做了什么,通过页面发起一个http请求,断点进入到LoadBalancerInterceptor类的intercept方法,
@Override
public ClientHttpResponse intercept(final HttpRequest request, final byte[] body,
final ClientHttpRequestExecution execution) throws IOException {
final URI originalUri = request.getURI();
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));
}
截图看下信息:
可以看到该方法取得了request里的url和servicName,然后将这些参数交给loadBalancer.execute去执行方法。而loadBalancer是LoadBalancerClient类的实例。
看下LoadBalancerClient的类图,可以看到LoadBalancerClient继承了ServiceInstanceChooser,LoadBalancerClient的实现类是RibbonLoadBalancerClient
逻辑继续,断点进入了RibbonLoadBalancerClient的execute方法
public <T> T execute(String serviceId, LoadBalancerRequest<T> request, Object hint)
throws IOException {
ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
Server server = getServer(loadBalancer, hint);
if (server == null) {
throw new IllegalStateException("No instances available for " + serviceId);
}
RibbonServer ribbonServer = new RibbonServer(serviceId, server,
isSecure(server, serviceId),
serverIntrospector(serviceId).getMetadata(server));
return execute(serviceId, ribbonServer, request);
}
跟着断点一步一步看方法:
ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
经过这个方法,得到loadBalancer,从截图里可以看到,loadBalancer里有个allServerList集合,里面有两个对象,端口号分别是8763和8762,这就是我们提供的服务节点。
Server server = getServer(loadBalancer, hint)
从图里可以看出,通过这个getServer方法,会返回给我们一个当前可调用的服务节点,而至于怎么返回服务节点,会再写一篇分析,写完后会更新链接到该篇。
生成RibbonServer 作为参数传入execute方法
运行execute方法
接着跟进execute方法
可以看该方法里的关键执行方法是:
T returnVal = request.apply(serviceInstance);
接着看apply方法,发现它是LoadBalancerRequest接口的方法,该接口却没有具体的实现类:
public interface LoadBalancerRequest<T> {
T apply(ServiceInstance instance) throws Exception;
}
思路回溯,是request对象调用的apply方法,而request其实是execute方法传进来的参数,追溯到源头,发现是LoadBalancerInterceptor类的intercept方法里this.requestFactory.createRequest(request, body, execution)生成了LoadBalancerRequest,然后作为参数传入,之后再调用了apply方法
@Override
public ClientHttpResponse intercept(final HttpRequest request, final byte[] body,
final ClientHttpRequestExecution execution) throws IOException {
final URI originalUri = request.getURI();
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));
}
跟进createRequest方法里:
可以从图中看到,经过一些操作后,生成的serviceRequest对象里的serviceId是eureka-client,也就是我们的服务节点名,而server是localhost:8763,这是具体的服务节点ip,之后作为参数调用org.springframework.http.client包下的InterceptingClientHttpRequest类中的execute方法
断点进入该方法:
可以看出通过requestFactory.createRequest(request.getURI(), method)方法生成了ClientHttpRequest类的实例delegate,它的url就是我们最后真正要请求的,最后正常调用delegate.execute()方法取得返回ClientHttpResponse就好了。
而这里产生了一个疑问,url是怎么产生的?重新发起请求断点试下
发现关键在LoadBalancerRequestFactory类中的createRequest方法中的这句:
HttpRequest serviceRequest = new ServiceRequestWrapper(request, instance,his.loadBalancer);
跟进ServiceRequestWrapper类中,发现它继承了HttpRequestWrapper 类,同时重写了getURI方法
public class ServiceRequestWrapper extends HttpRequestWrapper {
private final ServiceInstance instance;
private final LoadBalancerClient loadBalancer;
public ServiceRequestWrapper(HttpRequest request, ServiceInstance instance,
LoadBalancerClient loadBalancer) {
super(request);
this.instance = instance;
this.loadBalancer = loadBalancer;
}
@Override
public URI getURI() {
URI uri = this.loadBalancer.reconstructURI(this.instance, getRequest().getURI());
return uri;
}
}
断点打在getURI方法里:
可以看到该方法返回了我们最后需要的url。
最后,关于Ribbon是如何通过一个@LoadBalanced注解就实现负载均衡的分析就到这了,还是有很多疏漏的地方,但是大致的逻辑就是这样的了,还有一些更深层的比如如何根据策略选出当前提供服务的节点等,留待后续补充,来日方长~