Spring Cloud Ribbon负载均衡器处理方法

接下来撸一撸负载均衡器的内部,看看是如何获取服务实例,获取以后做了哪些处理,处理后又是如何选取服务实例的。

分成三个部分来撸:

  • 配置
  • 获取服务
  • 选择服务

配置

在上一篇《撸一撸Spring Cloud Ribbon的原理》的配置部分可以看到默认的负载均衡器是ZoneAwareLoadBalancer。

看一看配置类。

位置:

spring-cloud-netflix-core-1.3.5.RELEASE.jar
org.springframework.cloud.netflix.ribbon
RibbonClientConfiguration.class
@SuppressWarnings("deprecation")
@Configuration
@EnableConfigurationProperties
//Order is important here, last should be the default, first should be optional
// see https://github.com/spring-cloud/spring-cloud-netflix/issues/2086#issuecomment-316281653
@Import({OkHttpRibbonConfiguration.class, RestClientRibbonConfiguration.class, HttpClientRibbonConfiguration.class})
public class RibbonClientConfiguration {
// 略
 @Bean
 @ConditionalOnMissingBean
 public ILoadBalancer ribbonLoadBalancer(IClientConfig config,
 ServerList<Server> serverList, ServerListFilter<Server> serverListFilter,
 IRule rule, IPing ping, ServerListUpdater serverListUpdater) {
 if (this.propertiesFactory.isSet(ILoadBalancer.class, name)) {
 return this.propertiesFactory.get(ILoadBalancer.class, config, name);
 }
 return new ZoneAwareLoadBalancer<>(config, rule, ping, serverList,
 serverListFilter, serverListUpdater);
 }
// 略
}

在实例化ZoneAwareLoadBalancer的时候注入了,config、rule、ping、serverList、serverListFilter、serverListUpdater实例。

config:配置实例。

rule:负载均衡策略实例。

ping:ping实例。

serverList:获取和更新服务的实例。

serverListFilter:服务过滤实例。

serverListUpdater:服务列表信息更新实例。

@SuppressWarnings("deprecation")
@Configuration
@EnableConfigurationProperties
//Order is important here, last should be the default, first should be optional
// see https://github.com/spring-cloud/spring-cloud-netflix/issues/2086#issuecomment-316281653
@Import({OkHttpRibbonConfiguration.class, RestClientRibbonConfiguration.class, HttpClientRibbonConfiguration.class})
public class RibbonClientConfiguration {
 // 略
 @Bean
 @ConditionalOnMissingBean
 public IClientConfig ribbonClientConfig() {
 DefaultClientConfigImpl config = new DefaultClientConfigImpl();
 config.loadProperties(this.name);
 return config;
 }
 @Bean
 @ConditionalOnMissingBean
 public IRule ribbonRule(IClientConfig config) {
 if (this.propertiesFactory.isSet(IRule.class, name)) {
 return this.propertiesFactory.get(IRule.class, config, name);
 }
 ZoneAvoidanceRule rule = new ZoneAvoidanceRule();
 rule.initWithNiwsConfig(config);
 return rule;
 }
 @Bean
 @ConditionalOnMissingBean
 public IPing ribbonPing(IClientConfig config) {
 if (this.propertiesFactory.isSet(IPing.class, name)) {
 return this.propertiesFactory.get(IPing.class, config, name);
 }
 return new DummyPing();
 }
 @Bean
 @ConditionalOnMissingBean
 @SuppressWarnings("unchecked")
 public ServerList<Server> ribbonServerList(IClientConfig config) {
 if (this.propertiesFactory.isSet(ServerList.class, name)) {
 return this.propertiesFactory.get(ServerList.class, config, name);
 }
 ConfigurationBasedServerList serverList = new ConfigurationBasedServerList();
 serverList.initWithNiwsConfig(config);
 return serverList;
 }
 @Bean
 @ConditionalOnMissingBean
 public ServerListUpdater ribbonServerListUpdater(IClientConfig config) {
 return new PollingServerListUpdater(config);
 }
 @Bean
 @ConditionalOnMissingBean
 public ILoadBalancer ribbonLoadBalancer(IClientConfig config,
 ServerList<Server> serverList, ServerListFilter<Server> serverListFilter,
 IRule rule, IPing ping, ServerListUpdater serverListUpdater) {
 if (this.propertiesFactory.isSet(ILoadBalancer.class, name)) {
 return this.propertiesFactory.get(ILoadBalancer.class, config, name);
 }
 return new ZoneAwareLoadBalancer<>(config, rule, ping, serverList,
 serverListFilter, serverListUpdater);
 }
 @Bean
 @ConditionalOnMissingBean
 @SuppressWarnings("unchecked")
 public ServerListFilter<Server> ribbonServerListFilter(IClientConfig config) {
 if (this.propertiesFactory.isSet(ServerListFilter.class, name)) {
 return this.propertiesFactory.get(ServerListFilter.class, config, name);
 }
 ZonePreferenceServerListFilter filter = new ZonePreferenceServerListFilter();
 filter.initWithNiwsConfig(config);
 return filter;
 }
 @Bean
 @ConditionalOnMissingBean
 public RibbonLoadBalancerContext ribbonLoadBalancerContext(
 ILoadBalancer loadBalancer, IClientConfig config, RetryHandler retryHandler) {
 return new RibbonLoadBalancerContext(loadBalancer, config, retryHandler);
 }
 // 略
}

