Service Discovery Pattern: The Secret Behind How Microservices Call to Each Other

Service Discovery Pattern: The Secret Behind How Microservices Call to Each Other

It all started during a casual lunch break with the team. Our team leader, Fahmy looked frustrated as he stared at his phone.

“What’s wrong, Fahmy?” I asked, curious.

“I’m trying to book a car, but it’s a nightmare,” he replied. “I have to call a bunch of dealerships, check if they even have the car I want, and then compare prices. It’s so much work!”

Gimmy, one of our senior developers, smirked. “You know what you need? Service discovery.”

“Service discovery? What does that even mean?” I asked, leaning forward.

Khaled, our lead developer, jumped in with a laugh. “Imagine instead of contacting each dealership one by one, you had a central directory. You’d just tell it what you’re looking for, and it would match you with the best dealership automatically.”

“Oh, that would be amazing!” Fahmy said.

“That’s basically what service discovery does in microservices,” Gimmy added. “When one service needs to talk to another, it doesn’t need to know where the other service lives or how to find it. It just asks the service registry, and everything happens automatically.”

At this point, I was intrigued. “Okay, I get the idea. But how does this actually work in a microservices system?”

What Is Service Discovery?

Khaled took the lead. “In simple terms, service discovery is how microservices find each other. Let’s say Service A needs to call Service B. In a large system with dozens or even hundreds of services, it’s impossible for Service A always to know where Service B is. That’s because services can move, scale, or go down and come back up with a new IP address.”

“So instead of hardcoding IP addresses or URLs, services use something called a service registry,” Gimmy added. “The service registry acts like a phonebook. Services register themselves there with their current address, and other services can look them up when needed.”

“That sounds smart,” I said. “But how do services register themselves?”

How Services Register and Discover

“There are two ways this usually happens,” Khaled explained. “The first is self-registration. In this case, a service tells the registry directly, ‘Hey, I’m here, and this is my address.’ When the service goes down, it deregisters itself.”

“And the second way?” I asked.

Gimmy jumped in. “The second way is through a sidecar or an external tool. Instead of the service handling registration itself, another process does it for the service. This is more reliable because it’s not dependent on the service being up to keep its registration updated.”

“Both of these ways can happen on the Server-side Service Discovery or Client-side Service Discovery” Khaled said.

Server-side Service Discovery

“Service discovery can happen on the server side or the client side,” Khaled explained. “On the server side, the service registry is responsible for managing the service information and responding to discovery requests.”

“So how does that work in practice?” I asked.

“Well, when a service starts up, it registers itself with the service registry,” Gimmy said. “The registry stores the service’s location, such as its IP address and port. Then, when another service needs to call it, the caller queries the registry to find the service’s current location.”

“The registry acts as a central point of lookup, handling all the service discovery requests,” Khaled added. “This approach is often used in more traditional microservices architectures.”

Client-side Service Discovery

The other approach is client-side service discovery, Gimmy explained. “In this case, the service registry doesn’t receive and respond to discovery requests. Instead, the client (the service making the call) is responsible for looking up the service it needs.”

“How does that work?” I asked.

“With client-side discovery, the client has a local copy of the service registry,” Khaled said. “When it needs to call another service, it checks its local registry to find the service’s location. This can be more efficient than going through a central server for each request.”

“And what are the benefits of client-side discovery?” I asked.

“It can reduce the load on the central service registry, and make the overall system more resilient,” Gimmy replied. “If the registry goes down, the clients can still find services using their local copy. It also allows for more advanced load balancing and failover strategies on the client side.”

“Interesting,” I said. “So it really comes down to trade-offs between server-side and client-side discovery.”

“Exactly,” Khaled concluded. “Both approaches have their advantages, and the best choice depends on the specific requirements and architecture of your microservices system.”

“Okay,” I said, nodding. “But where does this registry live in Server Side ? Is it just a database?”

Where Does the Registry Live?

“Good question!” Khaled said. “The registry is usually managed by a service discovery tool. For example, Kubernetes has a built-in service discovery system. It uses DNS and something called CoreDNS to resolve service names to their IP addresses.”

“Wait,” I interrupted, “so if I’m using Kubernetes, do I even need a separate registry?”

“Not really,” Gimmy replied. “Kubernetes handles most of it for you. When a service is created, Kubernetes assigns it a ‘cluster IP.’ Other services can use the service’s name, and Kubernetes resolves it to the right IP. It even handles load balancing by distributing requests across the service’s pods.”

“That’s awesome,” I said. “But what if I’m not using Kubernetes?”

Other Tools for Service Discovery

“If you’re not using Kubernetes, there are other tools like Consul, Eureka, or Zookeeper,” Khaled explained. “Each of these tools acts as a service registry and discovery system. They allow services to register themselves and discover other services.”

“Consul, for example, is really popular,” Gimmy added. “It’s developed by HashiCorp, and it’s great for dynamic environments where services are constantly moving or scaling.”

