I am trying to design/POC on high availability architecture using spring cloud gateway and eureka. on local machine my entire setup is working fine with two eureka, two api gateway & two microservices nodes. Also we have created two AWS load balancer for two eureka & api gateway instances respectively. Entire setup is working fine on local machine but the whole setup is not working when we deploy same on UNIX environment.
Basically we have deployed each instance of eureka, api gateway & microservice on X & Y unix servers. and if we do request from gateway load balancer on unix server then its blocking and throwing 500 on web console.
Note - We have peered connection between two eureka instances. for more info https://medium.com/swlh/spring-cloud-high-availability-for-eureka-b5b7abcefb32
I'm adding microservice architecture screenshot for more understanding. we have to achieve high availability if in case any service is down from both the servers then application would be accessible any time.
Related
I have a eureka server running on test server and multiple services registers from test server to this eureka server.
Now problem is sometimes developers also connect their local microservice instance for some service to eureka. Due to this it shows multiple instances for that service on eureka and load balancer starts sending request to local servers as well from feign client. That causes issues in testing as test server is not able to connect local developers machine in feign client calls.
I instructed developers to set eureka.client.register-with-eureka=false from local but still if someone connects how can I stop that. Is there a way that eureka server registers only from specific IP (test server ip)? Or any other solution to prevent this problem?
For the services that you don;t want them to register, remove #EnableDiscoveryClient from the services. #EnableDiscoveryClien lives in spring-cloud-commons and picks the implementation on the classpath. This will stop your services from getting discovered but then you won;t be able to make the Feign calls to other services and take the benefit of load balancing your calls.
I am currenly learning microservices. I have two services Service A and Service B. Service A registered with Eureka server. Service B is calling Service B via Eureka server to get the response. My question is
why Service B has to register with Eureka service in order to call Service A?
Service B can get the Service A url and portno through service discovery from Eureka server. What is the significance of Service B to register with Eureka server?
Typically in Microservices architecture, we have a lot of small applications running independently together, and ofcourse they will all have their own URLs and ports.
In that scenario, it would be very cumbersome to maintain all these microservices to run in synchronization, and more importantly, with monitoring. This problem will increase manifold when we start implementing load balancers.
To solve this issue, we need a tool that will monitor and maintain the registry of all the microservices in the ecosystem.
That's why Eureka server acts as directory and service discovery system to make sure they is no direct binding between services and it make sure to have health check for those services.
I am using the ECS Fargate launch type.
I am deploying Spring based microservices.
Every service registers itself to AWS CloudMap.
Now I am trying to communicate between two microservices using the RestTemplate.
I call the services by their DNS endpoint (e.g.: auth.mynamespace.local:8080/login). I get a 404 response every time. The security groups around the microservices are transparent on port 8080 for the corresponding inbound group.
One note: Everything is private. I don't associate a public IP and also the CloudMap namespace (R53 hosted zone) is a private one.
I really can't get behind why I am getting all those 404 errors with my RestTemplate.postForEntity(...).
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.
i have created two java spring-boot micro services they are
1) producer
2) consumer
and i have used spring eureka server for service registration and discovery . it worked fine . then what is the use of Netflix Zuul.
Let's suppose you have 20 services to which user can interact to, and of course we are not going to expose each and every services publicly because that will be madness (because all services will have different ports and context), so the best approach will be to use an API gateway which will act as single entry point access to our application (developed in micro service pattern) and that is where Zuul comes into picture. Zuul act as a reverse proxy to all your micro-services running behind it and is capable of following
Authentication
Dynamic Routing
Service Migration
Load Shedding
Security
Static Response handling
Active/Active traffic management
You can go through documentation here
If you have enough experience in the domain, you could look at zuul as an API gateway like Apigee. It is very feature rich and touches up on a lot of different concerns like routing, monitoring and most importantly, security. And eureka as a service discovery platform that allows you to load balance (in Linux terms the nginx or haproxy) and fail over between your service instances.
Typically the backend services that perform the server side business operations (i.e. core) are not exposed publicly due to many reasons. They are shielded by some Gateway layer that also serves as reverse-proxy. Netflix Zuul serves as this gateway layer which easily gives you the capabilities as mentioned by #Apollo and here