I'm exploring Istio's circuit breaker and wan't to setup fallback methods if the circuit trips.
I have a few Spring boot applications that are deployed on kubernetes and with Istio's circuit breaking defined in DestinationRule.
I can see that my caller application gets a 503 Service Unavailable exception when I intentionally bring down the called service.
I'm looking for design patterns or libraries with which I can define fallback methods for my rest calls,
something similar to #HystrixCommand.
I checked out spring-cloud-circuitBreaker but that doesn't support Istio.
I have also explored ClientHttpRequestInterceptor with Spring RestTemplate, and can catch all ServiceUnavailable exceptions, but I need a way to configure different fallback methods to different REST calls.
Any suggestion is appreciated.
Related
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
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.
I get that Feign is declarative and hence it abstracts out a lot of things for the developer. But, when should one choose one over the other? Though feign is declarative, it has serious problems with oAuth. What are some of the considerations in using RestTemplate over Feign
Feign allows you to abstract the mechanics of calling a REST service. Once you configure and annotate the Feign interface, you can call a REST service by making a simple Java function call. The actual implementation of making a REST call is handled at runtime by Feign. This means that the implementation can be configured without changing your business logic code.
By just changing the Feign configuration in Java or using properties you can add encoding/decoding, logging, and change the REST call implementation library. All this is done through configuration only, while the business logic that calls the service remains unchanged.
Since Feign uses standard Java interfaces, it's also easy to mock them during unit tests.
There are certain advantages.
1.URLs are not hardcoded.
2.you don't have to write unit test cases for feign as there is no code to test however you have to write integration tests.
3.we can use Eureka Client ID instead of the URL.
4.Feign handled the actual code.
5.Feign integrates with Ribbon and Eureka Automatically.
6.Feign provides a very easy way to call RESTful services.
One of the advantages of using Feign over RestTemplate is that, we do not need to write any implementation to call the other services. So there is no
need to write any unit test as there is no code to test in the first place. However, it is advised that we write Integration tests.
Using Feign-clients over rest-templates has number of advantages. I will list down those below.
The developer need not worry about the implementation. Just to create abstract Feign interface and few annotations - declarative
principle. (If you want customized configuration, then it will hold
some code)
With Spring Cloud Eureka, Ribbon client-side load-balancer will be equipped with Feign client.
No need to worry about the unit test, because there is no implementation from you to test. (Arguable)
Supports Feign annotations and JAX-RS annotations.
Highly compatible and easily configurable with Spring Cloud (Specially with Eureka server registry)
Allows Feign client configuration via #Configuration class or application properties.
Allows us to add interceptors. (Add interceptors via #Configuration or application properties. Alternatively can use
Spring Cloud provided interceptors as well. Example -
BasicAuthRequestInterceptor)
Hystrix support for fall-back mechanism.
Logging
Error handling
Feign is a good choice, If you are fascinated with JPA and the way how it resolves your queries, then Feign is the tool for you. Feign will handle your server requests perfectly fine.
RestTemplate is used for making the synchronous call. When using RestTemplate, the URL parameter is constructed programmatically, and data is sent across to the other service. In more complex scenarios, we will have to get to the details of the HTTP APIs provided by RestTemplate or even to APIs at a much lower level.
Feign is a Spring Cloud Netflix library for providing a higher level of abstraction over REST-based service calls. Spring Cloud Feign works on a declarative principle. When using Feign, we write declarative REST service interfaces at the client, and use those interfaces to program the client. The developer need not worry about the implementation ...
Advantages of using Feign over RestTemplate:
Declarative approach: Feign provides a more declarative approach to define and use REST API clients, which can make the code more readable and easier to maintain.
Integrated with Eureka: Feign is integrated with Netflix Eureka for service discovery, making it easier to build and consume APIs in a microservices architecture.
Better error handling: Feign provides better error handling, including support for custom error handling and retries.
Support for multiple encodings: Feign supports multiple encoding types, including JSON, XML, and form data, while RestTemplate only supports JSON and XML.
Disadvantages of using Feign over RestTemplate:
Limited flexibility: Feign provides a more opinionated approach to defining and using REST API clients, which may limit flexibility in certain situations.
Limited control over HTTP request and response: Feign abstracts away some of the low-level details of the HTTP request and response, which can make it harder to control and customize these details if needed.
Lack of official support: Feign is not an officially supported library from Spring, which may be a consideration for some developers or organizations.
What is the best way to add a Circuit Breaker pattern in a Microservices Architecture. Should it be on the microservice side (inside each microservice), inside an ELB or insider the Api Gateway? What would be the best design pattern?
I think is not use in each microservice, but in your BFF (backend for frontend) who use microservice. You can find a good implementation and exemple in this book https://pragprog.com/book/mnee/release-it. Solution with API Gateway is good, see Kong https://getkong.org/ for that.
There are at least 3 options (illustrated below). In the general case, the circuit breaker "protects" calls to an http service. If we think this service is the microservice, the circuit breaker is never in the microservice itself.
API Gateway
In this case, you use an API gateway product that has circuit breaking support. Ambassador and Axway are examples. An alternative would be to provide circuit breaking in a BFF service that gets the calls to your backend service.
Service mesh
In this case, you use a service mesh product that has support for circuit breaking. Istio with Envoy are an example. In this example, the insurance quote service calls the customer history service. The proxy sidecar container does the circuit breaking.
Circuit breaker lib
Here you use a library that provides circuit breaker support. Resilience4J is the one we use at work (in some Spring Boot apps that call http services).
Your design
Which is best? It depends on your application requirements and infrastructure constraints. Things to remember:
Not all service interactions require circuit breaking.
See if a fallback mechanism (e.g., default response) can be used when the circuit is open.
Log/monitor circuit changes to detect problematic connections and services.
I would suggest you to delegate the circuit breaking concerns to a external library like Hystrix , rather than implementing it yourself.
Hystrix exposes a lot of properties that give you full control in tuning the circuit breaking capabilities.
We have developed a software proxy based on spring boot and zuul, that is meant to govern services within our integration layer. We do not own the systems consuming the various services, nor do we own the actual services themselves. The services are SOAP based webservices at present. We make use of pre, post , error and route filters. Validations are database driven, including which client is allowed to call what webservice. All service definitions reside in the database (request endpoint, request xsd, response xsd, which clients are allowed to invoke, etc.).
The aim now is to add hystrix commands to handle service failures, as well as a hystrix dashboard.
The standard way to use hystrix commands involves annotating service methods with javanica. Is there a way to dynamically declare/register hystrix commands for these webservices at runtime after reading the configurations from the database? The hystrix interception will need to happen based on the multiple webservice endpoints being invoked from a single point.
Hoping this is achievable ...if not, I would really appreciate any alternative proposals for how hystrix commands could be declared in this way.
Thanks!
You're saying that you are already using Spring Boot and Zuul. How are you mapping the routes? Through the url param? Then you'll have to enroll your own. But if you define the routes as ribbon services and pass the routes as ribbon servers as described in the documentation you will get Hystrix for free.