Microservices Communication Patterns (Saga, Circuit Breaker) · レッスン

Choreography Sagaの解説

中央コーディネーターを置かず、サービスがイベントを介して直接通信するChoreographyアプローチを理解します。

レッスン 2/412 ステップ

「Choreography Sagaの解説」はCoddyKit上の無料Microservices Communication Patterns (Saga, Circuit Breaker)レッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはMicroservices Communication Patterns (Saga, Circuit Breaker)学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Microservices Communication Patterns (Saga, Circuit Breaker)コースには全4レッスンが含まれています。

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

Choreography Saga Intro

Welcome! In this lesson, we'll explore the Choreography Saga pattern. It's a way to manage complex business transactions that span multiple services in a decentralized way.

Unlike an orchestra with a conductor, choreography is like a dance where each dancer knows their part and reacts to others' movements.

Decentralized Event Flow

In a choreography saga, there's no central coordinator service. Instead, each service involved in the transaction publishes events and listens for events from other services.

Services react to events.
They perform their part of the transaction.
They publish new events to trigger the next step.

Order Processing Example

Let's use a common example: processing a customer order. This involves multiple steps across different services:

Order Service: Creates the order.
Payment Service: Handles payment.
Inventory Service: Updates stock.

How do these services coordinate without a central brain?

Step 1: Order Created Event

When a customer places an order, the Order Service starts the saga. It saves the order and then publishes an OrderCreatedEvent.

This event signals to other services that a new order is ready for processing.

public class OrderService {
  public static void processNewOrder(String orderId) {
    System.out.println("Order Service: Received new order " + orderId);
    System.out.println("Order Service: Saving order " + orderId + " to database...");
    // Imagine database interaction here
    System.out.println("Order Service: Order " + orderId + " saved.");
    System.out.println("Order Service: Publishing 'OrderCreatedEvent' for " + orderId);
  }

  public static void main(String[] args) {
    processNewOrder("ORD789"); // Simulate a new order coming in
  }
}

Step 2: Payment Service Reacts

The Payment Service is subscribed to OrderCreatedEvents. When it receives one, it processes the payment for that order.

After processing, it publishes either a PaymentProcessedEvent or a PaymentFailedEvent.

public class PaymentService {
  public static void handleOrderCreated(String orderId) {
    System.out.println("Payment Service: Received 'OrderCreatedEvent' for order " + orderId);
    System.out.println("Payment Service: Processing payment for " + orderId + "...");
    // Simulate payment gateway interaction
    boolean paymentSuccess = true; // For this example, assume success
    if (paymentSuccess) {
      System.out.println("Payment Service: Payment successful for " + orderId + ".");
      System.out.println("Payment Service: Publishing 'PaymentProcessedEvent' for " + orderId);
    } else {
      System.out.println("Payment Service: Payment failed for " + orderId + ".");
      System.out.println("Payment Service: Publishing 'PaymentFailedEvent' for " + orderId);
    }
  }

  public static void main(String[] args) {
    handleOrderCreated("ORD789"); // Simulate receiving an event
  }
}

Step 3: Inventory Service Updates

Next, the Inventory Service listens for PaymentProcessedEvents. Upon receiving one, it reduces the stock for the ordered items.

It then publishes an InventoryUpdatedEvent to indicate its task is complete.

public class InventoryService {
  public static void handlePaymentProcessed(String orderId) {
    System.out.println("Inventory Service: Received 'PaymentProcessedEvent' for order " + orderId);
    System.out.println("Inventory Service: Updating stock for order " + orderId + "...");
    // Simulate inventory database update
    System.out.println("Inventory Service: Stock updated for order " + orderId + ".");
    System.out.println("Inventory Service: Publishing 'InventoryUpdatedEvent' for " + orderId);
  }

  public static void main(String[] args) {
    handlePaymentProcessed("ORD789"); // Simulate receiving an event
  }
}

The Challenge of Failures

What happens if a step in this flow fails? For example, if the payment fails, we can't update inventory. We also need to undo any previous successful steps.

This is where compensation logic comes in. It's about reversing previously completed actions.

Compensation in Choreography

In a choreography saga, compensation also happens through events. If a service fails, it publishes a compensation event.

Other services listen for these compensation events and perform their own rollback actions.

Compensation Example: Payment Fails

Imagine the Payment Service fails and publishes a PaymentFailedEvent. The Order Service, which started the saga, listens for this event.

Upon receiving it, the Order Service updates the order status to 'Cancelled', effectively rolling back the transaction from its side.

public class OrderService {
  public static void handlePaymentFailed(String orderId) {
    System.out.println("Order Service: Received 'PaymentFailedEvent' for order " + orderId);
    System.out.println("Order Service: Initiating compensation for " + orderId + ".");
    // Change order status to 'Cancelled'
    System.out.println("Order Service: Updating order " + orderId + " status to 'Cancelled'.");
    // Could publish OrderCancelledEvent if other services need to know
  }

  public static void main(String[] args) {
    handlePaymentFailed("ORD789"); // Simulate receiving a compensation event
  }
}

Pros and Cons of Choreography

Choreography offers benefits but also presents challenges:

Pros: Highly decoupled services, no central point of failure, simpler to implement for simple flows.
Cons: Can be harder to monitor the overall transaction flow, complex compensation logic, potential for 'event storms' if not designed carefully.

Choreography Check

Consider a choreography saga where an 'OrderConfirmedEvent' is published. Which statement accurately describes how the next step is initiated?

対話的なレッスンで答える

Recap: Choreography Saga

You've learned about the Choreography Saga pattern:

It's a decentralized approach for distributed transactions.
Services communicate by publishing and subscribing to events.
There's no central coordinator; each service knows its role.
Compensation for failures is also handled via events, allowing services to roll back their actions.

This pattern promotes loose coupling but requires careful design for monitoring and compensation.

無料で開始

AI チューターと学ぶ Microservices Communication Patterns (Saga, Circuit Breaker) — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース: 12
レッスン: 48

無料で学習を始めるコース全体を表示

よくある質問

「Choreography Sagaの解説」レッスンは無料ですか？

はい。「Choreography Sagaの解説」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Microservices Communication Patterns (Saga, Circuit Breaker)コースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Microservices Communication Patterns (Saga, Circuit Breaker)コースには全4レッスンが含まれています。

「Choreography Sagaの解説」で何を学びますか？

中央コーディネーターを置かず、サービスがイベントを介して直接通信するChoreographyアプローチを理解します。ブラウザで直接実行するハンズオンコードでMicroservices Communication Patterns (Saga, Circuit Breaker)を演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Microservices Communication Patterns (Saga, Circuit Breaker)を始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのMicroservices Communication Patterns (Saga, Circuit Breaker)は初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン2/4です。

「Choreography Sagaの解説」レッスンにはどのくらい時間がかかりますか？

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

このMicroservices Communication Patterns (Saga, Circuit Breaker)レッスンでコードを書いて実行できますか？

はい。すべてのMicroservices Communication Patterns (Saga, Circuit Breaker)レッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

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

← Microservices Communication Patterns (Saga, Circuit Breaker)に戻る