CODEWITHSUNDEEP
spring-cloudmicroservicesnetflix-eurekanetflix-zuulcanary-deployment
Ryan J. McDonough
Ryan J. McDonough

Reputation: 1725

Spring Cloud: Canary Deployments with Zuul

I am getting started with Spring Cloud using Eureka and Zuul and had some questions around structuring blue/green and Canary deployments. So far, I have the basics worked out and have Eureka, Zuul, and a config server working as expected. What I am trying to accomplish is set up a service that has two versions, say 1.0 and a 1.1. For a subset of specific users, I want to route them to the 1.1 version and everyone else should go to the 1.0 version.

The Zuul filter API is a little light on documentation and I'm struggling a bit to grok some of the concepts, so I thought I'd ask a few questions here. I have also have some basic filters running, which don't do a whole lot a the moment other than getting the identity of the principal and the service they are requesting. Where I am hitting a wall is understanding how to expose two different versions of the same service to Eureka and Zuul. A few things I'm curious about:

Upvotes: 17

Views: 4075

Answers (1)

moxn
moxn

Reputation: 1800

Assuming you are using Ribbon as well, I would leave the service IDs as they are. Instead I would take a look at the com.netflix.loadbalancer package. Canary deployments are essentially load balancing with very specific constraints. You could implement your own AbstractLoadBalancerRule that picks servers based on some property you would like to base the routing on. Then add that rule to the configuration of your Zuul instance.

@Configuration
public class CanaryConfiguration {
    @Bean public IRule canaryDeploymentRule(IClientConfig config) {
      CanaryDeploymentRule rule = new CanaryDeploymentRule ();
      rule.initWithNiwsConfig(config);
      return rule;
    }
}

If you let your services register themselves in Eureka with different service IDs ("simpleservice" and "simpleservice-x.y"), I suppose things are bound to become complicated. You would have to extend the discovery client to ignore the version part ("-x.y", while still being able to deal with "foo-service") when retrieving the list of available servers from Eureka and then do some selection process to pick the right one anyway. So I guess things would just become more complex.

This is all based on best guesses, I haven't actually implemented this. I realize that this question is almost 4 months old. So if you have found some other solution in the meantime, it would be great if you could share it in an answer to your own question.

Upvotes: 7

Related Questions