Published on
Ngày xuất bản:

Serverless cơ bản 07: Messaging Services (AWS)

Authors
  • avatar
    Name
    Tu Tran

Service A muốn nói chuyện service B, thường sẽ có 2 cách.

Cách 1 đó là service A gọi trực tiếp service B, cách thứ 2 đó là service A gửi yêu cầu đó đến 1 hệ thống được gọi là “messaging service”, từ đó hệ thống này sẽ gửi yêu cầu đến service B.

Ở trong cách 1, nếu chỉ có 2 services thì sẽ không sao, tuy nhiên nếu chúng ta có 100 hay 1000 services gọi trực tiếp lẫn nhau, thì đó sẽ là 1 thảm họa.

Lý do là bởi nếu 1 trong số những services đó xảy ra vấn đề, thì cả hệ thống sẽ bị lỗi. Chính vì vậy, trong thế giới serverless, các service sẽ rất ít khi nói chuyện trực tiếp với nhau mà thay vào đó sẽ thường nói chuyện với nhau thông các “messaging system”.

Dưới đây là 3 messaging services được sử dụng phổ biến:

SQS (Simple Queue Service)

Trước khi tìm hiểu về SQS, chúng ta cần nói đến 1 vài thuật ngữ quan trọng giúp bạn hiểu cũng như có thể từ đó tra khảo thông tin, đọc tài liệu 1 cách dễ dàng hơn.

Ở trong ví dụ được dẫn ở phần mở bài, service A là bên gửi yêu cầu thì sẽ được gọi là “producer”, còn service B là bên tiếp nhận yêu cầu thì sẽ được gọi là “consumer”, và những yêu cầu thì được gọi là “message”

Khi producer xuất ra 1 loạt các messages, các message đó sẽ được lưu ở trong 1 cái bình chứa được gọi “queue”.

Ok. Vậy là xong phần từ vựng. Bây giờ chúng ta sẽ nói đến SQS.

Ở trong thực tế, sẽ có rất nhiều consumer, và mỗi consumer sẽ thường được chỉ định lấy message ra từ 1 queue (hay nói cách khác 1 consumer sẽ xử lý 1 loại message được chứa ở 1 queue cụ thể)

Trong SQS, consumer thường pull (lấy) message thay vì được push (được đẩy cho). 1 option mà trong thực tế thường được sử dụng đó là “long-polling”, hiểu đơn giản consumer sẽ kết nối với SQS và ngồi đợi đến khi nào có message xuất hiện ở trong queue. Nếu bạn sử dụng Lambda function là 1 consumer, “long-polling” option trên sẽ tự động thiết lập cho bạn

Cách tính phí: dựa theo số lượng request (pull/push)

SNS (Simple Notification Service)

Thuật ngữ có 1 chút thay đổi khi chúng ta sử dụng SNS là 1 messaging service. Lúc này service A không được gọi là producer nữa mà sẽ được gọi là “publisher”, còn service B thay vì là consumer thì sẽ được gọi là “subscriber”

Nghe có vẻ khá quen đúng không?

Một ví dụ điển hình cho hệ thống sử dụng mô hình pub-sub này đó chính là Youtube. Giả sử bạn lên Youtube, bạn yêu thích 1 kênh channel nào đó, bạn quyết định đăng ký và ấn vào biểu tượng cái “chuông” để nhận báo.

Như vậy mỗi khi chủ kênh ra video, Youtube sẽ gửi thông báo đến không chỉ bạn mà tất cả những người khác cũng đăng ký giống bạn.

Như vậy ở trong mô hình pub-sub là thì khi publisher gửi ra 1 message thì tất cả các subscriber sẽ nhận được message đó

Với SNS, các bạn có thể gửi message đến nhiều service khác nhau:

  • Lambda function
  • SQS
  • HTTP endpoint
  • mobile phone - thông qua SMS (tin nhắn)
  • mobile app - thông qua push notification
  • email
  • …

Ngoài ra, SNS còn có tính năng filter (lọc) dựa theo thuộc tính có trong message truyền đi, mục đích giúp giới hạn message truyền đi và đảm bảo message được truyền đúng đến nơi cần đến.

Cách tính phí: dựa theo request + delivery (mỗi lần gửi)

EventBridge

EventBridge là 1 “event bus” (xe chở event) nơi chứa các messages (thường được gọi là event) trải dài trong toàn bộ hệ thống. Các event này sẽ được tạo ra dựa theo sự thay đổi trạng thái ở trong các AWS Service, ví dụ bạn muốn trigger (gọi) 1 Lambda function mỗi khi có 1 sự kiện thay đổi nào đó ở trong DynamoDB table. Ngoài ra, bạn hoàn toàn có thể tự tạo message (event) theo nhu cầu thực tế.

Giống như SNS, EventBridge cũng đi theo mô hình pub-sub. Mỗi subscriber sẽ thiết lập rules (luật) nhằm lựa chọn kiểu message nào mà nó muốn tiếp nhận.

Trái ngược với SQS, khi mà consumer thường chỉ tiếp nhận 1 loại message từ 1 queue cụ thể nào đó, thì EventBridge là trung tâm vận chuyển và lưu chứa các messasge, nó là nơi mà bất kỳ publisher nào cũng có thể gửi message đến, và bất kỳ subscriber nào cũng có thể đọc và lấy message đó ra.

Cách tính phí: dựa theo từng custom event (event mà bạn tự thiết lập theo nhu cầu) + số lần kích hoạt subscriber