Tạm biệt REST API "nghẽn mạch": Tại sao Event-Driven với Kafka là tương lai của Microservices?

Tấm ảnh này chính là "chìa khóa" giải mã sự khác biệt giữa một hệ thống Microservices chạy theo kiểu "cưỡng ép" (Tight Coupling) và một hệ thống hiện đại, linh hoạt theo kiểu Event-Driven Architecture.

Nếu ở bài trước chúng ta đã thấy Kafka là "hệ thần kinh", thì tấm ảnh này giải thích tại sao chúng ta nên dùng "hệ thần kinh" đó thay vì cứ nhấc máy lên gọi điện trực tiếp cho nhau mỗi khi có việc. Hãy cùng mình phân tích sâu hơn nhé!

1. Nỗi đau của việc gọi REST API trực tiếp (The Synchronous Pain)

Hãy nhìn vào những dấu X đỏ trong ảnh. Đó là kịch bản cũ: Khi một User đăng ký tài khoản thành công, Account Service phải thực hiện 2 cuộc gọi REST API:

1. Gọi sang Notification Service để gửi email chào mừng.
2. Gọi sang Statistic Service để cập nhật số lượng user mới.

Vấn đề là gì?

• Hiệu ứng domino (Cascading Failure): Nếu Notification Service bị sập hoặc phản hồi chậm, Account Service cũng sẽ bị "treo" theo để đợi kết quả. User đứng chờ xoay vòng vòng chỉ vì một cái email chưa gửi được.
• Sự phụ thuộc (Tight Coupling): Mỗi khi bạn muốn thêm một tính năng mới (ví dụ: Service tặng quà cho user mới), bạn lại phải vào code của Account Service để sửa và thêm một cú gọi API nữa. Cực kỳ mệt mỏi và dễ sinh bug!

2. "Cứu tinh" Kafka: Cơ chế Publish - Subscribe

Thay vì gọi trực tiếp, Account Service lúc này chuyển sang vai trò một Producer. Việc của nó chỉ là: "Tôi vừa tạo xong tài khoản này, thông tin đây, tôi quăng lên Kafka nhé!".

Nó không cần quan tâm ai sẽ đọc tin đó, Notification Service có đang sống hay không, hay hệ thống có thêm bao nhiêu service mới. Nó chỉ cần thực hiện đúng một hành động Publish Event rồi quay lại phục vụ user ngay lập tức.

3. Sức mạnh của sự "Vô cảm" (Decoupling)

Ở phía bên phải, chúng ta có các Consumers (Notification và Statistic Services). Chúng hoạt động hoàn toàn độc lập:

• Notification Service: "Lắng nghe" Kafka, thấy có event tạo tài khoản là bốc về gửi mail. Nếu nó bận? Nó cứ để event nằm đó trong Kafka, lúc nào rảnh thì xử lý sau. User không phải đợi!
• Statistic Service: Cũng "lắng nghe" cùng một event đó để tăng con số thống kê. Hai service này không hề biết đến sự tồn tại của nhau.

4. Tại sao mô hình này lại "đỉnh" hơn?

1. Tính sẵn sàng cao (High Availability): Nếu Statistic Service bảo trì 2 tiếng, dữ liệu vẫn nằm an toàn trong Kafka. Khi sống lại, nó chỉ cần đọc tiếp từ vị trí cũ. Không có dữ liệu nào bị mất.
2. Khả năng mở rộng (Scalability): Bạn muốn thêm 10 service nữa để xử lý dữ liệu từ Account Service? Cứ việc! Bạn không cần sửa một dòng code nào ở Account Service cả.
3. Tối ưu trải nghiệm User: Thời gian phản hồi (Response Time) của API tạo tài khoản sẽ nhanh hơn đáng kể vì nó không còn phải đợi các service "vệ tinh" hoàn thành công việc.

Lời kết

Việc chuyển từ Direct Call (REST) sang Event-Driven (Kafka) giống như việc bạn chuyển từ việc phải gọi điện thoại trực tiếp cho từng người (mất thời gian và phụ thuộc) sang việc đăng một thông báo lên bảng tin công ty. Ai cần thì tự đến đọc và xử lý.