在这里配置相关的实例

config:DefaultClientConfigImpl。

rule:ZoneAvoidanceRule。

ping:DummyPing。

serverList:ConfigurationBasedServerList,基于配置的服务列表实例。

serverListFilter:ZonePreferenceServerListFilter。

serverListUpdater:PollingServerListUpdater。

要注意的是,在这里serverList的实例是ConfigurationBasedServerList,这是在未使用Eureka时获取服务信息的实例,是从配置文件中获取。

那么在和Eureka配合使用时,需要从 Eureka Server获取服务信息,那该是哪个实例来做这件事情呢。

在启用Eureka服务发现时,会首先会采用EurekaRibbonClientConfiguration配置类。

位置:

spring-cloud-netflix-eureka-client-1.3.5.RELEASE.jar
org.springframework.cloud.netflix.ribbon.eureka
EurekaRibbonClientConfiguration.class
@Configuration
@CommonsLog
public class EurekaRibbonClientConfiguration {
 // 略
 @Bean
 @ConditionalOnMissingBean
 public IPing ribbonPing(IClientConfig config) {
 if (this.propertiesFactory.isSet(IPing.class, serviceId)) {
 return this.propertiesFactory.get(IPing.class, config, serviceId);
 }
 NIWSDiscoveryPing ping = new NIWSDiscoveryPing();
 ping.initWithNiwsConfig(config);
 return ping;
 }
 @Bean
 @ConditionalOnMissingBean
 public ServerList<?> ribbonServerList(IClientConfig config, Provider<EurekaClient> eurekaClientProvider) {
 if (this.propertiesFactory.isSet(ServerList.class, serviceId)) {
 return this.propertiesFactory.get(ServerList.class, config, serviceId);
 }
 DiscoveryEnabledNIWSServerList discoveryServerList = new DiscoveryEnabledNIWSServerList(
 config, eurekaClientProvider);
 DomainExtractingServerList serverList = new DomainExtractingServerList(
 discoveryServerList, config, this.approximateZoneFromHostname);
 return serverList;
 }
 // 略
}

在首先采用了EurekaRibbonClientConfiguration配置后,实际上各实例变成了

config:DefaultClientConfigImpl。

rule:ZoneAvoidanceRule。

ping:NIWSDiscoveryPing。

serverList:DomainExtractingServerList,内部是DiscoveryEnabledNIWSServerList,实际上是通过服务发现获取服务信息列表。

serverListFilter:ZonePreferenceServerListFilter。

serverListUpdater:PollingServerListUpdater。

获取服务

在找到获取服务信息入口前,先把负载均衡器的类继承关系撸一下。

在ZoneAwareLoadBalancer的构造中调用了父类DynamicServerListLoadBalancer构造。

位置:

ribbon-loadbalancer-2.2.2.jar

com.netflix.loadbalancer

ZoneAwareLoadBalancer.class

在DynamicServerListLoadBalancer的构造中,调用了restOfInit函数。

ribbon-loadbalancer-2.2.2.jar

com.netflix.loadbalancer

DynamicServerListLoadBalancer.class

 void restOfInit(IClientConfig clientConfig) {
 boolean primeConnection = this.isEnablePrimingConnections();
 // turn this off to avoid duplicated asynchronous priming done in BaseLoadBalancer.setServerList()
 this.setEnablePrimingConnections(false);
 enableAndInitLearnNewServersFeature();
 updateListOfServers();
 if (primeConnection && this.getPrimeConnections() != null) {
 this.getPrimeConnections()
  .primeConnections(getReachableServers());
 }
 this.setEnablePrimingConnections(primeConnection);
 LOGGER.info("DynamicServerListLoadBalancer for client {} initialized: {}", clientConfig.getClientName(), this.toString());
 }

