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
Related
I am confused with Zuul role in Microservice architecture.
zuul acts as a proxy and loadbalancer for internal communication between the services where in lets say no authentication is required.
zuul acts as a Api gateway which can take care of Authentication and access control functionalities for the requests coming from UI or some other external clients.
So the same zuul instance can take care of both the objectives. How it is handled in best scenario possible.
i am novice in architecture side of microservices. please excuse me if it is a silly question.
Thanks in advance.
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?
I have a few synchronous microservices working on production using Spring Boot 2.X version. Soon, we need to implement a gateway if the number of instances of each microservice is going to be increased. I read that Zuul was in a maintenance phase and was replaced by Spring Cloud Gateway which is by default asynchronous technology. My question is, can I still implement Spring Cloud Gateway with my microservices?
Yes, you can use Spring Cloud Gateway without any doubts.
Basically, asynchronous technology means that your resources/threads on Api Gateway won't be blocked waiting for the response from downstream services and that increases a throughput.
Now, once your blocking services complete their internal logic they respond back to Api Gateway using an originally opened connection. Api Gateway in turn responds back to your client.
What I know so far is that:
Api gateway: Is fixed entry point that manage north/south communications.
Service Mesh: Is a side-car proxy that manage inter-service communication east/west.
service registry: Is a database of services, their instances and their locations.
All sound clear, but when I try to put all things together, I am confused:
Most of the service mesh/api gateway vendors say that they provide
access control mechanisms and other similar mechanisms, are these mechanisms an overlapping
functionalities between both concepts, or they have different scope
and goals?
Assume all Api gateway, Service Mesh and Service registry are deployed together:
Does the api gateway forward the request directly to the service, or
it communicate with service proxy?
Do I have to register a service twice, one in the gateway and one in
the service registry? or how to integrate the service registy with api gateway?
Finally Until now it seems for me the all concepts purely serve different purposes so they all necessary, but they overloaded with other functionalities. Is it possible to integrate them in meaningful way? or is there a reference architecture that I can follow?
Because no one posted an answer and based on my continuous reading, I was able to grasp a basic idea of how all components should work together, I will not answer directly to question, rather I will try to make things more clear:
API Gateway or Service Mesh are nothing just proxies, but with that said they are proxies of different types.
API Gateway is a front-proxy or edge-proxy, through it you communicate with the world. so in your architecture you may have an API Gateway running with or without Service Mesh beeing deployed.
To register your services in your Gateway you have two options(maybe more):
Static registration: using configuration file or using the Admin API of the API Gateway you are using, this is similar of how KONG work.
Dynamic registration: usually this is done by integrating your Front-proxy (API Gateway) with some other Service Registry/Discovery tool. you can accomplish that for example using Envoy and consul.io.
Using only Front-proxy (without service mesh) It is hard to do health monitoring, Logging and let all service know if it’s pointless to try to contact a down service(Circuit breaker).
Now, if you need to isolate your services from the topology of the network, or you need to provide a set of functionality around each of your services such as, mentoring, Logging, retries, circuit breaker..etc, then you can accomplish that by deploying a process (beside each service) that proxies all the out and in requests to your service. This process what we call a sidecar proxy. All the sidecars proxies usually run the same code, but they are configured differently.
Finally: The combination of the edge-proxy (API Gateway ) and the sidecar proxies forms what we call a Service Mesh. And obviously all proxies can utilize the same service registry/discovery mechanism.
For Example, I have two Rest Api services running
https://my-app-one.com/get
https://my-app-two.com/update
After Zuul API Gateway Implementation the requests will be routed to
Zuul Proxy:
Proxy 1 : https://zuul-api-gateway.com/get
Proxy 2 : https://zuul-api-gateway.com/update
Questions:
Can we implement Hystrix Dashboard at Zuul API gateway level?
Can we utilize all Hystrix commands if implemented at API gateway level?
What are the challenges and please provide documentation or examples.
I already have a working example of Hystrix Circuit Breaker and Hystrix Dashboard. All I want to know is if I can move Hystrix implementation at Zuul API gateway level.
#IMNash: Unfortunately, I cannot comment to your original question so I am afraid I have to ask you via an Answer. I am terribly sorry that I need to do that but I don't have enough reputation points yet.
Is it mandatory for you to go the Zuul way? If not, you might want to consider using Spring Cloud Gateway. The relevant post from Baeldung is an eye opener. See the below snippet:
//...route definition
.route(r -> r.path("/articles")
.filters(f -> f.hystrix("some-command"))
.uri("http://baeldung.com")
.id("hystrix_route")
I have tested this myself and yes, it's that easy to apply Hystrix.
The next step would be to configure the Hystrix filter as per your needs (e.g. timeouts, max semaphores, etc.).
I think we can only implement hystrix at individual rest service level. we can't implement hystrix at zuul routing level.