When to configure zuul routes

Question

I am new to spring cloud and going through some examples and material available online to make myself comfortable. However, while reading about ZUUL, some sites configured the routes in ZUUL's application.yml and some other sites mentioned that the requests will be forwarded to the respective microservice and no need to explicitly configure the routes. I was bit confused. For ex, in the below scenario what is the approach, to configure routes or to let zuul route automatically?

1. Let's say i have few micro services running and all of them along with ZUUL are registered to Eureka.
2. I have a front end which is running on a different port on the same server and needs to interact with the above micro services.
3. I also have few other applications (Running entirely on different servers) which need to interact with the above micro services for fetching the data.

TIA..

Solution

Did you use Zuul (which know microservices address through Eureka) to forward request between your micro-services ? if it's the case, you are using Server-Side Load Balancing pattern.

If you use a discovery service (Eureka in your case), i think the best approach it's to use Client-Side load balancing pattern for all inter-services requests (inside your system). (you can use Ribbon or RestTemplate for that).

You can use Zuul as a unified front door to your system, which allows a browser, mobile app or other user interface to consume services from multiple hosts without managing cross-origin resource sharing (CORS) and authentication for each one.

For example : a client (mobile app) request for all picture comments. The client dont need to know the Comments-service address. Only proxy address needed and Zuul will forward the request to the right service. You can do this in application.yml/.properties by

zuul.routes.comments.path=/comments/**
zuul.routes.comments.service-id=comments

The request will be GET www.myproxy.mycompany.com/comments. Dont forget the service name in your application.yml/.properties is very important (spring.application.name). It's the service-id in Zuul routes (which the same identifier in Eureka).

For some reason, your system need to request external services (as you mentionned in the 3th note). In this case, your external services are not a discovery client, Zuul can't look for the service-id from Eureka. you use routes as

zuul.routes.currencyprovider.path=/currencies/**
zuul.routes.currencyprovider.url=https://currencies.net/

with this route, all /currencies/** requests from your services THROUGH Zuul will be done. with this approach you have one door for all your system. This is API Gateway pattern.

Sometimes your system need to aggregate multiple results from different services to response to client request. You can do this in Proxy (Zuul in your case).

Comments

[Harish]

Hi redoff, Thanks for the response. it has more info than i required :). I have another question. if i am using the discovery service (client-side load balancing), is there any advantage of letting zuul route the requests based on service name Vs explicitly configuring the paths?

[redoff]

when you use discovery service you are not implicitly use a client-side load balancing. it's the communication approach between your services which define if it's server-side or client-side LB. The advantage of using configured paths it's you can limit access for only specified services with routes (configured paths) IF ONLY you add the zuul.ignored-services=*.

[redoff]

example : you have 3 services (comments, users, metrics). You want to limit access THROUGH proxy to 1 service (e.g comments-service). you process as : zuul.ignored-services=* and zuul.routes.comments.path=/comments/** zuul.routes.comments.service-id=comments. With this properties lines, all requests THROUGH proxy will be rejected except www.myproxy.mycompany.com/comments

[redoff]

other advantage of routes (configured paths), it's to simplify routes. e.g zuul.routes.comments.path=/comms/** zuul.routes.comments.service-id=comments. When you use configured paths where Zuul exposes the service based solely on the Eureka service-id, if there are no instances of the service running then Zuul will not expose the route for the service. However, if you manually map a route to a service discovery ID and there are no instances registered with Eureka, Zuul will still show the route. If you try to call the route for the non-existent service, Zuul will return a 500 error.