I have an EDG service which is a gateway in front of some services,
those services were reached by feign client so all requests come to edge and it's controllers will forward the request to back end service using fegin client.
I thought that's bad so I wanted to change this by fully using Zuul integration, that will automatically do the routing to the backend services , load balancing ...etc
The problem is: handing zuul filters to do centralized logging is not so cool vs fegin client which is just a call and I can make global Exception handler to handle exceptions ...etc
so what is the correct way of implementing the Edge layer?
Related
Currently I am working on spring microservices. It has zuul proxy and eureka server registry.
All the web API calls are being handled by zuul proxy.
Now I want to design a light weight mobile app, where the API call request body dont match. So, Decided to have one more gateway for mobile. What is the best approach to design this?
From mobile gateway, is it worth calling zuul proxy with modified request body which then calls the microservices?
Or the mobile gateway calls the microservices through RestAPIs ?
where mobile gateway and zuul proxy service will be running independently
I'm beginer to micro-services, so please help me out on this issue,
I'm working on simple micro service project with spring boot, zuul, hystrix and eureka. One of service calls data from another service. But when the service is down, response is 500, so it needs to be send request again to get the expected result.
But end user shouldn't it see. So is there a way to send a http request for the failed service again with zuul if the previous request is failed/short circuited.
Thanks in advance.
First for an unavailable service http code 503 is probably more suitable.
Then Zuul is an api gateway not a service mesh. I think you mix up both concepts here.
The goal of an api gateway is to accept traffic from outside your network and distributes it internally...and so abstract his complexity(it is actually a distributed facade/router).
Example: zuul, spring cloud gateway
A Service mesh acts as a proxy between microservices and bring on communications aspects like automatic retries, circuit breaker, tracing, logging.
Example Istio, Linkerd
But you can go without service mesh to implement this concern. Your caller microservice can protect itself by implementing timeout, retries and circuit breakers by embed a powerful library like resilience4j.(hystrix is actually at the end of his life)
This library will provide you an api allowing you to wrap communications with outside (other microservices) through a special proxy that will handle retries or/and circuit breakers for you.
You should have a look : https://github.com/resilience4j/resilience4
i have created two java spring-boot micro services they are
1) producer
2) consumer
and i have used spring eureka server for service registration and discovery . it worked fine . then what is the use of Netflix Zuul.
Let's suppose you have 20 services to which user can interact to, and of course we are not going to expose each and every services publicly because that will be madness (because all services will have different ports and context), so the best approach will be to use an API gateway which will act as single entry point access to our application (developed in micro service pattern) and that is where Zuul comes into picture. Zuul act as a reverse proxy to all your micro-services running behind it and is capable of following
Authentication
Dynamic Routing
Service Migration
Load Shedding
Security
Static Response handling
Active/Active traffic management
You can go through documentation here
If you have enough experience in the domain, you could look at zuul as an API gateway like Apigee. It is very feature rich and touches up on a lot of different concerns like routing, monitoring and most importantly, security. And eureka as a service discovery platform that allows you to load balance (in Linux terms the nginx or haproxy) and fail over between your service instances.
Typically the backend services that perform the server side business operations (i.e. core) are not exposed publicly due to many reasons. They are shielded by some Gateway layer that also serves as reverse-proxy. Netflix Zuul serves as this gateway layer which easily gives you the capabilities as mentioned by #Apollo and here
Suppose there are 2 backend services:
A product service (to get the product info),
An inventory service (to get the available quantity).
Additionally to that, there is a frontend web application to display product details.
All the examples I see on the internet are about the frontend and the API gateway being the same application and using Zuul just as a reverse proxy.
My understanding is API gateway should be a separate application (layer) and frontend application should use it to call backend services.
In that case what is the benefits of Zuul? why not just use feign to create a client for both services and provide an endpoint for the frontend application ?
Feign client and Zuul are two entirely different components in Spring Cloud Netflix.
Feign Client is a glorified REST Template with additions such as Retry, Fallbacks etc. You can think along the lines of Apache HttpClient
Zuul on the other hand is a proxy / reverse - proxy / gateway. Typically Gateway should be a common entry point to your backend services. It should be a separate layer which allows you to add common functionalities like Authentication, Auditing, Logging etc. As #ootero mentioned, you can easily add Filters in Zuul to achieve this functionality.
Zuul as a Proxy server not only route requests but Zuul filters could also be used for handling crosscutting concerns like:
geolocation
token decryption
authentication
request / response manipulation
Traffic shaping
You mention Feign clients and that would work (to the best of my knowledge) with Java-based front-end apps, what if the front-end app is developed with Angular or React?
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?
Let's say i have few micro services running and all of them along with ZUUL are registered to Eureka.
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.
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..
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).