Okay, so these tools are basically doing the same thing as Kubernetes’ service discovery?” I asked.

“Yes, but they’re independent of the platform,” Khaled said. “You can use them with virtual machines, bare-metal servers, or even in hybrid environments.”

What Happens Behind the Scenes?

I wanted to dig deeper. “So, when Service A wants to call Service B, what’s happening behind the scenes?”

“It’s like this,” Khaled said, leaning back. “Service A sends a request using Service B’s name. For example, it might say, ‘Hey, I want to talk to Service B.’ The service registry or Kubernetes resolves that name to an IP address. Then, the request is forwarded to the service, which balances it across its pods.”

Gimmy added, “The key here is that Service A doesn’t need to know Service B’s actual IP. It just uses the name, and everything else is handled automatically.”

“That’s so cool,” I said. “It’s like magic!”

Why Is Service Discovery Important?

“Exactly,” Khaled said. “Without service discovery, you’d have to manually configure the addresses of all your services, which isn’t scalable. Plus, if a service goes down or scales up, you’d need to update everything manually. Service discovery automates all of that.”

Gimmy chimed in, “And it’s not just about convenience. Service discovery is critical for reliability and scalability. In a distributed system, services are always changing. A good discovery system makes sure everything stays connected, even when things move around.”

Key Takeaways

By the end of our discussion, I felt like I had a solid understanding of service discovery. Here’s what I learned:

  1. Service discovery helps microservices find each other without hardcoding addresses.
  2. A service registry is like a phonebook that keeps track of where services are.
  3. Tools like Kubernetes, Consul, Eureka, and Zookeeper handle service discovery for different environments.
  4. Kubernetes’ built-in system uses CoreDNS to resolve service names to IPs and balances traffic across pods.
  5. Without service discovery, managing communication between services would be chaotic and error-prone.

As I finished my lunch, I looked at Fahmy. “You know, Fahmy, maybe you don’t need service discovery for your car problem. But I sure do for my work!” ??

Fahmy laughed and picked up his phone. “Well, I’ve got good news for me. I just found a dealership that has the car I want. I didn’t have to call anyone. I just checked an app, and it automatically matched me with the right place. It’s like magic!”

“See? Even you got a taste of service discovery ?? Gimmy joked.

I smiled, realizing just how powerful service discovery really is for managing the complexity of microservices — and now, Fahmy had experienced a bit of the magic, too.


Resources

https://baeldung.com/cs/service-discovery-microservices/

https://highscalability.com/gossip-protocol-explained/

https://manerajona.medium.com/service-discovery-patterns-with-netflix-eureka-34d5b260aeda

https://microservices.io/patterns/server-side-discovery.html


Ahmed Safwat

Senior SDE @ Pixelogic Media | ex-Orange Labs | Backend Enthusiast

2 个月
回复

要查看或添加评论,请登录

Ahmed Safwat的更多文章

  • Reverse Proxy VS. API Gateway

    Reverse Proxy VS. API Gateway

    It all started during a casual team break. I had been reading some articles online about API Gateways, and a question…

    3 条评论
  • A Journey of Discovery and Decision “API Gateway”

    A Journey of Discovery and Decision “API Gateway”

    It was a regular Monday meeting — one of those where everyone was settling in, coffee cups in hand, waiting for Khaled…

    12 条评论
  • A Tale of Saving White Friday …

    A Tale of Saving White Friday …

    Disclaimer: This is a fictional story created to illustrate the Outbox Pattern. Any resemblance to real people, events,…

    1 条评论
  • Command Your Queries: Unraveling the CQRS Advantage

    Command Your Queries: Unraveling the CQRS Advantage

    Introduction to CQRS Command Query Responsibility Segregation (CQRS) is an architectural pattern that separates the…

    4 条评论
  • Spring Boot Projections Uncovered: How to Fetch Just What You Need

    Spring Boot Projections Uncovered: How to Fetch Just What You Need

    Spring Boot, powered by Spring Data JPA, simplifies the development of data-driven applications. One of its powerful…

    3 条评论
  • BIGINT vs. BIGSERIAL in PostgreSQL

    BIGINT vs. BIGSERIAL in PostgreSQL

    In PostgreSQL, managing large integers efficiently is crucial for many applications, especially when dealing with…

    1 条评论
  • ORM: The Database Magician

    ORM: The Database Magician

    the realm of software development, databases are an indispensable component for storing and managing data. Relational…

    2 条评论
  • Query Plan in a Nutshell

    Query Plan in a Nutshell

    Working with large databases often comes with the challenge of slow query performance. The root cause of this problem…

  • Discover the Secrets of Java Reflection

    Discover the Secrets of Java Reflection

    Java Reflection is a powerful feature in the Java programming language that allows developers to inspect and manipulate…

    3 条评论
  • Runnable OR Callable ??

    Runnable OR Callable ??

    Java provides various mechanisms to handle multithreading, and two of the core interfaces that facilitate concurrency…

    1 条评论

社区洞察

其他会员也浏览了