Lesson 7.3: Circuit Breakers

Thời lượng: 25 phút
Level: Advanced
Yêu cầu: Kiến thức về kiến trúc Microservices và xử lý bất đồng bộ.

Mục tiêu bài học

Sau bài học này, bạn sẽ:

• Hiểu cơ chế hoạt động của Circuit Breaker qua 3 trạng thái: Closed, Open, Half-Open.
• Thiết kế được cơ chế Fallback (Dự phòng) khi một service bị lỗi.
• Biết cách theo dõi (Monitoring) sức khỏe của hệ thống qua cơ chế này.

Nội dung chính

1. Vấn đề "Lỗi lan truyền" (Cascading Failure)

Trong hệ thống Microservices, Service A gọi Service B. Nếu Service B bị chậm hoặc chết, Service A sẽ phải đứng đợi (Timeout). Nếu có hàng nghìn yêu cầu cùng đợi như vậy, Service A cũng sẽ hết tài nguyên và chết theo.

Đó là lý do chúng ta cần một cái Cầu chì (Circuit Breaker).

2. Ba trạng thái của Cầu chì

Hệ thống hoạt động như một cái cầu chì điện trong nhà bạn:

• CLOSED (Đóng - Bình thường): Request được phép đi qua bình thường. Hệ thống đếm số lần thất bại. Nếu tỷ lệ lỗi vượt ngưỡng (VD: 50% lỗi trong 10 giây), cầu chì sẽ "nhảy".
• OPEN (Mở - Lỗi): Request bị chặn NGAY LẬP TỨC từ phía Service A. Không thèm gọi sang Service B để tránh làm quá tải thêm. Trả về kết quả Fallback hoặc lỗi nhanh (Fail-fast).
• HALF-OPEN (Nửa mở - Thử nghiệm): Sau một khoảng thời gian chờ (VD: 30 giây), cầu chì cho phép MỘT VÀI request đi qua để thử xem Service B đã khỏe lại chưa. Nếu thành công -> Quay lại CLOSED. Nếu vẫn lỗi -> Quay lại OPEN.

3. Chiến lược Fallback (Dự phòng)

Khi cầu chì đang ở trạng thái OPEN, thay vì báo lỗi cho khách hàng, hãy cố gắng cung cấp một trải nghiệm "hạ cấp" (Graceful Degradation).

• Ví dụ 1 (E-commerce): Service gợi ý sản phẩm bị chết? -> Fallback: Hiển thị danh sách sản phẩm bán chạy nhất (dữ liệu static/cache) thay vì để trống trang web.
• Ví dụ 2 (Social): Service đếm số lượt Like bị chậm? -> Fallback: Tạm thời không hiển thị số Like nhưng vẫn cho phép user đọc bài viết.

Nguyên tắc then chốt

"Thà trả về dữ liệu cũ (Cached) còn hơn bắt người dùng nhìn thấy trang trắng hoặc đợi quá lâu."

Mục tiêu của Circuit Breaker là cắt đứt sự phụ thuộc vào các service đang ốm yếu để bảo vệ các service đang khỏe mạnh khác.

Thực hành

Bài tập 1: Thiết kế Fallback cho hệ thống Thanh toán

Bối cảnh: Bạn gọi API của một cổng thanh toán bên thứ 3 (VD: VNPay/Stripe). API này đang bị chập chờn.

Yêu cầu:

• Khi Cầu chì OPEN, bạn sẽ trả về phản hồi gì cho người dùng đang nhấn nút "Thanh toán"?
• Tại sao không nên thử lại (Retry) liên tục trong trường hợp này?

Tình huống thực tế

Scenario 1: Sập dây chuyền (The Chain Reaction)

Bối cảnh: Service Shipping chết -> Dẫn đến Service Order đứng đợi -> Dẫn đến API Gateway hết thread -> Dẫn đến toàn bộ Website không thể truy cập, kể cả trang Home vốn không liên quan gì đến Shipping.

Giải quyết: Lắp Circuit Breaker ngay tại Service Order khi gọi sang Shipping.

• Khi Shipping lỗi, Order trả về ngay lập tức: "Đang tính phí vận chuyển...".
• Website vẫn hoạt động, user vẫn xem được sản phẩm, chỉ có phần liên quan đến Shipping là bị ảnh hưởng.

Câu hỏi phỏng vấn

Senior Level

1. Q: Phân biệt Retry và Circuit Breaker? Khi nào dùng cái nào? A:
   • Retry: Dùng cho các lỗi Tạm thời (Transient) như lag mạng chớp nhoáng. Thử lại ngay có thể thành công.
   • Circuit Breaker: Dùng cho các lỗi Dài hạn hoặc hệ thống đang quá tải. Càng thử lại càng chết. Circuit Breaker giúp hệ thống có "khoảng lặng" để phục hồi.
   • Kết hợp: Thường ta set Retry 3 lần, nếu cả 3 lần vẫn lỗi trong một khoảng thời gian thì mới trigger Circuit Breaker.

Tóm tắt

Những điều cần nhớ

• CLOSED -> OPEN -> HALF-OPEN.
• Fail-fast giúp giải phóng tài nguyên server.
• Fallback giúp duy trì trải nghiệm người dùng tối thiểu.

Bước tiếp theo

🎉 Chúc mừng! Bạn đã hoàn thành Module 7: Reliability & Performance.

Bạn đã học được các kỹ thuật của "Kiến trúc sư hệ thống":

• Chiến lược Caching đa tầng.
• Rate Limiting bảo vệ tài nguyên.
• Circuit Breakers chống cháy cho Microservices.

Module tiếp theo: Module 8: API Documentation - Viết tài liệu sao cho đồng nghiệp và đối tác "mê mẩn" API của bạn.

Bắt đầu Module 8 →