My Spring Boot application uses a REST endpoint.
This endpoint returns a HTTP 429 (too many requests) at high load.
What is the best way to handle it?
Does Spring Boot offer possibilities here?
It depends on which version of spring you use.
If you use reactive streams (e.g. webFlux framework) then you can use backpressure mechanism.
If not, you can use for example resilience4j ratelimiter and bulkhead mechanism.
Related
In your opinion, in a hybrid architecture (WEBSOCKET + HTTP) is it good practice to use 2 gateways: Zuul for HTTP communication and Spring Cloud Gateway for WEBSOCKET communication in a Spring Boot application? Alternatively, in this scenario is it recommended to use only Spring Cloud Gateway?
Thanks.
is it recommended to use only Spring Cloud Gateway Yes because
Spring Cloud does not provide any out of the box integration with Zuul2. Gateway has many features that are not available in the public version of Zuul2 such as Rate limiting, etc. Also, with the gateway you can have custom filters defined per route and there are tons of built-in filters defined as well, which helps a lot to get started. Reference
Reference: I think SCG is the way to go due to the agreements between Netflix and Pivotal, with the former leaning more toward the spring boot/cloud ecosystem as stated in https://medium.com/netflix-techblog/netflix-oss-and-spring-boot-coming-full-circle-4855947713a0
In a Spring Boot (2.2.2.RELEASE) application, I have reactive endpoints (returning Mono or Flux), each of them is using reactive WebClient for calling another service. This "other" service is legacy (non-reactive) one.
Here is my question:
Is there a benefit of using Webflux (reactive WebClient) if my reactive endpoint is calling this non-reactive endpoint which does blocking stuff?
Is my reactive endpoint still reactive?
If we're talking about HTTP endpoints, we can call them with blocking or non-blocking (asynchronous) clients, but not fully reactive.
If your "new" application is reactive, you have to use non-blocking client (WebClient in your case), otherwise you will block NIO-threads and loose all the advantages of the reactive approach. The fact that the “other” application is blocking doesn't matter, you can still get a less resource-intensive "new" application.
They are
1. Not fully.
2. Your request is not full reactive until you change legacy APIs
Explanation:
End-to-End Reactive pattern only help into to the performance side
Currently you’re using reactive client this helps to connect to server in two way communication.
First set of APIs are reactive so web server layer is now reactive but data layer (Legacy APIs ) not reactive
I am building a microservice using spring webflux and netty. Internally I use web client to make rest api calls. How can I control rate at which I can call rest api via webclient? I guess backnpressure is only for a single request/reply and does not work across multiple request to my microservice. Amy pointers will be appreciated.Thanks.
Resilience4j has support for non-blocking rate limiting with Reactor.
See: https://resilience4j.readme.io/docs/examples-1#decorate-mono-or-flux-with-a-ratelimiter
I have a written a microservice using Spring 5 WebFlux and trying to consume a non-reactive REST API through it. Is it possbile to consume a non-reactive service using a reactive webclient?
Yes, this is possible. From the server's point of view, this is just a regular HTTP client. WebClient does support streaming and backpressure, but this doesn't change things at the HTTP level.
The backpressure is dealt with at the TCP flow-control level, so the HTTP protocol stays the same.
While using Spring 5 reactive webflux with Spring boot 2.0, what's the default number of threads used to handle requests? How can I configure the number of threads used?
The default number of threads for request handling is determined by the underlying web server; by default, Spring Boot 2.0 is using Reactor Netty, which is using Netty's defaults (check out the EventLoopGroup documentation for that).
Spring Boot will soon allow you to customize that part (see #10418). In the meantime, you can provide your own ReactiveWebServerFactory bean and change that through the HttpServer configuration options (see this comment).
Currently, it seems that Spring Webflux 2.0 does not provide the ability to control threads.
Spring Webflux 2.0 is using Reactor-Netty. And ReactorNettyclass provides some configurations.
reactor.netty.ioWorkerCount
reactor.netty.ioSelectCount
reactor.netty.pool.maxConnections
etc
So, You can use it like this.
System.setProperty("reactor.netty.ioWorkerCount", "100");
I hope that Spring Boot will provide a custom configuration.