先是通过调用enableAndInitLearnNewServersFeature方法启动定时更新服务列表,然后立即调用updateListOfServers函数马上获取并更新服务列表信息。

先看下enableAndInitLearnNewServersFeature方法,实际上是调用了服务列表信息更新实例的start方法启动定时更新功能。

 /**
 * Feature that lets us add new instances (from AMIs) to the list of
 * existing servers that the LB will use Call this method if you want this
 * feature enabled
 */
 public void enableAndInitLearnNewServersFeature() {
 LOGGER.info("Using serverListUpdater {}", serverListUpdater.getClass().getSimpleName());
 serverListUpdater.start(updateAction);
 }

这里的服务列表信息更新实例就是配置阶段配置的PollingServerListUpdater实例,看一下这个类的构造和start方法。

public class PollingServerListUpdater implements ServerListUpdater {
 // 略
 private static long LISTOFSERVERS_CACHE_UPDATE_DELAY = 1000; // msecs;
 private static int LISTOFSERVERS_CACHE_REPEAT_INTERVAL = 30 * 1000; // msecs;
 // 略
 private final AtomicBoolean isActive = new AtomicBoolean(false);
 private volatile long lastUpdated = System.currentTimeMillis();
 private final long initialDelayMs;
 private final long refreshIntervalMs;
 // 略
 public PollingServerListUpdater(IClientConfig clientConfig) {
 this(LISTOFSERVERS_CACHE_UPDATE_DELAY, getRefreshIntervalMs(clientConfig));
 }
 public PollingServerListUpdater(final long initialDelayMs, final long refreshIntervalMs) {
 this.initialDelayMs = initialDelayMs;
 this.refreshIntervalMs = refreshIntervalMs;
 }
 @Override
 public synchronized void start(final UpdateAction updateAction) {
 if (isActive.compareAndSet(false, true)) {
 final Runnable wrapperRunnable = new Runnable() {
 @Override
 public void run() {
  if (!isActive.get()) {
  if (scheduledFuture != null) {
  scheduledFuture.cancel(true);
  }
  return;
  }
  try {
  updateAction.doUpdate();
  lastUpdated = System.currentTimeMillis();
  } catch (Exception e) {
  logger.warn("Failed one update cycle", e);
  }
 }
 };
 scheduledFuture = getRefreshExecutor().scheduleWithFixedDelay(
  wrapperRunnable,
  initialDelayMs,
  refreshIntervalMs,
  TimeUnit.MILLISECONDS
 );
 } else {
 logger.info("Already active, no-op");
 }
 }
 // 略
}

从构造和常量定义看出来,延迟一秒执行,默认每隔30秒执行更新,可以通过配置修改间隔更新的时间。

从start方法看,就是开了一个定时执行的schedule,定时执行 updateAction.doUpdate()。

回到start方法调用方DynamicServerListLoadBalancer类中看一下UpdateAction实例的定义。

protected final ServerListUpdater.UpdateAction updateAction = new ServerListUpdater.UpdateAction() {
 @Override
 public void doUpdate() {
 updateListOfServers();
 }
 };

实际上就是调用了DynamicServerListLoadBalancer类的updateListOfServers方法,这跟启动完定时更新后立即更新服务信息列表的路径是一致的。

继续看updateListOfServers方法。

public void updateListOfServers() {
 List<T> servers = new ArrayList<T>();
 if (serverListImpl != null) {
 servers = serverListImpl.getUpdatedListOfServers();
 LOGGER.debug("List of Servers for {} obtained from Discovery client: {}",
  getIdentifier(), servers);
 if (filter != null) {
 servers = filter.getFilteredListOfServers(servers);
 LOGGER.debug("Filtered List of Servers for {} obtained from Discovery client: {}",
  getIdentifier(), servers);
 }
 }
 updateAllServerList(servers);
 }

1.通过ServerList实例获取服务信息列表。

2.通过ServerListFilter 实例对获取到的服务信息列表进行过滤。

3.将过滤后的服务信息列表保存到LoadBalancerStats中作为状态保持。

接下分别看一下。

1.通过ServerList实例获取服务信息列表。

ServerList实例就是配置阶段生成的DomainExtractingServerList,获取服务信息都是委托给DiscoveryEnabledNIWSServerList。

