6 Event-Driven Architecture Patterns — Part 1
Bài tóm tắt Wix 2020 3. Quy mô lớn Độ khó: Trung bình
Wix · 2020 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Phần 1/2, tác giả thuộc team data-streams (hạ tầng messaging trên Kafka cho hơn 1.400 microservice, 2020). Phần 2: Wix 2020.
Bối cảnh
Team data-streams của Wix lo hạ tầng event-driven trên Kafka cho hơn 1.400 microservice (2020). Bài là ba mẫu dùng thực tế ở Wix, mỗi mẫu một use case.
Thay đổi chính
- Consume and Project (cho service "phổ biến" thành nút thắt):
- service MetaSite giữ metadata của mọi site (phiên bản, chủ, app đã cài) và nhận hơn 1 triệu request/phút từ nhiều team (Stores, Bookings, Restaurants...); API của nó gánh quá nhiều mối quan tâm của client;
- stream mọi object metadata (tạo, sửa) lên một topic Kafka; tính nhất quán có được nhờ ghi DB bên trong consumer, hoặc dùng CDC (Debezium);
- một service chỉ ghi consume topic, lấy riêng phần "Installed Apps" rồi ghi vào DB của nó (một materialized view); một service chỉ đọc phục vụ đúng loại request đó.
- Kết quả: MetaSite tách khỏi consumer, tải lên service và DB giảm mạnh; phía đọc scale bằng thêm replica và instance ở nhiều data center.
- Event-driven từ đầu tới cuối (cập nhật trạng thái luồng nghiệp vụ):
- ví dụ import danh bạ: trình duyệt subscribe vào service websocket với một channel-Id, gửi CSV kèm channel-Id tới jobs service, nhận response rỗng ngay;
- jobs service đẩy job lên Kafka, importer consume và làm, xong thì báo service websocket, service này báo trình duyệt.
- Không cần poll, không cần bảng trạng thái; message nằm trong Kafka nên xử lý lại được khi service restart; replication của Kafka cho phép đặt mỗi stage ở data center hợp nhất.
- KV store trong RAM bằng compacted topic (cấu hình động nhưng bền, latency 0):
- compacted topic giữ giá trị mới nhất của mỗi key; app đọc toàn bộ topic lúc khởi động vào RAM;
- lợi thế so với Redis AOF: consumer khác cũng subscribe được thay đổi. Ví dụ Bookings nghe topic "các nước được hỗ trợ" của Business Manager để tự thêm múi giờ vào topic của mình, rồi Wix Events nghe tiếp topic múi giờ.
Vì sao (theo Wix)
Đọc tách khỏi ghi theo kiểu eventually consistent để gỡ nút thắt mà không bắt service gốc gánh mọi kiểu truy vấn; luồng dài chạy bằng event để bền khi restart và không cần trạng thái ở front-end.
Bài học cho SWE
- Service bị đọc dồn: phát thay đổi lên log rồi dựng view đọc riêng cho từng nhu cầu (CQRS); một dạng của scale đọc (Scale dọc trước khi scale ngang).
- Luồng nghiệp vụ dài thì trả response ngay và đẩy tiến độ qua websocket, thay cho poll (Event-driven, message queue và Kafka).
- Compacted topic làm KV trong RAM chỉ hợp với dữ liệu nhỏ: hai năm sau chính Wix gặp giới hạn khởi động pod chậm khi topic lớn (Wix 2022).
Liên quan
Được nhắc tới trong
Công ty (1)