Deployment Context Based Vip Address in Spring Cloud Load Balancer

[xenobc]

We are looking to of move to Spring Cloud Load Balancer to replace Ribbon. We use Eureka for service discovery and registration.

It looks like as of Spring Cloud Netflix 3.x, the EurekaRibbonClientConfiguration in the Eureka client module has been removed.

We were using the deploymentContextBasedVipAddress configuration to map our internal host name to a registered vip address in Eureka.

The configuration was similar to this:

some-sevice-v1.ribbon.NIWSServerListClassName=com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
some-sevice-v1.ribbon.DeploymentContextBasedVipAddresses=some_service-v1
some-sevice-v1.ribbon.NIWSServerListFilterClassName=com.netflix.loadbalancer.ServerListSubsetFilter

We do this because the vip address that is registered with Eureka contains an _ in it and which is technically an invalid character for host names; the Java URI class will fail to parse a host with a _ in it. I am not by any means saying this a good approach, but we are not able to change this at this point. This could be useful in other situations as well.

So my question is; can this similar configuration be done with Spring Cloud Load Balancer and the new Eureka client module in Spring Cloud Netflix 3.x, where we can provide aliasing for the vip address? If not, will this be supported in the future?

[OlgaMaciaszek]

@xenobc Thanks for submitting the issue. I'm thinking we could solve it by allowing instantiating mapping functions to be called within the DiscoveryClientServiceInstanceListSupplier, but we'll discuss this with the team first and then get back to you.

[OlgaMaciaszek]

@xenobc We'll wait for more votes for this issue. As a workaround, we suggest you create and instantiate your own ServiceInstanceListSupplier that will wrap DiscoveryClientServiceInstanceListSupplier.

[mrozk]

Hi! We are also migrating on spring cloud loadbalancer and facing this problem. We have several versions of clients for one service and we used different client names for these in order to split configurations per client. Also, we have different feign clients for admin API and internal API and we have a different name for an admin feign client.

For example, we have

@FeignClient( value = "magic-service-v1", ) public interface MagicServiceV1Client

@FeignClient( value = "magic-service-v3", ) public interface MagicServiceV3Client

After that we add the configuration magic-service-v3.ribbon.DeploymentContextBasedVipAddresses=magic-service

@OlgaMaciaszek, I think that many developers will face such problems in the future, it would be great to have the ability to map client name to service in the loadbalancer in order to allow migrate existing services to the new libraries.