Request - Response

Trong mô hình này, một Service gửi một request (yêu cầu) đến một Service khác , và chờ đợi một response (phản hồi).

Ưu điểm:

• Đơn giản, dễ hiểu: Gửi yêu cầu – Nhận phản hồi.

• Dễ debug

Nhược điểm:

• Phụ thuộc lẫn nhau: Nếu Service B chậm hoặc lỗi thì Service A phải chờ hoặc lỗi luôn.

• Khó mở rộng (Scalability): Khi có thêm Service D thì phải thiết lập để service A kết nối tới Service D.

• Khả năng chịu lỗi kém (Reliability)

• Giao tiếp đồng bộ phải chờ thời gian hoàn thành.

Message Broker

Message Broker là một trung gian giúp các ứng dụng, hệ thống hoặc dịch vụ giao tiếp với nhau thông qua việc trao đổi thông điệp (messages). Nó đảm bảo việc truyền tải thông điệp giữa các thành phần một cách đáng tin cậy, hiệu quả.

Ưu điểm

1️⃣ Asynchronous Communication (Giao tiếp bất đồng bộ)

• Trong mô hình request-response truyền thống, dịch vụ A phải chờ dịch vụ B phản hồi mới tiếp tục xử lý. Điều này gây ra độ trễ và ảnh hưởng đến hiệu suất tổng thể.

• Với Message Broker, dịch vụ A chỉ cần gửi tin nhắn vào broker và tiếp tục làm việc khác. Dịch vụ B có thể xử lý khi có thời gian, không làm chậm hệ thống.

2️⃣ Decoupling (Tách biệt các thành phần hệ thống)

• Nếu dịch vụ A gọi trực tiếp dịch vụ B qua HTTP, chúng sẽ bị ràng buộc với nhau. Nếu B thay đổi API hoặc gặp sự cố, A cũng bị ảnh hưởng.

• Message Broker giúp các service không cần biết nhau, chỉ cần gửi và nhận tin nhắn từ hàng đợi. Điều này giúp việc bảo trì và mở rộng hệ thống dễ dàng hơn.

3️⃣ Scalability (Dễ dàng mở rộng hệ thống)

Với Message Broker, bạn có thể mở rộng số lượng service dễ dàng bằng cách thêm nhiều consumer để xử lý tin nhắn từ hàng đợi.

🔹 Pub/Sub Pattern (Mô hình xuất bản/đăng ký)

• Một service có thể gửi một thông báo, và nhiều service khác có thể đăng ký nhận nó.

• Ứng dụng: Hệ thống thông báo, cập nhật trạng thái trong microservices.

🔹 Cơ chế Fanout

• Một tin nhắn từ publisher có thể được gửi đến nhiều consumer.

• Ứng dụng: Khi người dùng đăng bài trên mạng xã hội, tin nhắn có thể gửi đến các service khác nhau như thông báo, feed, tìm kiếm, v.v.

4️⃣ Reliability (Độ tin cậy cao & Giảm tải hệ thống đích)

Hệ thống có thể tiếp nhận lượng lớn tin nhắn mà không gây quá tải cho các service phía sau nhờ các cơ chế:

🔹 Rate Limiting (Giới hạn tốc độ xử lý)

• Message Broker có thể điều tiết lượng request đến service đích, tránh tình trạng quá tải.

• Ứng dụng: API Gateway có thể đẩy request vào queue để xử lý tuần tự thay vì cho phép tất cả request đi trực tiếp đến backend.

🔹 Message Queue (Hàng đợi tin nhắn)

• Nếu service đích bị lỗi hoặc quá tải, Message Queue vẫn lưu tin nhắn lại để xử lý sau.

• Ứng dụng: Hệ thống xử lý thanh toán, nếu gateway gặp lỗi, đơn hàng vẫn được lưu trong queue và thử lại sau.

Nhược điểm

1️⃣ Complexity (Độ phức tạp cao hơn)

• Khi sử dụng Message Broker, bạn phải triển khai và quản lý thêm một thành phần trung gian trong hệ thống.

• Nếu team chưa có kinh nghiệm về RabbitMQ, Kafka, ActiveMQ, việc cài đặt, giám sát, và xử lý lỗi có thể là một thách thức.

2️⃣ Latency (Tăng độ trễ chuyển tin nhắn)

• Trong mô hình request-response, dịch vụ nhận phản hồi ngay lập tức. Nhưng với Message Broker, tin nhắn phải đi qua một trung gian, có thể làm tăng độ trễ.

3️⃣ Operational Overhead (Chi phí vận hành tăng cao)

• Bỏ thêm chi phí và công sức vận hành.