public class DiscoveryEnabledNIWSServerList extends AbstractServerList<DiscoveryEnabledServer>{
 // 略
 @Override
 public List<DiscoveryEnabledServer> getInitialListOfServers(){
 return obtainServersViaDiscovery();
 }
 @Override
 public List<DiscoveryEnabledServer> getUpdatedListOfServers(){
 return obtainServersViaDiscovery();
 }
 private List<DiscoveryEnabledServer> obtainServersViaDiscovery() {
 List<DiscoveryEnabledServer> serverList = new ArrayList<DiscoveryEnabledServer>();
 if (eurekaClientProvider == null || eurekaClientProvider.get() == null) {
 logger.warn("EurekaClient has not been initialized yet, returning an empty list");
 return new ArrayList<DiscoveryEnabledServer>();
 }
 EurekaClient eurekaClient = eurekaClientProvider.get();
 if (vipAddresses!=null){
 for (String vipAddress : vipAddresses.split(",")) {
 // if targetRegion is null, it will be interpreted as the same region of client
 List<InstanceInfo> listOfInstanceInfo = eurekaClient.getInstancesByVipAddress(vipAddress, isSecure, targetRegion);
 for (InstanceInfo ii : listOfInstanceInfo) {
  if (ii.getStatus().equals(InstanceStatus.UP)) {
  if(shouldUseOverridePort){
  if(logger.isDebugEnabled()){
  logger.debug("Overriding port on client name: " + clientName + " to " + overridePort);
  }
  // copy is necessary since the InstanceInfo builder just uses the original reference,
  // and we don't want to corrupt the global eureka copy of the object which may be
  // used by other clients in our system
  InstanceInfo copy = new InstanceInfo(ii);
  if(isSecure){
  ii = new InstanceInfo.Builder(copy).setSecurePort(overridePort).build();
  }else{
  ii = new InstanceInfo.Builder(copy).setPort(overridePort).build();
  }
  }
  DiscoveryEnabledServer des = new DiscoveryEnabledServer(ii, isSecure, shouldUseIpAddr);
  des.setZone(DiscoveryClient.getZone(ii));
  serverList.add(des);
  }
 }
 if (serverList.size()>0 && prioritizeVipAddressBasedServers){
  break; // if the current vipAddress has servers, we dont use subsequent vipAddress based servers
 }
 }
 }
 return serverList;
 }
 // 略
}

可以看到其实就是通过Eureka客户端从Eureka服务端获取所有服务实例信息并把上线的包装成DiscoveryEnabledServer实例,带有zone信息,做到服务列表中。

2.通过ServerListFilter 实例对获取到的服务信息列表进行过滤。

serverListFilte实例就是配置阶段生成的ZonePreferenceServerListFilter,通过调用该实例的getFilteredListOfServers方法进行过滤。

@Data
@EqualsAndHashCode(callSuper = false)
public class ZonePreferenceServerListFilter extends ZoneAffinityServerListFilter<Server> {
 private String zone;
 @Override
 public void initWithNiwsConfig(IClientConfig niwsClientConfig) {
 super.initWithNiwsConfig(niwsClientConfig);
 if (ConfigurationManager.getDeploymentContext() != null) {
 this.zone = ConfigurationManager.getDeploymentContext().getValue(
  ContextKey.zone);
 }
 }
 @Override
 public List<Server> getFilteredListOfServers(List<Server> servers) {
 List<Server> output = super.getFilteredListOfServers(servers);
 if (this.zone != null && output.size() == servers.size()) {
 List<Server> local = new ArrayList<Server>();
 for (Server server : output) {
 if (this.zone.equalsIgnoreCase(server.getZone())) {
  local.add(server);
 }
 }
 if (!local.isEmpty()) {
 return local;
 }
 }
 return output;
 }
}

在getFilteredListOfServers方法里面,一上来是调用父类的同名方法先过滤,其实父类也是把和消费端同区域的服务给过滤出来使用,不仅如此,增加了些智能的判定,保证在故障/负载较高时或者可用实例较少时不进行同区域的过滤。

但是在ZonePreferenceServerListFilter.getFilteredListOfServers这里,就算父类没做过过滤,这里依然要把同zone的服务给滤出来使用,谁叫这里的类是ZonePreference的呢。

这是比较怪异的地方,感觉父类的智能判定没什么作用。

还是看看ZoneAffinityServerListFilter.getFilteredListOfServers做的辛苦工作吧。

