Notes on Microservices and Service Discovery

Introduction

• Microservices are dynamic; they can be created or destroyed over time.
• Managing communication addresses between microservices is challenging.

Service Discovery

• Definition: Service Discovery allows for a central service registry to manage the addresses of microservices in a system.
• Functionality: Enables logical naming of services to find their physical addresses through a service registry.

Example Scenario

• Microservices Example: Client communicates with three microservices:
  • Product Service
  • Search Service
  • Ordering Service
• Problem: Clients (or services) need to know physical addresses of these services, which is impractical when scaled.
• Load Balancer: Can route requests but requires knowledge of physical addresses.

Dynamic URLs Problem

• URLs can change over time, making hardcoding difficult.
• Example with Product Service scaled to 10 instances, requiring knowledge of 10 physical addresses.

Service Discovery Solutions

• Popular solutions include:
  • HashiCorp Consul
  • Netflix Eureka
• The rest of the discussion will focus on HashiCorp Consul as the service registry.

Implementation of Service Discovery

• Services register their physical addresses with Consul when they start.
• Flow of requests:
  1. Service (e.g., Ordering Service) registers with Consul.
  2. Client queries Consul with logical service name (e.g., "Ordering Service").
  3. Consul returns physical address for the client to make a request.

Example API Implementation (ASP.NET Core)

• Services:
  • Newsletter API
  • Newsletter Reporting API
• Integration with HTTP requests:
  • Create a typed HTTP client to call the Reporting API.
  • Initial state uses hardcoded base address which is problematic.

Task Steps to Implement

1. Copy and modify GetArticle feature for new endpoint GetReportingArticle in Newsletter API.
2. Use a typed HTTP client to send requests.
3. Register the HTTP client before building the application.

Hardcoded URI Issue

• Hardcoding leads to challenges when URLs change (e.g., service address changed to reportingAPI1).
• This will highlight issues when scaling services.

Transition to Service Discovery

1. Set up the Consul service registry in Docker.
2. Use Steeltoe.Discovery.Client for connection to Consul.
3. Register APIs in Consul with logical names.
4. Use logical names in the base address instead of hardcoded values.

Service Discovery in Action

• Dashboard: Can monitor service registration and health at localhost:8500.
• Service Discovery translates logical names to physical addresses effectively, avoiding hardcoding.

Conclusion and Further Learning

• Watch related videos for more on microservices and distributed systems.
• Source code available on Patreon for further experimentation.
• Suggested further learning includes clean architecture and modular monolith courses.