Lecture 246: Why you need a service registry in microservices

By this point in the course you’ve already got the basics of microservices down, learned how to work with API Gateway, and how to integrate it into Spring Boot projects. API Gateway has become your buddy and the go-to for directing requests between microservices. You learned how to route requests, handle them with various filters and predicates, and also ensure security and load balancing. Today we’ll dig into another important aspect of microservices — Service Discovery. But first, let’s understand why this even matters!

Picture this...

So you, as a dev experienced in microservice architecture, decide to build an app out of a bunch of independent services: a product catalog, an auth service, a shopping cart, a payment service. Everything’s fine until you need these services to start talking to each other.

"What’s the IP for the product catalog?" your teammates will ask. "We hosted it on another server. And if we scale, how do we add new replicas?" the DevOps folks will add.

And chaos begins: you manually hardcode IPs, change configs for every microservice, and after a couple days you realize that managing this hell manually is impossible. Congrats, you’ve just hit the problem a service registry solves!

What is a service registry?

Come closer, we’ll break it down.

A service registry is a centralized catalog of all microservices in your system that enables dynamic discovery of services. Instead of microservices calling each other directly, they ask the registry for addresses.

Here’s how it looks:

1. Microservices register with the registry. When a new instance of a service starts, it tells the registry: "Hi, I’m the payment service, my address is http://127.0.0.1:8082".
2. Requesting a list of services. When another service, like the "shopping cart", wants to talk to the payment service, it asks the registry: "Where can I find the payment service?"
3. Real-time updates. If a service dies or new instances are added (for example, due to increased load), the registry updates its information.

Problems a service registry solves

1. Dynamic service discovery: services can move, be added, or removed freely without needing to update routes manually.
2. Scalability: multiple instances of the same service can register, enabling load to be balanced across them.
3. Simplified configuration: you don’t have to set static IP addresses for every service.

Why using static configuration is a bad idea?

When you start wiring microservices together, the first impulse for many devs is "Let’s hardcode everything into application.yml!".

Here’s an example:

catalog-service:
  url: http://127.0.0.1:8081
payment-service:
  url: http://127.0.0.1:8082
auth-service:
  url: http://127.0.0.1:8083

It works… as long as your microservices stay static. But what if:

1. One of the services moves to another server?
2. You want to add new instances to scale?
3. Services start scaling dynamically in Kubernetes?

Manually updating configs becomes unbearable, and you end up with more bugs than code. The fix is dynamic service discovery and a service registry, like Eureka, Consul, or Zookeeper.

How does a service registry work?

Main components:

1. Service Registry (registry of services): the central node that stores info about all registered services. It knows who’s where, who’s alive, and who’s not.
2. Service Provider: each microservice that provides functionality registers with the registry. This happens on application startup.
3. Service Consumer: any microservice that wants to use another service queries the registry to find its location.

Workflow:

1. Registration: a service sends its info to the registry on startup (IP, port, name).
2. Heartbeat: services periodically send "I’m alive" signals to the registry. If the heartbeat stops, the registry marks the service as "unavailable".
3. Discovery: when a consumer wants to find another service, it asks the registry.
4. Load balancing: when multiple instances of a service are registered, the registry can provide a list of active instances to spread the load.

An example using a Eureka-based registry

Eureka is Netflix’s solution for Service Discovery. It integrates with Spring Boot and is one of the most popular tools in the microservices world.

1. Setting up a Eureka Server

First, let’s create a server that will act as our service registry. Add the dependency to your pom.xml:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

Then add the @EnableEurekaServer annotation to your main class:

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApp {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApp.class, args);
    }
}

And configure a minimal application.yml:

server:
  port: 8761

eureka:
  client:
    fetch-registry: false
    register-with-eureka: false

Run the app. The Eureka Server will be available at http://localhost:8761.

2. Setting up a client service

Now let’s register a microservice with Eureka. Add this dependency:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Enable the Eureka client with the @EnableEurekaClient annotation:

@SpringBootApplication
@EnableEurekaClient
public class PaymentServiceApp {
    public static void main(String[] args) {
        SpringApplication.run(PaymentServiceApp.class, args);
    }
}

Add Eureka settings to application.yml:

server:
  port: 8082

spring:
  application:
    name: payment-service

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

After starting the microservice it will show up on the Eureka Server dashboard.

Alternatives to Eureka

Eureka isn’t the only option. Here are a few popular alternatives:

• Consul: a powerful service registry with support for traffic distribution and config management.
• Zookeeper: a stable tool for distributed systems, used by many large companies.
• Etcd: a lightweight, fast solution often used with Kubernetes.

Benefits of using a service registry

1. Flexibility and scalability of your microservice system.
2. Simplified management of configuration and routing.
3. Ability to easily add new service instances without changing the main configuration.
4. Improved fault tolerance by automatically excluding unavailable services.

Using static configuration is easy, but kinda sad. With service registries life gets way more fun — at least because you stop being the "sysadmin" for your microservices. In the next lecture we’ll see how to combine API Gateway and a service registry to unlock even more cool capabilities!