5-year Evolution of Ele.me's Transaction System - Part 5

Bài tóm tắt Ele.me 2020 3. Quy mô lớn Độ khó: Trung bình

Ele.me · 2020 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 5/6. Trước: Ele.me 2020; sau: Ele.me 2020.

Thay đổi chính

  • Sự cố RabbitMQ: test hiệu năng cho thấy throughput ổn, nhưng thực tế CPU cao tới mức kích hoạt cơ chế tự bảo vệ của RabbitMQ, chặn producer. Gốc nằm ở client RabbitMQ do một phòng khác tự đóng gói, dùng sai chế độ get/fetch và prefetch_count.

    • Liên quan tới đơn hàng vì cụm dùng chung: đơn hàng, vận đơn, merchant chỉ tách bằng virtual host.
    • Ngay hôm đó, trưởng phòng vận hành yêu cầu dựng cụm broadcast riêng cho đơn hàng (7 node).
    • Một năm sau, cụm này chạm trần không scale thêm được, vì consumer lọc message ở local thay vì dùng routing của RabbitMQ. Theo tác giả, thiếu quản trị và chuẩn dùng chung thì hiệu năng sẽ xuống.
  • Hệ "bữa sáng" mượn pipeline giao dịch: một bộ phận đổi mới dựng nguyên mẫu e-commerce riêng nhưng mượn luồng thanh toán của mảng giao đồ ăn. Pre-production và production chưa tách hẳn; có lần task bất đồng bộ của production bị kéo sang PPE rồi không ai xử lý, làm đơn bị huỷ.

  • Hệ đơn hàng "ảo" cho thẻ thành viên bán online (đầu 2016), dùng để thử kiến trúc mới trên nghiệp vụ ít traffic:

    • mô hình trạng thái tối giản;
    • tách bảng giao dịch thành bảng cơ bản (người mua, người bán, trạng thái, loại nghiệp vụ, số tiền) và bảng mở rộng (sản phẩm, khuyến mãi, liên hệ);
    • theo tác giả, "hệ càng quan trọng càng phải đơn giản".

    Kết quả: nghiệp vụ mới tích hợp trong 2–3 ngày, ra mắt trong khoảng một tuần, là nguyên mẫu của một PaaS giao dịch. Bài học sau đó: phải ràng buộc cấu trúc dữ liệu ở bảng mở rộng, nếu không quản trị rất khó.

Bài học cho SWE

Liên quan