AI Powered SaaS: Stripe + Auth + Billing + Deploy · レッスン

サービスディスカバリと通信

分散マイクロサービス環境で、サービス同士が互いを検出し、効果的に通信する仕組みを理解します。

「サービスディスカバリと通信」はCoddyKit上の無料AI Powered SaaS: Stripe + Auth + Billing + Deployレッスンです。これはレッスン3/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAI Powered SaaS: Stripe + Auth + Billing + Deploy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AI Powered SaaS: Stripe + Auth + Billing + Deployコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Intro to Service Discovery

In a microservices architecture, applications are broken into many small, independent services. These services need to find and talk to each other to work together.

Service discovery is the automatic process by which services locate each other on a network.

It solves the problem of services needing to know each other's network locations (IP addresses, ports).
Essential for dynamic, scalable, and resilient systems.

The Problem Without Discovery

Imagine you have a 'User Service' and an 'Order Service'. If the Order Service needs user data, it must know the User Service's address.

Without service discovery:

You might hardcode IP addresses and ports.
If a service scales up or moves, its address changes, breaking communication.
Manual updates are error-prone and time-consuming.

This approach isn't feasible for dynamic cloud environments.

Introducing the Service Registry

At the heart of service discovery is the Service Registry. Think of it as a phone book for your services.

It's a central database that stores the network locations of all active service instances.
When a service starts, it registers itself with the registry.
When a service needs to communicate, it queries the registry to find the target service's address.

Popular examples include HashiCorp Consul, Netflix Eureka, and etcd.

How Services Register

Services need a way to tell the registry they exist and where they can be reached. There are two main patterns:

Self-Registration: The service itself registers and de-registers with the service registry. It also sends periodic heartbeats to prove it's still alive.
Third-Party Registration: A separate component (often called a 'Registrar' or 'Agent') handles registration for the service. This decouples the service from the discovery mechanism.

Both methods ensure the registry has up-to-date information.

Client-Side Discovery Explained

In client-side discovery, the client service is responsible for querying the service registry to find available instances of a target service.

The client uses a discovery client library (e.g., Spring Cloud Netflix Eureka Client).
It retrieves a list of service instances from the registry.
It then uses a load-balancing algorithm (like round-robin) to select an instance and make a direct request.

This approach puts discovery logic into each client service.

Server-Side Discovery Explained

With server-side discovery, a dedicated component (often a load balancer, API Gateway, or router) handles service lookup.

The client makes a request to a well-known address (e.g., the load balancer).
The load balancer queries the service registry to find an available instance of the target service.
It then forwards the client's request to that instance.

This pattern simplifies client logic, as clients don't need discovery libraries.

Service Communication Basics

Once a service has discovered the address of another service, they need to communicate. This typically involves making requests and receiving responses.

Communication can be synchronous (request-response) or asynchronous (event-driven).
The choice depends on whether the calling service needs an immediate response or can continue processing.

Let's look at common synchronous methods first.

Synchronous Communication Example

Synchronous communication means the calling service waits for a response from the called service. The most common protocols are HTTP/REST and gRPC.

Here's a conceptual Java example demonstrating how a service might register and a client might find it to make a 'request':

public class Main {
  // Mock Service Registry
  static class ServiceRegistry {
    private String serviceAddress = "http://localhost:8080/my-service"; // Example address

    public void register(String serviceName, String address) {
      System.out.println("Service '" + serviceName + "' registered at: " + address);
      this.serviceAddress = address; // Simplified: in real system, this is a map
    }

    public String lookup(String serviceName) {
      System.out.println("Client looking up service: " + serviceName);
      if (serviceName.equals("MyService")) {
        return serviceAddress;
      }
      return null;
    }
  }

  // Mock Service
  static class MyService {
    private String name = "MyService";
    private String address = "http://localhost:8081/api/data";

    public void startAndRegister(ServiceRegistry registry) {
      System.out.println(name + " starting up...");
      registry.register(name, address);
      System.out.println(name + " ready to receive requests at " + address);
    }
  }

  // Mock Client
  static class MyClient {
    private ServiceRegistry registry;

    public MyClient(ServiceRegistry registry) {
      this.registry = registry;
    }

    public void makeRequest(String serviceName) {
      System.out.println("Client needs to call '" + serviceName + "'");
      String serviceAddress = registry.lookup(serviceName); // Discovery step

      if (serviceAddress != null) {
        System.out.println("Found service at: " + serviceAddress);
        System.out.println("Making HTTP request to " + serviceAddress + "...");
        System.out.println("Response: Hello from MyService!"); // Simulating response
      } else {
        System.out.println("Service '" + serviceName + "' not found.");
      }
    }
  }

  public static void main(String[] args) {
    ServiceRegistry registry = new ServiceRegistry();

    MyService dataService = new MyService();
    dataService.startAndRegister(registry); // Service registers itself

    System.out.println("\n--- Client Interaction ---");
    MyClient appClient = new MyClient(registry);
    appClient.makeRequest("MyService"); // Client discovers and communicates
  }
}

Asynchronous Communication

While synchronous communication is direct, asynchronous communication uses message queues or event streams (as discussed in the previous lesson).

Services don't wait for an immediate response.
They publish events or messages to a queue, and other services consume them when ready.
This decouples services, improving resilience and scalability.

Service discovery ensures event producers and consumers can find the message broker.

Benefits: Load Balancing & Resilience

Service discovery isn't just about finding services; it enables crucial microservice benefits:

Load Balancing: If multiple instances of a service are registered, the discovery mechanism (client-side or server-side) can distribute requests evenly among them.
Resilience: If a service instance fails, it stops sending heartbeats or is de-registered. The registry updates, and clients/load balancers automatically stop routing requests to the failed instance.

This dynamic adaptability is key to robust microservices.

Check Your Understanding

Consider a microservices setup where a 'Product Service' needs to call a 'Review Service'. The Review Service has multiple instances running.

Which of the following best describes the role of a Service Registry in this scenario?

Recap: Discovery & Communication

In this lesson, we explored the critical concepts of service discovery and communication in microservices.

Service Discovery allows services to find each other dynamically.
The Service Registry is the central 'phone book' for service instances.
We learned about client-side and server-side discovery patterns.
Services communicate synchronously (e.g., HTTP/REST) or asynchronously (e.g., message queues).
Discovery enables key benefits like load balancing and resilience.

Understanding these patterns is vital for building scalable and maintainable microservice architectures.

よくある質問

「サービスディスカバリと通信」レッスンは無料ですか？

はい。「サービスディスカバリと通信」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AI Powered SaaS: Stripe + Auth + Billing + Deployコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AI Powered SaaS: Stripe + Auth + Billing + Deployコースには全4レッスンが含まれています。

「サービスディスカバリと通信」で何を学びますか？

分散マイクロサービス環境で、サービス同士が互いを検出し、効果的に通信する仕組みを理解します。ブラウザで直接実行するハンズオンコードでAI Powered SaaS: Stripe + Auth + Billing + Deployを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

AI Powered SaaS: Stripe + Auth + Billing + Deployを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAI Powered SaaS: Stripe + Auth + Billing + Deployは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン3/4です。

「サービスディスカバリと通信」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAI Powered SaaS: Stripe + Auth + Billing + Deployレッスンでコードを書いて実行できますか？

はい。すべてのAI Powered SaaS: Stripe + Auth + Billing + Deployレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← AI Powered SaaS: Stripe + Auth + Billing + Deployに戻る