• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Eureka service discovery  RSS feed

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all, I'm approaching to the study of Spring Eureka Server relatively to a microservices architecture.

Basically, as far I understood, the main purpose of Eureka is to discover each registered microservice's address that meanwhile pings the Eureka server to notify it that is available.

So, I was reading some articles about it, trying to understand why we need a service discovery in our architecture, and I faced some doubts about the service scaling process:

Nowadays, on a cloud platform, it is obvious that all the servers or containers use dynamic IPs for autoscaling. And the interesting thing is that in microservice architecture, the key principle is that your service can autoscaled as per load, so cloud platforms are ideal for microservices. (...)
We can not predict the IP addresses of the container/server beforehand, so putting dependent services IP addresses in the config file is not a solution. We need a more sophisticated technique to identify the service, and Eureka server steps in here.


Can someone explain me these last two sentences about the autoscaling process and its relationship with a cloud platform?

Thanks.

 
Sheriff
Posts: 21716
102
Chrome Eclipse IDE Java Spring Ubuntu VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Consider you have a microservice that you use. There is one instance deployed, and you talk to that directly. After a while, your demand increases and a single instance just can't cut it, so you add a second instance. However, now you must change your application to support both instances, or put a load balancer (Apache, Nginx, etc) in front of it. You can do that, but once you need a third instance you need to go through this process again. (If you use a load balancer, you must update its configuration).

With service discovery, each instance registers itself. Your application is a client of the discovery service. When it needs to access the microservice, it asks the discovery server for an instance to talk to. You don't need to configure all the separate instances, only the discovery service. If a new instance is added, it registers itself again, and the discovery service will automatically make it available for you.
 
Kirk James
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rob Spoor wrote:Consider you have a microservice that you use. There is one instance deployed, and you talk to that directly. After a while, your demand increases and a single instance just can't cut it, so you add a second instance. However, now you must change your application to support both instances, or put a load balancer (Apache, Nginx, etc) in front of it. You can do that, but once you need a third instance you need to go through this process again. (If you use a load balancer, you must update its configuration).

With service discovery, each instance registers itself. Your application is a client of the discovery service. When it needs to access the microservice, it asks the discovery server for an instance to talk to. You don't need to configure all the separate instances, only the discovery service. If a new instance is added, it registers itself again, and the discovery service will automatically make it available for you.



Thank you for your reply.

Going in deeper, what's the role covered by a load balancer and Zuul proxy server in this kind of workflow/structure  (that basically is the kind of architecture i'm trying to understand more)?
 
Rob Spoor
Sheriff
Posts: 21716
102
Chrome Eclipse IDE Java Spring Ubuntu VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know the Zuul proxy server, but with a discovery service you don't need a load balancer, the discovery service can take care of that. A load balancer is often used instead of a discovery service, but it usually requires manual adding and removing of available nodes.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!