อธิบาย Saga แบบประสานงานด้วยเหตุการณ์
ทำความเข้าใจแนวทางแบบประสานงานด้วยเหตุการณ์ ซึ่งบริการต่าง ๆ สื่อสารกันโดยตรงผ่านเหตุการณ์โดยไม่มีตัวประสานงานส่วนกลาง
อธิบาย Saga แบบประสานงานด้วยเหตุการณ์ เป็นบทเรียน Microservices Communication Patterns (Saga, Circuit Breaker) ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน 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.
เรียนรู้ Microservices Communication Patterns (Saga, Circuit Breaker) ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 12
- บทเรียน
- 48
คำถามที่พบบ่อย
บทเรียน “อธิบาย Saga แบบประสานงานด้วยเหตุการณ์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “อธิบาย Saga แบบประสานงานด้วยเหตุการณ์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Microservices Communication Patterns (Saga, Circuit Breaker) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Microservices Communication Patterns (Saga, Circuit Breaker) มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “อธิบาย Saga แบบประสานงานด้วยเหตุการณ์”
ทำความเข้าใจแนวทางแบบประสานงานด้วยเหตุการณ์ ซึ่งบริการต่าง ๆ สื่อสารกันโดยตรงผ่านเหตุการณ์โดยไม่มีตัวประสานงานส่วนกลาง คุณปฏิบัติ Microservices Communication Patterns (Saga, Circuit Breaker) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Microservices Communication Patterns (Saga, Circuit Breaker) หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Microservices Communication Patterns (Saga, Circuit Breaker) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “อธิบาย Saga แบบประสานงานด้วยเหตุการณ์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Microservices Communication Patterns (Saga, Circuit Breaker) นี้ได้ไหม
ได้ บทเรียน Microservices Communication Patterns (Saga, Circuit Breaker) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- รูปแบบ Saga คืออะไร
- อธิบาย Saga แบบประสานงานด้วยเหตุการณ์
- อธิบาย Saga แบบมีตัวประสานงาน
- การเลือกระหว่างการประสานงานแบบกระจายกับการควบคุมจากศูนย์กลาง