Unified Interface for Microservice Registration and Discovery

As in typical monolithically-architectured applications, some applications are deployed over to application servers and statically registered with load balancers. But as we move towards microservices-based architectures, services may scale up and down based on certain pre-defined metrics or due to auto-scaling. This dynamic nature of service endpoint addresses is handled by service registration and discovery. Each service registers with a broker and provides more details about itself, such as the endpoint address. Other consumer services then query the broker to find out the location of a service and invoke it.

In this blog, we will talk about three concepts for a sound microservice architecture – service discovery, client-side load balancing, and a Non-JVM client. We will also see how the dynamic scaling of services takes place.

Eureka Service Registry

The service registry is a kind of database populated with information on how to dispatch requests to microservice instances. Whenever a service endpoint changes, the registry needs to know about the change. This is what registration is all about; who publishes or updates the information on how to reach each service. Netflix Eureka, in our case, will tell users where services register themselves with a known Eureka instance and then will intermittently send heartbeats to make sure the Eureka instance(s) know they’re still alive. Let’s start the Eureka registry server for services:

First, we create a new Maven project and put the dependencies into it.


<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-eureka-server</artifactId>

<version>1.1.5.RELEASE</version>

</dependency>

Next, we’re creating the main application class:

@SpringBootApplication

@EnableEurekaServer

public class EurekaServerApplication {

public static void main(String[] args) {

SpringApplication.run(EurekaServerApplication.class, args);

}

}

 

Then, we configure the properties for the Eureka server, so an application.properties will be our configuration file:


server.port=8764

eureka.client.register-with-eureka=false

eureka.client.fetch-registry=false

logging.level.com.netflix.eureka=OFF

logging.level.com.netflix.discovery=OFF

 

Here we’re configuring an application port – 8764 is the default one for Eureka servers. We are telling the built-in Eureka client not to register with ‘itself’ because our application should be acting as a server.

Now we will point our browser to http://localhost:8764 to view the Eureka dashboard, where we will later inspect the registered instances.

 

Enable client application for service registry

To register our application service with the Eureka server, we will make the following configuration in application service.


@SpringBootApplication

@EnableDiscoveryClient

public class ServiceApplication {

public static void main(String[] args) {

SpringApplication.run(ServiceApplication.class, args);

}

}

 

Then we configure the application service properties like application.properties:


spring.application.name=eureka-application

eureka.client.serviceUrl.defaultZone=http://localhost:8764/eureka/

server.port=9080

 

The service points to Eureka using the specified ‘eureka.client.serviceUrl.defaultZone’ value. By default, services will try to connect to localhost:8761/eureka server.

After that, we need to start our client service application and point our browser to http://localhost:8764. The client service application is now registered with the Eureka server.

 

Service discovery and client-side load balancing using Ribbon

As you can imagine, discovery is the counterpart to registration from the point of view of clients. When a client wants to access a service, they must find out where the service is located (and other relevant information to perform the request).

The client is responsible for connecting to the service registry and looking up the service to get actual address information (IPs, hostnames, ports) of services they need to call. The client is coupled with service registry concerns. An example of a client-side load balancer in the Spring Cloud ecosystem is Netflix Ribbon. Netflix Ribbon is used to look up and communicate with services. Ribbon comes with the basic round-robin based load balancing and fault tolerance.


@SpringBootApplication

@RibbonClient(name = "ribbonservice",configuration=SayHelloConfiguration.class)

public class RibbonClientApplication {

public static void main(String[] args) {

SpringApplication.run(RibbonClientApplication.class, args);

}

@LoadBalanced

@Bean

public RestTemplate restTemplate(RestTemplateBuilder builder) {

return builder.build();

}

}

Unified interface for a non-JVM based client using a proxy

A Java-based client can easily invoke microservices using a Ribbon client, so we extended this to make it possible for a non-JVM based client using proxy over HTTP to invoke it.

 

Here we are using restTemplate returned by the Ribbon client, so it will provide us with an easy mechanism for load balancing as well as service discovery.

Using this approach in microservice architecture, we get the benefit of client-side load balancing and service discovery. Microservices can be easily invoked by non-JVM clients.

Pawan Mishra

Pawan Mishra

Pawan Mishra is a Senior Technical Lead at 3Pillar Global, working out of our office in Noida, India. He has expertise in building Java-based enterprise products. He likes learning new things and believes that there can never be an end to learning. His current areas of interest are data science, performance optimization, micro service/serverless design and architecture. He loves to spend his spare time reading literature and spiritual books.

One Response to “Unified Interface for Microservice Registration and Discovery”
  1. wings io on

    It is easy to understand, detailed and meticulous! I have had a lot of harvest after watching this article from you! I feel it interesting, your post gave me a new perspective! I have read many other articles about the same topic, but your article convinced me! I hope you continue to have high quality articles like this to share with veryone!

    Reply
Leave a Reply

Related Posts

How to Develop Microservices Using .NET Core & Docker With increasing business demands, we now develop very large and complex projects that take more time to build and deploy. Whenever QA reports any issu...
Highlights of the AWS re:Invent Conference & The Future... In Take 3, Scene 30, we debrief you on the AWS re:Invent conference that was recently held in Las Vegas. We're joined by Dan Greene, the Director of C...
Re:Invent Recap – The Finale Re:Invent is over and man, that was a lot of content. Now that we've had a few days to marinate on it, let's break down a bit of the conference by the...
Microservice & Serverless Architectures – Is Eith... On this episode of Take 3, we explore microservices and serverless architectures - what they are, why microservices have gained so much in popularity ...
Is Mobile Automation Testing Right For You? In the fast paced software development industry, mobile automation testing has become indispensable. The real value of mobile automation testing is re...