public class ZoneAffinityServerListFilter<T extends Server> extends
 AbstractServerListFilter<T> implements IClientConfigAware {
 // 略
 private boolean shouldEnableZoneAffinity(List<T> filtered) {
 if (!zoneAffinity && !zoneExclusive) {
 return false;
 }
 if (zoneExclusive) {
 return true;
 }
 LoadBalancerStats stats = getLoadBalancerStats();
 if (stats == null) {
 return zoneAffinity;
 } else {
 logger.debug("Determining if zone affinity should be enabled with given server list: {}", filtered);
 ZoneSnapshot snapshot = stats.getZoneSnapshot(filtered);
 double loadPerServer = snapshot.getLoadPerServer();
 int instanceCount = snapshot.getInstanceCount();
 int circuitBreakerTrippedCount = snapshot.getCircuitTrippedCount();
 if (((double) circuitBreakerTrippedCount) / instanceCount >= blackOutServerPercentageThreshold.get()
  || loadPerServer >= activeReqeustsPerServerThreshold.get()
  || (instanceCount - circuitBreakerTrippedCount) < availableServersThreshold.get()) {
 logger.debug("zoneAffinity is overriden. blackOutServerPercentage: {}, activeReqeustsPerServer: {}, availableServers: {}",
  new Object[] {(double) circuitBreakerTrippedCount / instanceCount, loadPerServer, instanceCount - circuitBreakerTrippedCount});
 return false;
 } else {
 return true;
 }
 }
 }
 @Override
 public List<T> getFilteredListOfServers(List<T> servers) {
 if (zone != null && (zoneAffinity || zoneExclusive) && servers !=null && servers.size() > 0){
 List<T> filteredServers = Lists.newArrayList(Iterables.filter(
  servers, this.zoneAffinityPredicate.getServerOnlyPredicate()));
 if (shouldEnableZoneAffinity(filteredServers)) {
 return filteredServers;
 } else if (zoneAffinity) {
 overrideCounter.increment();
 }
 }
 return servers;
 }
 // 略
}

首先会将与消费端相同的zone的服务过滤出来,然后通过shouldEnableZoneAffinity(filteredServers)来判定是否可以采纳同zone的服务,还是采用所有的服务。

在shouldEnableZoneAffinity方法内,对相同zone的服务做了一次snapshot,获取这些服务的实例数量,平均负载,断路的实例数进行计算判定。

可以看一下initWithNiwsConfig方法中关键指标的值。

判定条件:

断路实例百分比>=0.8(断路的实例数/服务的实例数量)

平均负载>=0.6

可用实例数<2(实例数量-断路的实例数)

如果达到判定条件,那么就使用全部的服务,保证可用性。

但,上面也说了,因为ZonePreferenceServerListFilter本身总是会选用和消费端zone一致的服务,所以ZoneAffinityServerListFilter.getFilteredListOfServers中做的智能操作并没什么用。

不过,当然可以通过自定义配置来采用ZoneAffinityServerListFilter实例。

3.将过滤后的服务信息列表保存到LoadBalancerStats中作为状态保持。

跟进updateAllServerList(servers);去,一步步深入,会发现,实际上是保存到LoadBalancerStats中,并且这时候的服务是按照zone分组以HashMap<String, List<Server>>结构保存的,key是zone。

选择服务

实现了ILoadBalancer接口的负载均衡器,是通过实现chooseServer方法来进行服务的选择,选择后的服务做为目标请求服务。

看一下ZoneAwareLoadBalancer.chooseServer方法。

@Override
 public Server chooseServer(Object key) {
 if (!ENABLED.get() || getLoadBalancerStats().getAvailableZones().size() <= 1) {
 logger.debug("Zone aware logic disabled or there is only one zone");
 return super.chooseServer(key);
 }
 Server server = null;
 try {
 LoadBalancerStats lbStats = getLoadBalancerStats();
 Map<String, ZoneSnapshot> zoneSnapshot = ZoneAvoidanceRule.createSnapshot(lbStats);
 logger.debug("Zone snapshots: {}", zoneSnapshot);
 if (triggeringLoad == null) {
 triggeringLoad = DynamicPropertyFactory.getInstance().getDoubleProperty(
  "ZoneAwareNIWSDiscoveryLoadBalancer." + this.getName() + ".triggeringLoadPerServerThreshold", 0.2d);
 }

 if (triggeringBlackoutPercentage == null) {
 triggeringBlackoutPercentage = DynamicPropertyFactory.getInstance().getDoubleProperty(
  "ZoneAwareNIWSDiscoveryLoadBalancer." + this.getName() + ".avoidZoneWithBlackoutPercetage", 0.99999d);
 }
 Set<String> availableZones = ZoneAvoidanceRule.getAvailableZones(zoneSnapshot, triggeringLoad.get(), triggeringBlackoutPercentage.get());
 logger.debug("Available zones: {}", availableZones);
 if (availableZones != null && availableZones.size() < zoneSnapshot.keySet().size()) {
 String zone = ZoneAvoidanceRule.randomChooseZone(zoneSnapshot, availableZones);
 logger.debug("Zone chosen: {}", zone);
 if (zone != null) {
  BaseLoadBalancer zoneLoadBalancer = getLoadBalancer(zone);
  server = zoneLoadBalancer.chooseServer(key);
 }
 }
 } catch (Exception e) {
 logger.error("Error choosing server using zone aware logic for load balancer={}", name, e);
 }
 if (server != null) {
 return server;
 } else {
 logger.debug("Zone avoidance logic is not invoked.");
 return super.chooseServer(key);
 }
 }

