I am trying to figure out entries required in zuul(version 1.3.0) configuration to support multiple versions of same api. Example Service 'A' has multiple versions viz v1, v2 and v3 each of the services are running using different spring profiles on different ports. Service name is same and not different for different api versions. Service 'A' is registered in eureka server and all instances are listed in eureka registry.
How can zuul application.yml be configured to support routing and load balancing request to v1, v2 and v3 versions of apis.
What will be approach in case Service 'B' which also has v1,v2 and v3 versions wants to call v1,v2 and v3 of Service 'A' through eureka registry.
Related
I am going to create a kubernetes cluster to deploy all my spring boot microservices. Currently I have a spring cloud gateway server, a eureka discovery server and my back-end and front-end applications.
Do we need gateway server and discovery server if deployed on kubernetes, as these services are provided as part of cluster?
Thanks.
You are not required to use the Spring Cloud Gateway or Eureka discovery server. Kubernetes provides all basic building blocks (like Service) implemented without additional software requirements (for example with plain DNS).
If you need a more advanced setup you can integrate kubernetes API in Spring applications or use other ways to integrate. For the 90% case there is no need to do so.
What are the benefits to use "spring service discovery kubernetes" instead of using directly the Service DNS coming from Kubernetes?
I mean, If I deploy in kubernetes 2 services (service-a and service-b), and service-b exposes a Rest API.
service-a can easily connect to service-b using the url "http://service-b/...".
Question #1. In order to let service-a be able to connect to service-b using the service DNS, service-b has to be deployed before service-a?
Question #2. What are the pros/cons using the spring discovery?
Question #1:
No, the order in which you deploy the services is not important to use the kubernetes DNS services to resolve the ips, the only thing here is that if you deploy serviceA after serviceB, you will have in serviceA as an environment variable the ip of serviceB but not the inverse.
Question #2:
The spring service discovery is an alternative to the native kubernetes service discovery and it is used by other spring cloud projects like spring-cloud-eureka to perform the service discovery. The only pros I see in this approach is that you can custom the load balancing algorithm tath you can use to spread the load among the different instances
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.
Does Netflix Eureka support non-RESTful endpoints? We have a requirement where clients should be able to discover the AMQP based endpoints provided by RabbitMQ.
It seems main competitors to Eureka such as Consul and Zookeeper are essentially key-value stores and you can store anything in the value.
We have created our application with Spring-Cloud Eureka and Spring-Cloud Zuul with multiple core / support micro services registering to Eureka and accessed via Zuul, everything works fine.
We wanted to collect metrics of the APIs that is accessed via ZUUL.
For example, API - ".../extract" need to know how many times its accessed in 5,15 and 60min time period.
We did some analysis and found various metrics library like Netflix Servo, Dropwiard Metrics, Spring Boot Actuator. Everything points to implementation at the service or API level. We wanted our metrics to be captured at ZUUL itself so that a simple counter is implemented in ZUUL and that would provide us the required metrics. Any suggestion in how to implement this would be helpful.