Skip to content

LoadBalancer: add an ability to supply custom load-balancer strategy into context #730

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Fetsivalen opened this issue Apr 13, 2020 · 7 comments

Comments

@Fetsivalen
Copy link

Is your feature request related to a problem? Please describe.
It can be useful in a few cases:

  • some load-balancer strategies not implemented yet
  • some case-specific logic needs to have custom ReactorServiceInstanceLoadBalancer.

In this case, would be great to have an ability to supply custom login via bean in context and allow to enable it for the specific client via configuration properties.

For example in SCG the I have a lot of routes and want to supply a custom load-balanced algorithm (let it be sticky in this case) and keep default round-robin for others.

As a can see for not I have to add

@LoadBalancerClients(defaultConfiguration = MyCustomLoadbalanserConfiguration.class)

And Implement custom configuration with factory methods.

Describe the solution you'd like
It would be cool to have smth like:

    @Bean
    @Primary
    public ReactorServiceInstanceLoadBalancer loadBalancerStrategy(List<ReactorServiceInstanceLoadBalancer> availableLoadBalancers,
                                                                   Environment environment,
                                                                   LoadBalancerClientFactory loadBalancerClientFactory) {
        String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
         String loadnalancerStrategyOption = environment.getProperty(LoadBalancerClientFactory.NAMESPACE + "." + name + ".strategy");
        ReactorServiceInstanceLoadBalancer loadBalancerStrategy = availableLoadBalancers.stream()
                .filter(strategy -> strategy.getLoadbalancerStrategyName().equals(loadnalancerStrategyOption))
                .findFirst()
                .orElseGet(() -> new RoundRobinLoadBalancer());
        // setters based binding seems ok in the case since instance supplier and serviceId are defined during child context creation
loadBalancerStrategy.setServiceInstanceListProvider(loadBalancerClientFactory.getLazyProvider(name,
                ServiceInstanceListSupplier.class));
        loadBalancerStrategy.setInstanceId(loadBalancerStrategy);
        return loadBalancerStrategy;
    }

and place it in LoadBalancerClientConfiguration

It will allow using properties to define a load-balanced strategy and supply an additional one via the context.
Of course, the implementation should be a little bit different to address backward-compatibility but I think the one supplied here is enough to illustrate intention.

Describe alternatives you've considered
There are definitely a lot of other ways to implement a "factory".

@spencergibb
Copy link
Member

Our current discussion is in #672

@Fetsivalen
Copy link
Author

as far as I understand from that thread it is more about how to choose implementation based on the request, while my proposal was about how to choose the load-balancer algorithm during context creation.
But it seems I need to wait until that ticket will be resolved.

@OlgaMaciaszek
Copy link
Collaborator

Also related to: #660.

@OlgaMaciaszek
Copy link
Collaborator

Reopening, so we can include it in team discussion.

@OlgaMaciaszek
Copy link
Collaborator

Since the same result can be obtained by adding the default configuration, we don't think there's a need for a different solution for the same use-case.

@spring-projects-issues
Copy link

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@Fetsivalen
Copy link
Author

Ok, thanks for info, closing this issue ticket than

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants