Xin chào. Tôi là Lee Ji-min đến từ đội Vertical Engineering. Nền tảng du lịch của Gmarket cung cấp dịch vụ bằng cách tích hợp hệ thống thương mại của Gmarket với API từ máy chủ của các đối tác OTA (Đại lý du lịch trực tuyến). Do có sự phụ thuộc cao vào nhiều máy chủ khác nhau, độ phức tạp của dịch vụ là rất lớn.
Đặc biệt, các lĩnh vực kinh doanh đòi hỏi kết nối API thời gian thực và cuộc gọi API bền bỉ bao gồm:
Trang chi tiết sản phẩm du lịch
Đặt chỗ thời gian thực (Real-time Reservation)
(1) Trang chi tiết sản phẩm du lịch
Đây là màn hình đòi hỏi tính chịu lỗi (Fault Tolerance) cao. Một trang chi tiết sản phẩm cần sự phối hợp của hơn 10 API từ nhiều đội ngũ và công ty khác nhau.
Các lưu ý khi kết nối API:
Thiết lập Timeout theo từng trường hợp (Case-by-case): Cần cân nhắc giữa "Độ quan trọng" và "Thời gian phản hồi trung bình". Với các API ít quan trọng, cần đặt timeout ngắn để tránh kéo sập toàn bộ trang. Ngược lại, với API giá và kho hàng (vốn đòi hỏi tính toán phức tạp theo ngày/giờ/độ tuổi), hệ thống cần kiên nhẫn chờ phản hồi lâu hơn.
Fallback - "Giả vờ như không có lỗi": Khi một API gặp sự cố (ví dụ: API giá khuyến mãi), hệ thống có thể tạm thời hiển thị giá gốc thay vì báo lỗi toàn trang. Công cụ
resilience4jthường được dùng để xử lý việc này một cách dễ dàng.
(2) Đặt chỗ thời gian thực
Quy trình này phải đảm bảo Tính nhất quán cuối cùng (Eventual Consistency) và Tính lũy đẳng (Idempotency) vì nó liên quan trực tiếp đến giao dịch tiền tệ và quyền lợi dịch vụ của khách hàng.
Các lưu ý khi kết nối API:
Xây dựng Máy trạng thái (State Machine): Giúp đơn giản hóa quá trình kết nối trạng thái phức tạp và tăng khả năng tái sử dụng hàm đồng bộ hóa giữa các hệ thống (Gmarket - OTA).
Xây dựng Batch đối soát (Reconciliation Batch): Một chương trình đóng vai trò điều phối sẽ kiểm tra trạng thái của các hệ thống. Nếu có sự sai lệch do sự cố tạm thời, nó sẽ kích hoạt lại máy trạng thái để đưa về trạng thái thống nhất cuối cùng.
Thử lại (Retry) dựa trên tính lũy đẳng: Khi xảy ra lỗi mạng nhưng phía đối tác đã xử lý thành công, việc gọi lại API có thể gây ra yêu cầu trùng lặp. Cần xử lý ngoại lệ để nhận biết các mã lỗi "yêu cầu trùng lặp" là một kết quả thành công, hoặc sử dụng API truy vấn trạng thái để kiểm tra trước khi thử lại.
Giao dịch bù đắp (Compensation Transaction): Nếu không thể giải quyết bằng cách thử lại, cần đưa dữ liệu về trạng thái ban đầu. Để xử lý mượt mà, nên kết nối các hệ thống khó kiểm soát (như OTA có phí hủy) ở bước cuối cùng của quy trình.
0 Comments
Happy new year !