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.
Related
I am working on a distributed application project where there is need for rate limiting and authentication depending on the client consuming the service on an api gateway. I am wondering the best solution for designing the gateway.
Should I go with Spring cloud gateway or Spring Cloud function/AWS Lambda to create the gateway service?
I'd argue that using AWS API Gateway will make your life easier...
The benefits of using AWS API Gateway are:
it will remove all the operational cost of maintaining, configuring, monitoring and operating a Spring Cloud Gateway instance,
it will be highly available, with failover,
it will give you instant features like rate limiting, api keys, caching, authorization, canary testing, proxying, integration mapping, environments
it is very very cheap ($3.50 x MM requests).
The benefits of using Spring Cloud Function:
Define your API's as code within the application code itself
Leverage the ecosystem integration within Spring, for example, to run it locally on a dev's PC.
Cons of using API Gateway:
Deployment of new API's will be harder than using Spring Cloud Gateway (you need to configure each new resource/method)
Your costs are now tied to the number of requests... if you have a 900.000.000 millons/months API it could get expensive
Vendor lock-in
Cons of using Spring Cloud Function:
Operative cost of maintenance
Single point of failure
You can use Amazon API Gateway.
For more info on request throttling and quotas, please refer to the docs:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
I will rather use Istio gateway Envoy proxy rather than both options if permitted. Keeping my operational and maintenance cost little and no code change.
I'm implementing a microservices system with Spring Boot, and I want to have a service that using Rsocket to make real-time connecting between user and system. But in the document of Spring Cloud Gateway, that's seem not support Rsocket. Is this possible to using Rsocket in a microservices system with Spring Boot ? Or should I using websocket instead ?
Here is my idea
Don't try this, lost time. See authoritative article
https://spring.io/blog/2020/03/25/spring-tips-spring-cloud-loadbalancer
https://spring.io/guides/gs/spring-cloud-loadbalancer/
https://cloud.spring.io/spring-cloud-gateway/reference/html/#the-websocket-routing-filter
https://cloud.spring.io/spring-cloud-gateway/reference/html/#the-loadbalancerclient-filter
https://cloud.spring.io/spring-cloud-gateway/reference/html/#reactive-loadbalancer-client-filter
For load balancing with Spring Cloud Gateway, let use technology stack [Eureka Discovery Client + Cloud Loadbalancer + Reactive Web] or Ribbon (Netflix Open Source Software - Netflix OSS).
Rsocket for "... Reactive Streams", load balancing need something like request/response round robin, these are different.
I am writing a microservice app by spring boot and spring cloud. I have five modules which are
API-Gateway (base on spring cloud gateway spect)
Discovery-Server (base on spring cloud Netflix Eureka service discovery)
Microservice-A (It is a spring boot app that includes our business)
Microservice-B (It is a spring boot app that includes our business)
Microservice-C (It is a spring boot app that includes our business)
All requests which come from users route to API gateway and through API gateway send to app A or B or C (these are not exposed out). Now I have a question, base on one business role, app A will need to call one rest endpoint of app B. Which approach is the best? I call app B endpoint from app A directly or I call by API-Gateway?
The API Gateway should serve as an ingress layer, it only accepts traffic which is coming from outside of your application (clients / external integrations). More details here.
Any internal communication between your microservices, should be a point-to-point interaction, that can be done in multiple ways. This answer describes that in more details.
So the API Gateway should not be concerned with orchestration of the microservices.
If I were you I'll use a message broker for microservices communication. Let the api gateway for external clients. I think we overuse the http protocol. With a microservice architecture we should try to think differently.
I search to use spring boot, spring-cloud-gateway, netflix eureka.
Is there anything to do to have a load balancer and circuit breaker for micro-service instance?
I found few information ex ribbon when spring gateway is used instead of zuul.
Actually I have an application for the gateway, another for eureka, another for thymeleaf client
security is not yet choose, probabley jwt
With Spring Cloud Gateway, you can currently use the Hystrix Gateway Filter.
Consider using Hystrix. It is extremely good for microservices and aligns well with Spring cloud stack. Also, take a look at Feign, due to its simplistic approach to communication between microservices and integration with hystrix and ribbon.
The setup:
I have a set of Spring Boot based microservices that are fronted by Spring Cloud Gateway, meaning every request that comes from UI or external API client first comes to Spring Cloud Gateway and is then forwarded to appropriate microservice.
The routes are configured in Consul, and Spring Cloud Gateway communicates with Consul to get the routes accordingly.
Requirement:
There is a need of some microservices communicating with each other with REST APIs. I would prefer this communication to happen via the Spring Cloud Gateway as well. This will help in reducing multiple services going to Consul for getting other service's details.
This means every service should know Gateway's detail at least. And there can be multiple instances of Gateways as well. How is this dealt with in bigger architectures?
Any example that I look up contains one service using Consul, or Gateway using the consul with one microservice. Couldn't understand how to extrapolate that design to a bigger system.