M02.08 - Messaging and Queuing

Bạn có bao giờ tự hỏi làm thế nào các coffee shops bận rộn giữ mọi thứ chạy trơn tru, ngay cả khi barista đang nghỉ giải lao hoặc cashier bị quá tải? Vâng, các nguyên tắc tương tự áp dụng cho software architecture. Trong bài học này, bạn sẽ tìm hiểu cách messaging và queuing giúp ngăn chặn slowdowns và failures.

Trong coffee shop, có các cashiers nhận đơn hàng từ khách hàng và các baristas làm đơn hàng. Hiện tại, cashier nhận đơn hàng, viết nó xuống bằng bút và giấy, và giao đơn hàng này cho barista. Barista sau đó lấy giấy và làm đơn hàng. Khi đơn hàng tiếp theo đến, quy trình lặp lại. Điều này hoạt động tốt, miễn là cả cashier và barista đều đồng bộ.

Mục tiêu học tập

Sau khi hoàn thành bài học này, bạn sẽ có thể:

• ✅ Mô tả cách Amazon Simple Queue Service (Amazon SQS) tạo điều kiện cho message queuing
• ✅ Giải thích cách Amazon Simple Notification Service (Amazon SNS) sử dụng publish-subscribe model để phân phối messages
• ✅ Xác định sự khác biệt giữa tightly coupled và loosely coupled architectures
• ✅ Giải thích cách message queues giúp cải thiện communication giữa các components

Vấn đề với Tightly Coupled Architecture

Nhưng điều gì sẽ xảy ra nếu cashier nhận đơn hàng, quay lại để chuyển nó cho barista, và barista đang nghỉ giải lao hoặc bận với đơn hàng khác? Vâng, cashier đó sẽ bị kẹt cho đến khi barista sẵn sàng nhận đơn hàng. Và, tại một thời điểm nhất định, đơn hàng có thể sẽ bị bỏ qua để cashier có thể phục vụ khách hàng tiếp theo.

Bạn có thể thấy đây là một quy trình có lỗi, vì ngay khi cashier hoặc barista mất đồng bộ, quy trình sẽ suy giảm. Điều này sẽ gây ra slowdowns trong việc nhận đơn hàng—và failures để hoàn thành đơn hàng hoàn toàn.

Giải pháp: Message Queue

Một quy trình tốt hơn nhiều sẽ là giới thiệu một số loại buffer hoặc queue vào hệ thống. Thay vì giao đơn hàng trực tiếp cho barista, cashier sẽ đăng đơn hàng lên một order board.

Ý tưởng đặt messages vào một buffer được gọi là messaging và queuing. Giống như cashier của chúng ta gửi đơn hàng cho barista, applications gửi messages cho nhau để giao tiếp.

Tightly Coupled vs Loosely Coupled Architectures

Tightly Coupled Architecture

Nếu applications giao tiếp trực tiếp, giống như cashier và barista trước đây, đó được gọi là tightly coupled. Một đặc điểm nổi bật của tightly coupled architecture là: Nếu một single component thất bại hoặc thay đổi, nó gây ra vấn đề cho các components khác hoặc thậm chí toàn bộ hệ thống.

Ví dụ, Application A đang gửi messages trực tiếp đến Application B. Nếu Application B có một failure và không thể chấp nhận những messages đó, Application A sẽ bắt đầu thấy errors, cũng vậy.

Loosely Coupled Architecture

Nếu chúng ta thiết kế application để sử dụng một loosely coupled architecture hơn, nó có thể trông như thế này.

Giống như cashier và barista của chúng ta, chúng ta đã giới thiệu một buffer giữa hai bên. Trong trường hợp này, chúng ta đã giới thiệu một message queue. Messages được gửi vào queue bởi Application A và được xử lý bởi Application B. Nếu Application B thất bại, Application A không gặp bất kỳ gián đoạn nào. Messages đang được gửi vẫn có thể được gửi vào queue và sẽ ở đó cho đến khi chúng được xử lý cuối cùng.

