1. Bối cảnh doanh nghiệp & phạm vi
Một nền tảng giao hàng chặng cuối tại Việt Nam vận hành đội xe gồm 18.000 tài xế hoạt động đồng thời trong giờ cao điểm, xử lý trung bình 60.000 đơn/giờ trên toàn quốc. Khác với bài toán đối soát COD offline, bài toán ở đây là thời gian thực (realtime): mỗi khi một đơn mới phát sinh, hệ thống điều phối (dispatch) phải chọn đúng 1 tài xế phù hợp trong vòng vài giây, đẩy thông báo qua kênh WebSocket tới thiết bị tài xế, và chờ tài xế xác nhận (ACK) trong cửa sổ thời gian ngắn trước khi coi như từ chối và tìm tài xế khác. SLA cam kết với khách hàng là 'gán tài xế trong 30 giây kể từ khi đơn được xác nhận thanh toán' và 'giao hàng trong 45 phút nội thành' — hai chỉ số SLA hoàn toàn khác nhau về bản chất đo lường nhưng cùng phụ thuộc vào chất lượng của engine định tuyến.
Phạm vi tự động hoá
- API/WebSocket gán đơn cho tài xế, luồng ACK/từ chối, timeout tự động chuyển tài xế khác
- SLA clock: đo thời gian gán, thời gian giao, phát hiện breach realtime
- Cân bằng tải (load balancing) giữa các zone/khu vực khi phân bổ tài xế
- Ngoài phạm vi: thuật toán tối ưu tuyến đường chi tiết bằng OR-Tools/bản đồ (do đội Data đảm nhiệm), UI bản đồ tài xế
2. Kiến trúc hệ thống & luồng nghiệp vụ
Kiến trúc gồm 5 thành phần chính: Order Intake (nhận đơn mới, xác định điểm lấy/giao), Routing Engine (tính khoảng cách, thời gian dự kiến, xếp hạng ứng viên tài xế), Assignment Service (giữ trạng thái gán, xử lý ACK/decline/timeout, đảm bảo tính duy nhất bằng lock phân tán), WebSocket Gateway (kênh hai chiều realtime giữ kết nối bền với hàng chục nghìn thiết bị tài xế), và SLA Clock Service (đo thời gian từ lúc đơn sẵn sàng tới lúc gán, và từ lúc gán tới lúc giao, phát cảnh báo khi gần vỡ SLA). Assignment Service dùng Redis với lệnh SET NX (set-if-not-exists) hoặc Lua script nguyên tử để giữ khoá 'orderId đang được gán cho driverId X', tránh race condition khi engine định tuyến trả về nhiều ứng viên gần như đồng thời cho các dispatcher worker khác nhau.
Điểm khó khi kiểm thử
- Realtime + concurrency: nhiều đơn/nhiều tài xế xử lý song song, khó tái lập race condition ổn định
- WebSocket bền kết nối: cần mô phỏng mất kết nối, reconnect, và tin nhắn đến trễ/mất gói
- SLA clock phân tán: đồng hồ đo trên nhiều service phải nhất quán, lệch giờ server (clock skew) gây sai số
- Cân bằng tải giữa zone: khó kiểm chứng 'công bằng' bằng một assertion đơn giản, cần đo phân phối thống kê
3. Mô hình dữ liệu & bất biến nghiệp vụ (oracle)
Thực thể trung tâm là Order với các trường: orderId, pickupZone, status (PENDING_ASSIGN, ASSIGNED, PICKED_UP, DELIVERING, DELIVERED, SLA_BREACHED), createdAt, assignedAt, deliveredAt. Thực thể Assignment ghi nhận mỗi lần hệ thống gán đơn cho tài xế: assignmentId, orderId, driverId, offeredAt, ackedAt (nullable), declinedAt (nullable), expiresAt. Thực thể DriverPresence theo dõi trạng thái realtime của tài xế qua WebSocket: driverId, connectionId, lastHeartbeatAt, currentZone, isAvailable. Cuối cùng, SLABreach ghi nhận mỗi lần một mốc SLA bị vi phạm: breachId, orderId, slaType (ASSIGNMENT hoặc DELIVERY), thresholdSeconds, actualSeconds, detectedAt — đây là dữ liệu dùng để tính KPI vận hành và để QA đối chiếu độ chính xác của SLA clock.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!