注意这里有两种用法:

1.通过配置ZoneAwareNIWSDiscoveryLoadBalancer.enabled=false关闭区域感知负载均衡,或者zone的个数<=1个。

2.采用区域感知,或者zone的个数>1。

一个个来看一下

1.通过配置ZoneAwareNIWSDiscoveryLoadBalancer.enabled=false关闭区域感知负载均衡,或者zone的个数<=1个。

这种情况下,调用了父类BaseLoadBalancer.chooseServer方法。

public Server chooseServer(Object key) {
 if (counter == null) {
 counter = createCounter();
 }
 counter.increment();
 if (rule == null) {
 return null;
 } else {
 try {
 return rule.choose(key);
 } catch (Exception e) {
 logger.warn("LoadBalancer [{}]: Error choosing server for key {}", name, key, e);
 return null;
 }
 }
 }

这里使用的负载均衡策略rule实际上就是构造ZoneAwareLoadBalancer时传进来的,在配置阶段生成的ZoneAvoidanceRule策略实例。

public void setRule(IRule rule) {
 if (rule != null) {
 this.rule = rule;
 } else {
 /* default rule */
 this.rule = new RoundRobinRule();
 }
 if (this.rule.getLoadBalancer() != this) {
 this.rule.setLoadBalancer(this);
 }
 }

假设,如果没有配置,默认用的是RoundRobinRule策略实例。

2.采用区域感知,或者zone的个数>1。

public Server chooseServer(Object key) {
 if (!ENABLED.get() || getLoadBalancerStats().getAvailableZones().size() <= 1) {
 logger.debug("Zone aware logic disabled or there is only one zone");
 return super.chooseServer(key);
 }
 Server server = null;
 try {
 LoadBalancerStats lbStats = getLoadBalancerStats();
 Map<String, ZoneSnapshot> zoneSnapshot = ZoneAvoidanceRule.createSnapshot(lbStats);
 logger.debug("Zone snapshots: {}", zoneSnapshot);
 if (triggeringLoad == null) {
 triggeringLoad = DynamicPropertyFactory.getInstance().getDoubleProperty(
  "ZoneAwareNIWSDiscoveryLoadBalancer." + this.getName() + ".triggeringLoadPerServerThreshold", 0.2d);
 }

 if (triggeringBlackoutPercentage == null) {
 triggeringBlackoutPercentage = DynamicPropertyFactory.getInstance().getDoubleProperty(
  "ZoneAwareNIWSDiscoveryLoadBalancer." + this.getName() + ".avoidZoneWithBlackoutPercetage", 0.99999d);
 }
 Set<String> availableZones = ZoneAvoidanceRule.getAvailableZones(zoneSnapshot, triggeringLoad.get(), triggeringBlackoutPercentage.get());
 logger.debug("Available zones: {}", availableZones);
 if (availableZones != null && availableZones.size() < zoneSnapshot.keySet().size()) {
 String zone = ZoneAvoidanceRule.randomChooseZone(zoneSnapshot, availableZones);
 logger.debug("Zone chosen: {}", zone);
 if (zone != null) {
  BaseLoadBalancer zoneLoadBalancer = getLoadBalancer(zone);
  server = zoneLoadBalancer.chooseServer(key);
 }
 }
 } catch (Exception e) {
 logger.error("Error choosing server using zone aware logic for load balancer={}", name, e);
 }
 if (server != null) {
 return server;
 } else {
 logger.debug("Zone avoidance logic is not invoked.");
 return super.chooseServer(key);
 }
 }

在这种情况下默认使用ZoneAvoidanceRule负载均衡策略。

获取zone的snapshot信息。

获取可用的zone,通过观察ZoneAvoidanceRule.getAvailableZones定义,不是可用zone的条件是:

  • 所属实例数==0。
  • 故障率>0.99999或者平均负载<0。
  • 如果不是上面两种情况,就选择负载最高的一个去除不作为可用的zone。

可用zone都获取后,随机选一个。

