Chuẩn bị timeout và retry cho dịch vụ phụ thuộc bên ngoài

Dịch vụ bên ngoài chậm và ứng dụng phải chờ. Thêm retry có vẻ là cách nhanh để tăng độ tin cậy, nhưng các lần thử có thể tăng tải hoặc lặp tác động nghiệp vụ. Hãy quyết định khách hàng được chờ bao lâu và hệ thống làm gì khi hết ngân sách thời gian đó.

Phân biệt chờ với kết quả nghiệp vụ

Timeout phía gọi chỉ cho ứng dụng biết thời gian chờ đã hết. Nó không chứng minh thao tác từ xa đã dừng hoặc chưa bắt đầu. Nên có trạng thái rõ cho chưa thử, xác nhận thành công, xác nhận thất bại và chưa rõ kết quả. Bộ phận hỗ trợ cần phân biệt chúng để không khởi động lại công việc đã xong.

HTTP khuyến cáo không tự động thử lại phương thức không idempotent, trừ khi phía gọi biết ngữ nghĩa yêu cầu là idempotent hoặc xác định được yêu cầu chưa được áp dụng.[2] Áp dụng quy tắc cho thao tác thực tế. Cơ chế idempotency của nhà cung cấp có thể hỗ trợ, nhưng vẫn cần xem phạm vi, thời gian lưu và hành vi khi lỗi.

Phân bổ hạn chót tổng thể

Đặt ngân sách cho toàn bộ thao tác khách hàng, rồi phân bổ thời gian kết nối, nhận phản hồi và xử lý trong đó. Không chọn từng timeout độc lập. Chừa thời gian trả kết quả dễ hiểu hoặc lưu công việc để xử lý sau.

Nên chỉ có một tầng chịu trách nhiệm thử lại. Nếu ứng dụng, thư viện gọi và tiến trình nền đều thử lại độc lập, số lần gọi có thể nhân lên. Kiểm tra mặc định trước khi thêm chính sách. Dùng số lần thử hữu hạn, khoảng chờ tăng dần và độ lệch ngẫu nhiên khi phù hợp. Khoảng chờ phải nằm trong ngân sách còn lại, và hệ thống nên dừng nếu lần tiếp theo không còn đủ thời gian hoàn tất có ý nghĩa.

Đặt chính sách riêng cho yêu cầu tương tác và khôi phục nền. Màn hình khách hàng có thể ngừng chờ trong khi tác vụ khôi phục có người phụ trách vẫn tiếp tục. Tuy nhiên, trạng thái hiển thị phải phản ánh rõ sự khác biệt đó, không báo thất bại cuối cùng quá sớm.

Phân loại trước lần thử tiếp theo

Tách lỗi dữ liệu và phân quyền khỏi lỗi tạm thời của dịch vụ phụ thuộc. Ngay cả phản hồi lỗi tạm thời cũng không kết luận việc lặp thao tác ghi có an toàn không. Tuân thủ hướng dẫn nhà cung cấp. Retry-After có thể là ngày HTTP hoặc số giây chờ, nên phía gọi dùng chung không được chỉ giả định một định dạng.[2]

• Ghi một hạn chót tổng và các timeout thành phần.
• Chỉ định nơi duy nhất phụ trách thử lại và tắt mặc định xung đột.
• Kiểm thử phản hồi chậm, mất kết nối và mất phản hồi sau thực thi.
• Quy định tra cứu trạng thái hoặc đối soát cho kết quả ghi chưa rõ.

Ví dụ giả định: yêu cầu nhãn vận chuyển

Ví dụ giả định: ứng dụng vận chuyển yêu cầu hãng giao nhận tạo nhãn. Hãng nhận lô hàng nhưng phản hồi bị mất. Ứng dụng giữ mã tham chiếu lô hàng và đánh dấu yêu cầu nhãn chưa rõ kết quả thay vì tạo lô hàng khác.

Tiến trình khôi phục tra cứu hãng trước khi quyết định có nên gửi yêu cầu tiếp không. Cách này có thể làm chậm nhãn và cần hàng đợi ngoại lệ dễ thấy nếu hãng không có chức năng tra cứu. Dừng nhanh không phải lúc nào cũng phục vụ khách hàng tốt hơn. Bước tiếp theo là kiểm thử lỗi để chứng minh người dùng thấy gì và nhân viên vận hành khôi phục được gì khi phản hồi biến mất.