Đây là loosely coupled. Đây là những gì chúng ta phấn đấu đạt được với architectures trên AWS.

Key Takeaways: Decoupling Services

Trong modern application development, reliability và resilience là quan trọng. Một cách hiệu quả để đạt được điều này là bằng cách áp dụng một service-oriented approach.

Monolithic Applications

Applications bao gồm nhiều components làm việc cùng nhau để truyền dữ liệu, fulfill requests, và giữ application chạy trơn tru. Trong một traditional approach đến application architecture, các components—như database logic, web application servers, user interfaces, và business logic—là tightly coupled. Điều này có nghĩa là nếu một component thất bại, nó có thể gây ra failure của các components khác, có khả năng làm sập toàn bộ application.

Microservices Architecture

Để cải thiện application availability và resilience, bạn có thể áp dụng một microservices architecture. Trong cách tiếp cận này, application components là loosely coupled, có nghĩa là nếu một component thất bại, các components khác tiếp tục hoạt động bình thường. Communication giữa các components vẫn nguyên vẹn, và failure của một single component không ảnh hưởng đến toàn bộ hệ thống. Thiết kế này thúc đẩy flexibility và reliability lớn hơn trong application.

Supporting Scalable and Reliable Cloud Communication

Amazon EventBridge, Amazon SNS, và Amazon SQS là các AWS services giúp các phần khác nhau của một application giao tiếp hiệu quả trong cloud. Các services này hỗ trợ xây dựng event-driven và message-based systems. Cùng nhau, chúng giúp tạo ra các applications scalable, reliable có thể xử lý high traffic và có thể nâng cao communication giữa các components.

Amazon EventBridge

EventBridge là một serverless service giúp kết nối các phần khác nhau của một application sử dụng events, giúp xây dựng scalable, event-driven systems. Với EventBridge, bạn route events từ các sources như custom apps, AWS services, và third-party software đến các applications khác. EventBridge đơn giản hóa quy trình nhận, lọc, transform, và deliver events, vì vậy bạn có thể nhanh chóng xây dựng reliable applications.

Ví dụ: EventBridge

Khách hàng sử dụng một online food delivery service để đặt bữa ăn từ các nhà hàng địa phương thông qua một mobile app. Khi một khách hàng đặt hàng, một số bước cần xảy ra đồng thời.

1. Payment processing: Payment service phải verify và process payment của khách hàng.
2. Restaurant notification: Nhà hàng nhận được một notification để bắt đầu chuẩn bị bữa ăn.
3. Inventory management: Inventory system kiểm tra xem các ingredients cho đơn hàng có sẵn không.
4. Delivery dispatch: Một delivery driver được thông báo để pick up và deliver bữa ăn.

Cách EventBridge giúp đỡ: EventBridge có thể route events, như "order placed" hoặc "payment completed", đến các services liên quan (payment, restaurant, inventory, và delivery). Nó có thể xử lý high volumes của events trong giờ cao điểm, đảm bảo mỗi service hoạt động độc lập. Ngay cả khi một service thất bại, EventBridge sẽ lưu trữ event và xử lý nó ngay khi service có sẵn trở lại. EventBridge giúp cung cấp một operation mượt mà và reliable trên toàn bộ hệ thống.

Amazon SQS

Amazon Simple Queue Service (Amazon SQS) là một message queuing service tạo điều kiện cho reliable communication giữa các software components. Nó có thể gửi, lưu trữ, và nhận messages ở bất kỳ quy mô nào, đảm bảo messages không bị mất và các services khác không cần phải có sẵn để xử lý.

SQS làm cho bạn có thể gửi, lưu trữ, và nhận messages giữa các software components ở bất kỳ volume nào. Điều này được thực hiện mà không mất messages hoặc yêu cầu các message consumers khác phải có sẵn.

