Posted inDevelopment

Circuit Breaker trong Node.js với Opossum: Đừng để một Service sập kéo sập cả hệ thống

Development tutorial - IT technology blog
Development tutorial - IT technology blog

Lỗi dây chuyền: Khi một quân Domino làm đổ cả hệ thống

Trong kiến trúc Microservices, một hệ thống có 10 service gọi chéo nhau là chuyện bình thường. Nhưng hãy xem xét kịch bản này: API thanh toán của bên thứ ba bỗng nhiên phản hồi chậm mất 10 giây hoặc sập hoàn toàn. Service đặt hàng của bạn vẫn miệt mài gửi request và đứng đợi.

Hệ quả là các worker thread bị chiếm dụng sạch, gây ra tình trạng nghẽn cổ chai. Lúc này, không chỉ thanh toán lỗi mà cả chức năng xem giỏ hàng hay tìm kiếm cũng “ngỏm” theo. Đây chính là cascade failure (lỗi dây chuyền) – kịch bản tồi tệ nhất với dân Backend.

Để ngăn chặn điều này, Circuit Breaker (Mô hình cầu chì) là giải pháp bắt buộc. Nó hoạt động như một chiếc cầu chì điện trong nhà. Khi dòng điện (request) quá tải hoặc gặp sự cố, nó tự ngắt mạch để bảo vệ toàn bộ thiết bị (hệ thống) phía sau khỏi cháy nổ.

Tại sao Timeout và Retry là chưa đủ?

Nhiều bạn thường chỉ dùng hai cách cơ bản để xử lý lỗi dependency, nhưng chúng đều có điểm yếu chí mạng:

1. Cơ chế Retry (Thử lại)

Nếu service đối diện đang quá tải, việc bạn liên tục gửi thêm 3-5 request retry chỉ khiến họ sập nhanh hơn. Nó giống như việc cố đẩy một người đang kiệt sức phải chạy tiếp.

2. Timeout (Thời gian chờ)

Đặt timeout giúp giải phóng tài nguyên sớm hơn. Tuy nhiên, nếu bạn có 1.000 request cùng đợi timeout 5 giây, hệ thống vẫn sẽ tiêu tốn một lượng lớn RAM và CPU để duy trì các kết nối chờ đợi đó.

3. Circuit Breaker (Cầu chì thông minh)

Đây là cơ chế “fail-fast” (thất bại sớm). Thay vì đâm đầu vào một cánh cửa đang đóng, hệ thống sẽ theo dõi tỷ lệ lỗi. Nếu tỷ lệ này vượt ngưỡng (ví dụ 50% lỗi trong 10 giây), nó ngắt mạch (Open) ngay lập tức. Mọi request sau đó sẽ nhận được thông báo lỗi hoặc dữ liệu dự phòng (fallback) mà không cần tốn thời gian gọi đến service đang hỏng.

Đánh giá thực tế: Được và mất

Lợi ích rõ rệt:

  • Cô lập vùng ảnh hưởng: Lỗi ở Service A sẽ không thể lây lan sang Service B.
  • Hệ thống tự phục hồi: Cơ chế Half-Open giúp hệ thống tự động thăm dò và đóng mạch khi service ổn định lại.
  • UX mượt mà hơn: Người dùng nhận được phản hồi “Tính năng tạm bảo trì” ngay lập tức thay vì nhìn icon loading xoay vòng vô tận.

Thách thức:

  • Cấu hình thông số: Việc chọn ngưỡng 50% hay 20% lỗi để ngắt mạch cần dựa trên dữ liệu thực tế (monitoring).
  • Trạng thái dữ liệu: Cần đảm bảo dữ liệu fallback không làm sai lệch logic nghiệp vụ của các bước tiếp theo.

Triển khai Opossum cho dự án Node.js

Trong hệ sinh thái Node.js, Opossum là thư viện tiêu chuẩn nhất hiện nay. Nó nhẹ, hỗ trợ đầy đủ các trạng thái Closed, Open, Half-Open và tích hợp cực tốt với các hàm Async/Await.

Khi cấu hình các option phức tạp cho Opossum, mình thường dùng toolcraft.app/vi/tools/developer/json-formatter để kiểm tra cấu trúc JSON. Việc này giúp tránh các lỗi cú pháp ngớ ngẩn khiến Circuit Breaker hoạt động không đúng ý muốn.

Bước 1: Cài đặt nhanh

npm install opossum

Bước 2: Code mẫu thực chiến

Giả sử bạn cần gọi một service lấy thông tin sản phẩm. Hãy bọc logic đó trong một Circuit Breaker:

const CircuitBreaker = require('opossum');

async function callExternalAPI() {
  // Giả lập gọi API thực tế
  if (Math.random() > 0.7) throw new Error('API sập!');
  return { status: 'success', data: 'Sản phẩm A' };
}

const options = {
  timeout: 3000, // Ngắt nếu API không phản hồi sau 3 giây
  errorThresholdPercentage: 50, // Ngắt mạch nếu trên 50% request thất bại
  resetTimeout: 15000 // Thử kết nối lại sau 15 giây
};

const breaker = new CircuitBreaker(callExternalAPI, options);

// Thiết lập dữ liệu dự phòng (Fallback)
breaker.fallback(() => ({ status: 'fallback', data: 'Dữ liệu từ Cache (Offline)' }));

// Thực thi
breaker.fire()
  .then(console.log)
  .catch(console.error);

Bước 3: Giám sát qua Event

Đừng để Circuit Breaker là một “hộp đen”. Hãy lắng nghe các sự kiện để đẩy log về Grafana hoặc bắn alert vào Slack:

breaker.on('open', () => console.error('--- MẠCH HỞ: Service đang lỗi nặng, dừng gọi! ---'));
breaker.on('close', () => console.info('--- MẠCH ĐÓNG: Service đã khỏe lại, hoạt động bình thường ---'));
breaker.on('halfOpen', () => console.log('--- MẠCH NỬA MỞ: Đang gửi thử request kiểm tra... ---'));

Kinh nghiệm “xương máu” khi vận hành

Dưới đây là 3 lưu ý giúp bạn tránh bị “gậy ông đập lưng ông”:

  • Đừng quá nhạy cảm: Đặt errorThresholdPercentage quá thấp (dưới 20%) có thể khiến mạch nhảy liên tục chỉ vì vài request mạng chập chờn.
  • Chiến lược Fallback thông minh: Đừng chỉ trả về lỗi. Hãy cố gắng trả về dữ liệu cũ trong Cache hoặc một giá trị mặc định để giữ cho luồng người dùng không bị đứt quãng.
  • Bypass cho Health Check: Đảm bảo các route kiểm tra sức khỏe hệ thống (Health Check) không bị Circuit Breaker chặn, nếu không Kubernetes có thể kill nhầm pod của bạn.

Nếu bạn cần xử lý các chuỗi Regex phức tạp để lọc URL cần bypass, hãy dùng các tool online như toolcraft.app để test trước. Việc này giúp tiết kiệm hàng giờ debug so với việc sửa code rồi deploy lại liên tục.

Lời kết

Circuit Breaker không đơn thuần là một kỹ thuật, nó là tư duy bảo vệ hệ thống chủ động. Sử dụng Opossum giúp ứng dụng Node.js của bạn trở nên lì lợm hơn trước các sự cố khách quan. Hãy áp dụng ngay vào những service quan trọng để hệ thống luôn vận hành ổn định, bất kể các service bên thứ ba có “hắt hơi sổ mũi” ra sao.

Share:
Tags: