Circuit breaker là cơ chế tạm ngừng gọi một dịch vụ phụ thuộc đang có dấu hiệu lỗi, thay vì để mọi yêu cầu tiếp tục chờ rồi thất bại. Nó hữu ích khi một API chậm làm cạn tài nguyên của cả ứng dụng. Tuy nhiên, ngắt mạch không sửa được dữ liệu sai và cũng không cho phép màn hình báo thành công khi thao tác chưa thực hiện.
Circuit breaker khác retry ở đâu?
Retry thử lại một thao tác trong điều kiện được cho là tạm thời. Breaker quyết định có nên tiếp tục gọi phụ thuộc hay không, dựa trên tình trạng quan sát được. Hai cơ chế có thể phối hợp, nhưng nếu mỗi tầng đều thử lại nhiều lần, lưu lượng tổng vẫn có thể tăng mạnh trước khi mạch mở. Cần xác định tầng nào sở hữu retry và tầng nào sở hữu breaker.
Mẫu Azure mô tả ba trạng thái Closed, Open và Half-open. Closed cho phép gọi bình thường; Open chặn gọi trong thời gian hoặc điều kiện đã đặt; Half-open cho phép lượng thử hạn chế để đánh giá phục hồi. Các ngưỡng phải phù hợp hệ thống thật, không lấy một con số trên mạng làm tiêu chuẩn cho mọi dịch vụ.
Không tính mọi lỗi vào cùng một bộ đếm
Mật khẩu sai, đơn hàng không đủ tồn kho và dịch vụ mất kết nối là những vấn đề khác nhau. Nếu lỗi dữ liệu người dùng cũng mở breaker chung, một nhóm request không hợp lệ có thể làm gián đoạn những người còn lại. Hãy phân loại lỗi theo hợp đồng API và bằng chứng vận hành, đồng thời chú ý việc nhiều endpoint dùng chung một phụ thuộc nhưng có mức ảnh hưởng khác nhau.
| Tình huống | Cần xem xét | Không nên mặc định |
|---|---|---|
| Lỗi kết nối lặp lại | Tính vào trạng thái phụ thuộc | Retry vô hạn |
| Dữ liệu bị từ chối | Trả người dùng sửa | Mở mạch toàn dịch vụ |
| Quyền truy cập hết hạn | Xử lý cấu hình/xác thực | Coi như mạng chập chờn |
| Đọc dữ liệu cũ | Tuổi dữ liệu và thông báo | Gọi đó là dữ liệu hiện tại |
Ví dụ giả định: tra cứu vận chuyển và chốt đơn
Ứng dụng bán hàng gọi API vận chuyển để tính phí. Khi phụ thuộc không đáp ứng, trang xem trạng thái có thể hiển thị dữ liệu đã lưu kèm thời điểm cập nhật. Nhưng màn hình chốt phí vận chuyển không nên dùng giá cũ rồi báo đơn đã được xác nhận như bình thường. Một fallback hợp lý có thể là lưu yêu cầu chờ xác nhận phí, với trạng thái rõ ràng và người chịu trách nhiệm tiếp nhận.
Cùng một sự cố, hành vi dự phòng khác nhau theo tác động nghiệp vụ. Cần viết bảng endpoint–fallback–hệ quả trước khi lập trình. Nếu không có phương án dự phòng đáng tin, phản hồi lỗi rõ ràng thường tốt hơn một kết quả có vẻ hợp lệ nhưng sai. Ví dụ này không mô tả tính năng đã được Onter triển khai cho khách hàng.
Mở lại bằng tín hiệu, không chỉ bằng đồng hồ
Hết thời gian chờ không chứng minh dịch vụ đã khỏe. Half-open cần giới hạn số yêu cầu thử, xác định loại kết quả được coi là phục hồi và điều kiện quay lại Open. Với nhiều instance, hãy xem bộ đếm nằm ở từng instance hay chia sẻ; không giả định mọi instance sẽ chuyển trạng thái đồng thời.
Yêu cầu thử cũng có thể tạo tác động. Không dùng một lệnh tạo đơn hoặc trừ tiền chỉ để kiểm tra dịch vụ sống. Nếu có endpoint kiểm tra phù hợp, cần biết nó phản ánh phần nào của hệ thống; một health check thành công chưa chắc chứng minh đường ghi dữ liệu nghiệp vụ đã hoạt động. Log nên ghi chuyển trạng thái và nguyên nhân có chọn lọc, tránh đổ toàn bộ payload.
Đưa gì vào tiêu chí nghiệm thu?
Chuẩn bị các tình huống lỗi liên tiếp, phục hồi một phần, kết quả thử thất bại và nhiều người dùng cùng truy cập. Theo dõi thời gian phản hồi của ứng dụng, số cuộc gọi thực sự đến phụ thuộc và cách màn hình mô tả trạng thái. Chỉ đánh dấu đạt khi có lần chạy và bằng chứng thật; bảng tình huống ở đây là hướng dẫn chuẩn bị.
Nếu cần Onter khảo sát một tích hợp đang gây nghẽn, hãy mang theo bản đồ phụ thuộc và một cửa sổ log đã che dữ liệu nhạy cảm. Câu hỏi hữu ích không chỉ là “có thêm circuit breaker được không”, mà là thao tác nào được chặn, người dùng nhìn thấy gì và ai xử lý những yêu cầu chưa hoàn tất.
Đọc thêm theo vấn đề liên quan: API trả 429: đặt ngân sách retry để không làm nghẽn hàng chờ.
Đọc thêm theo vấn đề liên quan: Dead-letter queue: phát lại công việc lỗi mà không tạo thêm sự cố.
Trao đổi phạm vi phát triển và tích hợp tại dịch vụ gia công phần mềm Onter. Tài liệu mẫu cần được che thông tin nhạy cảm trước khi chia sẻ.
Nguồn kỹ thuật
Tài liệu chính thức cho chủ đề circuit breaker. Quy trình, bảng kiểm và ví dụ trong bài là đề xuất biên tập; chưa phải log triển khai hay chứng nhận sản phẩm.