Hãy nghĩ về messages như các đơn hàng cà phê của chúng ta và order board như một SQS queue. Messages có tên người, đơn hàng cà phê, và thời gian họ đặt hàng. Dữ liệu trong một message được gọi là payload. SQS queues là nơi các messages được đặt cho đến khi chúng được xử lý. Chúng scale tự động, reliable, và đơn giản để cấu hình và sử dụng.

Trong Amazon SQS, một application đặt messages vào queue, và một user hoặc service retrieve message, xử lý nó, và sau đó loại bỏ nó khỏi queue.

Ví dụ: Amazon SQS

Khi customer support teams phát triển và volume của issues tăng lên, traditional workflows có thể gặp khó khăn để theo kịp. Hãy xem xét cách một customer support team có thể giải quyết thách thức này.

Scenario

Một customer support team có một workflow truyền thống: Khách hàng gửi một issue, support agent tạo một ticket và assign nó cho một technical specialist, và specialist làm việc trên issue và thông báo cho support agent.

Challenge

Tuy nhiên, điều gì sẽ xảy ra nếu support agent tạo một ticket nhưng technical specialist đang bận làm việc trên issue khác hoặc không có sẵn? Agent sẽ phải đợi cho đến khi specialist rảnh để chấp nhận ticket mới, gây ra delays trong việc giải quyết customer issues và kéo dài thời gian chờ đợi cho khách hàng. Khi volume của customer issues tăng lên, quy trình này trở nên không hiệu quả.

Solution

Để cải thiện hiệu quả, họ triển khai một queue system sử dụng Amazon SQS. Support agent thêm customer issues vào queue, tạo ra một backlog. Ngay cả khi specialist bận, agent có thể tiếp tục thêm issues mới. Specialist kiểm tra queue, giải quyết issues, và cập nhật agent. Hệ thống này cung cấp một workflow mượt mà và giúp xử lý higher volumes mà không có delays hoặc bottlenecks.

Amazon SNS

Amazon Simple Notification Service (Amazon SNS) tương tự vì nó cũng gửi messages đến services, nhưng nó có một sự khác biệt lớn: SNS messages được gửi không được giữ để pickup cho đến khi processing service có thời gian để xử lý chúng. Thay vào đó, SNS messages cần một response ngay bây giờ.

Nếu SQS là order board cà phê, SNS là barista hét lên, "One Rudy's Rhubarb Refresher, to go!"

Amazon SNS là một publish-subscribe service mà publishers sử dụng để gửi messages đến subscribers thông qua SNS topics. Trong Amazon SNS, subscribers có thể bao gồm web servers, email addresses, Lambda functions, và các endpoints khác nhau. Bạn sẽ tìm hiểu về Lambda chi tiết hơn sau.

Ngoài ra, SNS có thể được sử dụng để fan out notifications đến end users sử dụng mobile push, SMS, và email. Đưa điều này trở lại coffee shop của chúng ta, chúng ta có thể gửi một notification khi đơn hàng của khách hàng sẵn sàng. Điều này có thể là một text message đơn giản.

Ví dụ: Amazon SNS

Một công ty bán nhiều loại sản phẩm hiện đang gửi một email duy nhất cho tất cả khách hàng với các cập nhật về các chủ đề khác nhau, chẳng hạn như sản phẩm mới, ưu đãi đặc biệt, và các sự kiện sắp tới. Mặc dù phương pháp này hoạt động ban đầu, khách hàng muốn nhận chỉ các cập nhật mà họ quan tâm. Email cập nhật hiện tại đang gây ra sự không hài lòng của khách hàng và engagement thấp hơn.

1. Segment the communication

Công ty quyết định chia communication thành ba topics riêng biệt, bao gồm một cho sản phẩm mới, một cho ưu đãi đặc biệt, và một cho events. Mỗi topic sẽ tập trung vào một lĩnh vực quan tâm cụ thể.

