What is all this fuss about?

A service registry allows our services to find/discover each other. Without some sort of registry, we would need to wire our services by hand. A central registry for our services enables advanced features like client-side load balancing where a client can distribute its requests across multiple instances of the same service. Another use-case leveraging service discovery is an API Gateway which uses the registry to forward the requests and therefore is a single entry-point to accessing our services. An API Gateway can keep unauthorized users out or create pre- and postprocessors for passing requests.

Let’s get it started

Our journey again takes us again to http://start.spring.io.

In order to create the service discovery itself, we need to add ‘Eureka Server’ as a dependency. Eureka is part of the Netflix Open Source Project. It is a component which they used to enable their services to discover each other on AWS.

After downloading and extracting the just generated project we are almost finished with implementing the server. The only things remaining here are:

Adding @EnableEurekaServer on top of your Application-class

on top of your Application-class Adding a few lines to the application.properties of our newly created registry service

server.port=8761

eureka.client.register-with-eureka=false

eureka.client.fetch-registry=false

Very simple, yet very effective. The only configuration we have done here is that we specified 8761 as the port being used and also that the registry itself should neither fetch the registry nor register itself with Eureka.

Being in the working directory of the registry-service we can run the service via

./mvnw clean spring-boot:run

After it booted we should be able to see the Eureka Dashboard at http://localhost:8761/. Eureka! There is the Dashboard of our Service Registry, but until now we can see that no service is registered there (see Instances currently registered with Eureka). Don’t fear, we will change this very soon.

What about the other services?

Yeah, you are totally right. Even if it sometimes feels like there is happening a lot of magic in the background, not everything is done for you. The other services still have to register themselves at the service registry and also have to fetch the information about other services from there.

You remember our counter-service which is fetching its configuration from the config-service? It was fetching its configuration from the configuration service by hitting its defined default port. This is not very robust and not a good practice at all. We will now refactor these two services to leverage the service registry we just created to fetch the configuration regardless of the port being used.

Updating the Config-Service

The changes in the Config-Service are very small:

Add a dependency to your pom (up to date versions always can be found at http://projects.spring.io/spring-cloud/)

<dependency>

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

<artifactId>spring-cloud-starter-eureka</artifactId></dependency> <!-- Don’t forget to add the spring cloud project to your dependency management area of your pom. --> ...

<dependency>

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

<artifactId>spring-cloud-dependencies</artifactId>

<version>Camden.SR5</version>

<type>pom</type>

<scope>import</scope>

</dependency>

Add @EnableDiscoveryClient to your Application class

Make sure that the following is inside your application.properties

spring.application.name=config

spring.cloud.config.discovery.enabled=true

When you now start your config service and the service registry, you should be able to see the config service registering itself at the registry. You can check this again on our Dashboard at http://localhost:8761/.