Synchronous, Asynchronous và Message-driven programming.

Trong bài này, ta hãy cùng nắm ba khái niệm về:

• Asynchronous programming.
• Message-driven programming.
• Message broker.

Synchronous và Asynchronous programming:

Ta lấy 1 ví dụ cho dễ hiểu:

Hôm nay, khi công ty NT bị cúp điện, leader quyết định rủ cả team ra Coffee House để uống nước và bàn công việc. Mọi người trong team nhanh chóng đổ về địa điểm hẹn và tự sắp xếp vào các hàng chờ để đợi đến lượt order. Người đến sau sẽ đứng sau người đến trước, và bất kỳ ai "lấn hàng" sẽ bị yêu cầu rời hàng và phải xếp lại từ đầu. Bên cạnh đó, nếu có ai đó chưa cài đặt ứng dụng đặt hàng trước đó và cần sự hướng dẫn từ nhân viên, việc này sẽ làm chậm quá trình order của cả hàng.

Trong ví dụ này, các nhân viên trong công ty NT có thể được xem là các client, trong khi mỗi nhân viên của quán là các service trong server. Client tương tác trực tiếp với service, đó là hình ảnh của synchronous programming - lập trình đồng bộ. Client phải đợi cho tới khi service xử lý xong request mới có thể thực hiện các thao tác tiếp theo. Như vậy, mấu chốt của synchronous programming không nằm ở số lượng client, số lượng request hay số lượng service mà nằm ở cách client và các service tương tác với nhau.

💡Quản lý đã tăng hiệu suất lên bằng cách:

Sau khi quan sát, quản lý của cửa hàng phải ra quyết định tăng cường thêm nhân viên order và mở thêm các quầy, điều này giúp cải thiện đáng kể tốc độ phục vụ.

⚠️ Nhưng trong thực tế làm việc này là không khả thi, và nó cũng không giải quyết triệt để vấn đề giao tiếp, chờ đợi giữa Service - Client.

Giải pháp khác được đưa ra:

Mỗi khách vào sẽ chỉ cần thông báo với nhân viên những món mà mình muốn order, nhân viên xác nhận. Trong lúc nhân viên nhập và xử lý yêu cầu order thì khách có thể đi tới chỗ ngồi và làm việc khác. Khi order hoàn thành, nhân viên sẽ thông báo khách tới lấy và thanh toán.

Đây là hình ảnh của asynchronous programming. Ta sẽ tách biệt giữa khâu request và response, client và service vẫn có thể tương tác trực tiếp với nhau nhưng không cần chờ đợi nhau.

Chỉ cần service gửi lại tin nhắn đã xác nhận thì client có thể làm việc khác trong thời gian service xử lý yêu cầu. Khi nào xong thì service sẽ thông báo.

🧑🏻💻 Khi tách biệt được hai luồng request và response, ta hoàn toàn có thể thực hiện giao tiếp giữa nhiều service với nhau.

1. Service A gửi request tới service B.
2. Service B nhận được request và gửi response xác nhận.
3. Service A có thể làm những việc khác trong khi service B xử lý.
4. Service B sẽ gửi phản hồi ngược lại service A sau khi xử lý xong,.

🪦 Tuy nhiên phương án này sẽ vẫn gặp phải vấn đề:

1. Nếu các service bị quá tải, bị sập hay từ chối nhận thêm request. Thì client cần phải có cơ chế retry để gửi lại request.
2. Khi mà client muốn order các món khác nhau ở tại nhiều cửa hàng khác nhau trong hệ thống thì sẽ phải gửi order tới từng cửa hàng.

Message-driven programming:

💡 Đối với trường hợp này sau khi trao đổi với các chuyên gia thì lựa chọn sử dụng dịch vụ bên thứ ba, cụ thể ở đây là dịch vụ SMS.

Khách hàng sẽ order qua hệ thống SMS, hệ thống xử lý và gửi request tới các cửa hàng, nhân viên để thực hiện nhiệm vụ. Điều này có lợi thế là nếu cửa hàng này đóng cửa thì sẽ có cửa hàng khác, hoặc nếu muốn thử nước hoặc bánh ở các cửa hàng khác nhau thì cũng chỉ cần liệt kê ra danh sách và đặt nó vào trong một request. Nhiệm vụ còn lại là việc của hệ thống SMS. Trên thực tế đã có những ứng dụng áp dụng phương pháp này như: Grab, Beamin, Now,…

Message-driven programming giúp các service và client không cần tương tác trực tiếp với nhau. Tất cả request sẽ được gửi dưới dạng message cho bên thứ ba. Bên thứ ba sẽ có nhiệm vụ điều hướng message đến địa chỉ cụ thể với hai mục tiêu:

• Đảm bảo message được gửi thành công.
• Gửi đến đúng địa chỉ.

Message Broker:

Với ví dụ trên, ta thấy rằng hệ thống SMS có chức năng là điều hướng, trung chuyển message từ người gửi tới người nhận với 4 ưu điểm chính:

• Giảm tải cho các service bằng việc giảm tương tác trực tiếp.
• Lưu trữ request, trong trường hợp server gặp sự cố.
• Có khả năng phân phối request tới nhiều service.
• Đơn giản hóa quá trình gửi nhận message trong môi trường multi-services.

Message distribution patterns:

Message Broker cung cấp 2 pattern chính để xử lý việc điều hướng message:

• Point to point messaging (Queue): là dạng phân phối message giữa 1 client và 1 địa chỉ service duy nhất.
• Broadcast messaging: một message có thể được gửi tới nhiều địa chỉ khác nhau, nhưng ai subscribe mới có thể thấy được tin nhắn. Pattern đó là topic.

Tóm lại:

• Nhắn tin giữa 2 người ta sử dụng Queue:
• Nhắn tin giữa nhiều người trong group ta sẽ sử dụng topic.

Mô hình sử dụng Message broker:

Không còn khái niệm Client và Server mà thay vào đó sẽ là producer/publisher và consumer/subscriber. Về bản chất nó vẫn là một bên gửi một bên nhận.

• Producer/Publisher: Nơi gửi message.
• Consumer/Subscriber: Nơi nhận message.
• Message Broker: hệ thống điều hướng message.

Tổng kết:

Ta thấy rằng hệ thống message broker có nhiều ưu điểm trong quá trình gửi và nhận message cùng với sử đảm bảo message được đi tới đích. Với những ưu điểm như vậy Apache Kafka được ra đời với hiệu suất mạnh mẽ và sự an toàn cho dữ liệu.

Reference:

[1]. Dat Bui (August, 8 2021) Message-driven programming với Message broker và Apache Kafka