2. Let customers choose topics

Khách hàng có thể subscribe vào các topics mà họ quan tâm, chẳng hạn như:

• Một khách hàng có thể chỉ subscribe vào cập nhật sản phẩm mới.
• Một khách hàng khác có thể chỉ chọn thông báo sự kiện.
• Một khách hàng thứ ba có thể chọn subscribe vào cập nhật sản phẩm mới và ưu đãi đặc biệt.

3. Send tailored notifications

Với Amazon SNS, công ty có thể gửi notifications được cá nhân hóa đến subscribers dựa trên interests cụ thể của họ. Amazon SNS đảm bảo rằng các notifications này được deliver kịp thời đến đúng audience, cải thiện hiệu quả và relevance của communication.

So sánh SQS và SNS

Đặc điểm	Amazon SQS	Amazon SNS
Mô hình	Message Queue	Publish-Subscribe
Message Delivery	Messages được lưu trữ trong queue cho đến khi được xử lý	Messages được gửi ngay lập tức đến subscribers
Use Case	Decoupling components, xử lý bất đồng bộ	Real-time notifications, fan-out messaging
Ví dụ	Order board trong coffee shop	Barista hét tên đơn hàng

Tóm tắt

Trong bài học này, bạn đã học về:

• ✅ Tightly Coupled Architecture: Components phụ thuộc chặt chẽ vào nhau, failure của một component có thể ảnh hưởng toàn bộ hệ thống
• ✅ Loosely Coupled Architecture: Components hoạt động độc lập, failure của một component không ảnh hưởng đến các components khác
• ✅ Monolithic Applications: Tất cả components được tích hợp chặt chẽ trong một application duy nhất
• ✅ Microservices Architecture: Application được chia thành các services nhỏ, độc lập
• ✅ Amazon EventBridge: Serverless service để route events giữa các services
• ✅ Amazon SQS: Message queuing service để lưu trữ và xử lý messages bất đồng bộ
• ✅ Amazon SNS: Publish-subscribe service để gửi notifications real-time
• ✅ Message Queues: Giúp cải thiện communication và decoupling giữa các components

Test your skills

Câu hỏi 1

What BEST describes the key difference between tightly coupled and loosely coupled architectures?

• In a tightly coupled architecture, components are tightly connected and dependent on each other, whereas in a loosely coupled architecture, components can operate independently.
• Tightly coupled systems are more flexible in adding new components, whereas loosely coupled systems require careful configuration to add new components.
• Tightly coupled architectures are designed for scalability, whereas loosely coupled systems focus on maintaining high availability.
• Loosely coupled systems require components to share data directly with each other, whereas tightly coupled systems store data in a central repository.

Giải thích: Trong tightly coupled systems, components phụ thuộc chặt chẽ vào nhau. Nếu một component thất bại, nó có thể gây ra cascading failures. Ngược lại, loosely coupled systems có các components hoạt động độc lập, vì vậy failure của một component không làm gián đoạn toàn bộ hệ thống.

Câu hỏi 2

In a banking system, when customers transfer money, the transaction details are sent from the transaction service to a fraud detection service for verification. Sometimes, the fraud detection service is temporarily down. What is the MAIN advantage of using Amazon Simple Queue Service (Amazon SQS) in this banking scenario?

• It guarantees immediate approval of transactions.
• It stores transaction details until the fraud detection service can process them, even if the service is down.
• It speeds up transaction processing by avoiding the use of a buffer.
• It forces the transaction service and fraud detection service to depend on each other directly.

Giải thích: Amazon SQS dùng để lưu trữ messages và xử lý chúng sau, không phải cho immediate responses như approval. Trong scenario này, SQS sẽ lưu trữ transaction details trong queue cho đến khi fraud detection service có sẵn để xử lý chúng, đảm bảo không mất dữ liệu ngay cả khi service tạm thời down.