并从该zone中,通过ZoneAwareLoadBalancer的父类BaseLoadBalancer.chooseServer选取服务,上面整理过,BaseLoadBalancer里如果没有传入rule,那么默认使用RoundRobinRule策略轮寻一个服务。

其实,还是上面获取服务中ZonePreferenceServerListFilter过滤器的问题,实际上过滤出来的只有一个和消费端相同的一个zone的服务,所以第2.部分的从可用zone中选取服务的功能是走不到,要走到就得把过滤器给换掉。

总结:

配置的负载均衡器会启动schedule获取服务信息,在使用了Eureka客户端时,会从Eureka服务获取所有服务实例信息,通过过滤器过滤出可以使用的服务,过滤器默认只过滤出与消费端相同zone的服务,如果要保证高可用可配置ZoneAffinityServerListFilter过滤器,过滤后的服务列表,通过实现了IRule接口的负载均衡策略选取对应的服务,如果是使用zone感知的策略,可以从负载情况良好的zone中选取合适的服务。

(0)

相关推荐

  • 采用软件负载均衡器实现web服务器集群(iis+nginx)

    我用nginx实现网站负载均衡测试的例子,windows下IIS做负载实测. 如果你的网站访问量(pv)越来越高,一台服务器已经没有办法承受流量压力,那就增多几台WEB服务器来做负载吧. 做网站负载可以买硬件设备来实现,我们公司用的是F5,不过价格就几十万到上百万,太贵了, 目前好多门户网站与大访问量的网站都在使用nginx做为HTTP服务器,所以nginx是非常优秀的,下面我亲手做这个负载测试吧. 软/硬件环境: (2台服务器) 第一台:  CPU:Inter(R) 酷睿 i5 CPU 2.2

  • linux服务器之LVS、Nginx和HAProxy负载均衡器对比总结

    LVS特点: 1.抗负载能力强,使用IP负载均衡技术,只做分发,所以LVS本身并没有多少流量产生: 2.稳定性.可靠性好,自身有完美的热备方案:(如:LVS+Keepalived) 3.应用范围比较广,可以对所有应用做负载均衡: 4.不支持正则处理,不能做动静分离. 常用四种算法: 1.rr:轮叫,轮流分配到后端服务器: 2.wrr:权重轮叫,根据后端服务器负载情况来分配: 3.lc:最小连接,分配已建立连接最少的服务器上: 4.wlc:权重最小连接,根据后端服务器处理能力来分配. 可以采用ip

  • 如何使用nginx充当mysql的负载均衡器

    说明:nginx版本要求是1.9以上 ,编译nginx的时候需要加上 --with-stream 如: ./configure --prefix=/Data/apps/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_realip_module --with-http_image_filter_module --with-stream 注意 1.因为mysql默认使用了3306端口所以配置nginx t

  • Spring Cloud 负载均衡器 Ribbon原理及实现

    Ribbon简介 分布式系统中,各个微服务会部署多个实例,如何将服务消费者均匀分摊到多个服务提供者实例上,就要使用到负载均衡器 Ribbon 是负载均衡器 ,它提供了很多负载均衡算法,例如轮询.随即等,在配置服务提供者地址后,可以将服务消费者请求均匀的分发 为服务消费者整合Ribbon 添加 Ribbon 依赖库 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spri

  • Spring Cloud Ribbon负载均衡器处理方法

    接下来撸一撸负载均衡器的内部,看看是如何获取服务实例,获取以后做了哪些处理,处理后又是如何选取服务实例的. 分成三个部分来撸: 配置 获取服务 选择服务 配置 在上一篇<撸一撸Spring Cloud Ribbon的原理>的配置部分可以看到默认的负载均衡器是ZoneAwareLoadBalancer. 看一看配置类. 位置: spring-cloud-netflix-core-1.3.5.RELEASE.jar org.springframework.cloud.netflix.ribbon

  • Spring Cloud Ribbon实现客户端负载均衡的方法

    简介 我们继续以之前博客的代码为基础,增加Ribbon组件来提供客户端负载均衡.负载均衡是实现高并发.高性能.可伸缩服务的重要组成部分,它可以把请求分散到一个集群中不同的服务器中,以减轻每个服务器的负担.客户端负载均衡是运行在客户端程序中的,如我们的web项目,然后通过获取集群的IP地址列表,随机选择一个server发送请求.相对于服务端负载均衡来说,它不需要消耗服务器的资源. 基础环境 JDK 1.8 Maven 3.3.9 IntelliJ 2018.1 Git:项目源码 更新配置 我们这次

  • 浅谈Spring Cloud Ribbon的原理

    Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将Netflix的中间层服务连接在一起.Ribbon客户端组件提供一系列完善的配置项如连接超时,重试等.简单的说,就是在配置文件中列出Load Balancer(简称LB)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随即连接等)去连接这些机器.我们也很容易使用Ribbon实现自定义的负载均衡算法. 说起负载均衡一般都会想到服务端的负载均衡,常用产品包括LBS硬件或云服务.Nginx等,都是

  • Spring Cloud Ribbon 中的 7 种负载均衡策略的实现方法

    目录 Ribbon介绍 负载均衡设置 7种负载均衡策略 1.轮询策略 2.权重策略 3.随机策略 4.最小连接数策略 5.重试策略 6.可用性敏感策略 7.区域敏感策略 项目源码 总结 负载均衡通器常有两种实现手段,一种是服务端负载均衡器,另一种是客户端负载均衡器,而我们今天的主角 Ribbon 就属于后者——客户端负载均衡器. 服务端负载均衡器的问题是,它提供了更强的流量控制权,但无法满足不同的消费者希望使用不同负载均衡策略的需求,而使用不同负载均衡策略的场景确实是存在的,所以客户端负载均衡就

  • Spring Cloud Ribbon配置详解

    本节我们主要介绍 Ribbon 的一些常用配置和配置 Ribbon 的两种方式. 常用配置 1. 禁用 Eureka 当我们在 RestTemplate 上添加 @LoadBalanced 注解后,就可以用服务名称来调用接口了,当有多个服务的时候,还能做负载均衡. 这是因为 Eureka 中的服务信息已经被拉取到了客户端本地,如果我们不想和 Eureka 集成,可以通过下面的配置方法将其禁用. # 禁用 Eureka ribbon.eureka.enabled=false 当我们禁用了 Eure

  • Spring Cloud Ribbon的使用原理解析

    目录 一.概述 1.Ribbon是什么 2.Ribbon能干什么 3.Ribbon现状 4.未来替代方案 5.架构说明 二.RestTemplate 用法详解 三.Ribbon核心组件IRule 四.实战项目 1.回顾之前的项目 2.@RibbonClient注解用法 3.配置文件用法 3.测试 五.Ribbon原理 1.负载均衡算法 2.源码分析 六.手写负载均衡器 一.概述 1.Ribbon是什么 Ribbon是Netflix发布的开源项目,Spring Cloud Ribbon是基于Net

  • Spring Cloud Ribbon实现客户端负载均衡的示例

    前面我们已经完成了注册中心和服务提供者两个基础组件.本文就介绍使用Spring Cloud Ribbon在客户端负载均衡的调用服务. 对于大型应用系统负载均衡(LB:Load Balancing)是首要被解决一个问题.在微服务之前LB方案主要是集中式负载均衡方案,在服务消费者和服务提供者之间又一个独立的LB,LB通常是专门的硬件,如F5,或者是基于软件的,如VS.HAproxy等.LB上有所有服务的地址映射表,当服务消费者调用某个目标服务时,它先向LB发起请求,由LB以某种策略(比如:Round

  • Spring Cloud Ribbon的踩坑记录与原理详析

    简介 Spring Cloud Ribbon 是一个基于Http和TCP的客服端负载均衡工具,它是基于Netflix Ribbon实现的.它不像服务注册中心.配置中心.API网关那样独立部署,但是它几乎存在于每个微服务的基础设施中.包括前面的提供的声明式服务调用也是基于该Ribbon实现的.理解Ribbon对于我们使用Spring Cloud来讲非常的重要,因为负载均衡是对系统的高可用.网络压力的缓解和处理能力扩容的重要手段之一.在上节的例子中,我们采用了声明式的方式来实现负载均衡.实际上,内部

  • spring cloud Ribbon用法及原理解析

    这篇文章主要介绍了spring cloud Ribbon用法及原理解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 简介 这篇文章主要介绍一下ribbon在程序中的基本使用,在这里是单独拿出来写用例测试的,实际生产一般是配置feign一起使用,更加方便开发.同时这里也通过源码来简单分析一下ribbon的基本实现原理. 基本使用 这里使用基于zookeeper注册中心+ribbon的方式实现一个简单的客户端负载均衡案例. 服务提供方 首先是一个

  • Spring Cloud Ribbon客户端详细介绍

    目录 前言 LB负载均衡(Load Balance)是什么 Ribbon核心组件IRule 前言 Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具.(负载均衡+RestTemplate调用) 简单的说,Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法和服务调用.Ribbon客户端组件提供一系列完善的配置项如连接超时,重试等.简单的说,就是在配置文件中列出Load Balancer(简称LB)后面所有的机器,

随机推荐