Giới thiệu
AWS gần đây đã phát hành một tính năng mới cho dịch vụ SQS nổi tiếng của mình mang tên "Hàng đợi công bằng". Trong các cuộc trò chuyện với các kỹ sư về hành vi của nó, tôi nhận thấy có một số sự nhầm lẫn chung về các hệ thống nhắn tin khác nhau trong AWS, chức năng của chúng và cách chúng khác nhau. Trong bài viết này, tôi sẽ cung cấp cái nhìn tổng quan về các loại dịch vụ nhắn tin của AWS, bao gồm một số ví dụ bạn có thể sử dụng để dạy người khác.
Đối với những người mới làm quen với kiến trúc AWS, hàng loạt tùy chọn (SQS, SNS, EventBridge, Kinesis, MSK) cho việc di chuyển dữ liệu có thể gây áp lực. Tôi thấy hữu ích khi phân loại chúng theo cách rộng và sau đó kết nối chúng với các ví dụ cụ thể từ các trường hợp thực tế.
Điều mà tất cả các dịch vụ này có điểm chung là chúng di chuyển dữ liệu. Chúng khác nhau về tốc độ, khả năng, và điểm đến. Chúng cũng khác nhau theo cách mà dịch vụ được "quản lý". Tôi sẽ chỉ ra điều này trong suốt bài viết.
Tôi sử dụng các phân loại rộng "Hàng đợi," "Bus," và "Dòng dữ liệu." Hãy cùng xem xét từng loại và xem các dịch vụ này nằm ở đâu.
Hàng đợi
Thuật ngữ "hàng đợi" trong khoa học máy tính là một tập hợp các thực thể mà "có thể được sửa đổi bằng cách thêm các thực thể ở một đầu của chuỗi và loại bỏ các thực thể ở đầu đối diện." Thuật ngữ này bắt nguồn từ hiện tượng thực tế mà mọi người xếp hàng để nhận một cái gì đó. Hãy tưởng tượng một cửa hàng tạp hóa và mọi người xếp hàng (hay đang đứng trong hàng đợi) tại quầy thanh toán. Các xe hàng mới xếp hàng ở phía sau, và nhân viên thu ngân xử lý các xe hàng ở phía trước.
Một hàng đợi cũng có thể được coi là một bộ đệm. Nó có thể hấp thụ công suất dư thừa (khách mua sắm) mà nếu không sẽ làm cho nguồn lực hạn chế (nhân viên thu ngân) bị quá tải. Càng nhiều nhân viên thu ngân (hoặc càng nhanh mỗi người làm việc), chúng ta càng có thể xử lý mọi người trong hàng đợi nhanh hơn. Hàng đợi giúp làm mịn các khối lượng công việc không đều hoặc bùng nổ.
Một trong những dịch vụ quản lý đầu tiên mà AWS cung cấp là Dịch vụ Hàng đợi Đơn giản (SQS) vào năm 2006. SQS được quản lý hoàn toàn và tự động mở rộng khi mức sử dụng thay đổi. Người tiêu dùng sử dụng mô hình dựa trên việc kéo để truy cập thông điệp và chỉ tiêu thụ khi họ có khả năng làm như vậy. Nói cách khác, người tiêu dùng phải hỏi, "Bạn có thông điệp nào cho tôi không?" để nhận bất kỳ thứ gì.
Vào năm 2025, AWS đã thêm "công bằng" cho SQS. Ngay từ đầu, hàng đợi xử lý các thông điệp (hầu như) theo thứ tự mà nó được đưa vào. Với hàng đợi công bằng của SQS, bạn chỉ định cách SQS nhóm các thông điệp để phân phối tài nguyên xử lý một cách đồng đều hơn. Điều này có thể giúp giảm thiểu tác động của hàng xóm ồn ào trong các hàng đợi đa người thuê.
Tôi nhóm một hàng đợi với người tiêu dùng của nó; nó là một phần của kiến trúc của người nhận, không phải của người gửi.
Hãy xem xét một hàng đợi nếu bạn cần làm chậm mọi thứ lại. Nếu bạn thấy mình nói, "Tôi không thể xử lý sự kiện này ngay bây giờ, nhưng tôi không muốn mất nó," hãy lấy một hàng đợi.
Bus
Có nhiều loại bus thông điệp, và chúng có thể bao gồm các tính năng thường thấy trong hàng đợi hoặc dòng dữ liệu. Tuy nhiên, tôi muốn tập trung vào những đặc điểm cơ bản mà tôi coi là của một bus thông điệp: phân phối và tính không xác định của người nhận.
Phân phối đề cập đến tình huống mà một thông điệp đầu vào tạo ra nhiều thông điệp đầu ra. Ví dụ, khi tôi đặt một thông điệp OrderReceived trên bus, nhiều người nghe độc lập sẽ nhận được một bản sao của thông điệp đó. Điều này thường được gọi là "pub-sub," viết tắt của "Publish/Subscribe." Trong mô hình pub-sub, nhà xuất bản không nên biết về người đăng ký. Nó không có sự xác định của người nhận.
Tính không xác định của người nhận là một cách nói bóng bẩy để nói, "Tôi không biết ai có thể tiêu thụ thông điệp này." Nói cách khác, nhà sản xuất không nói, "Gửi thông điệp này cho Frank." Nhà sản xuất nói, "Gửi thông điệp này cho bất kỳ ai đang lắng nghe." Tôi đã nghe điều này được so sánh với một chiếc radio, nơi bất kỳ ai đang điều chỉnh để nghe sẽ nghe chương trình, nhưng nếu bạn bỏ lỡ nó, nó sẽ biến mất.
AWS đã giới thiệu Dịch vụ Thông báo Đơn giản (SNS) vào năm 2010. Vào thời điểm đó, nó là dịch vụ pub-sub quản lý hoàn toàn đầu tiên trong thế giới đám mây. Do đó, nó đã tiên phong trong lĩnh vực này và đặt ra tiêu chuẩn (cùng với SQS) cho những gì một dịch vụ quản lý hoàn toàn nên làm.
SNS là mô hình dựa trên việc đẩy. Người đăng ký nhận thông điệp theo thời gian thực khi chúng được xuất bản. Họ không cần phải hỏi, "Bạn có thông điệp nào cho tôi không?" Vì các thông điệp không được lưu trữ (hãy nhớ đến phép so sánh với radio?), bạn thường thấy các kiến trúc kết nối một hàng đợi SQS như một người đăng ký cho một chủ đề SNS. Sau đó, dịch vụ tiêu thụ sẽ kéo các thông điệp của nó từ hàng đợi SQS để xử lý.
Vào năm 2016, AWS phát hành "CloudWatch Events" để cho phép người dùng nhận thông báo về các hệ thống mà họ chạy trên AWS. Nó bao gồm các sự kiện tắt EC2 và tự động điều chỉnh quy mô, các sự kiện tạo hoặc xóa dịch vụ mới và nhiều sự kiện khác. Người phát ngôn chính của AWS, Jeff Barr, nói: "Bạn có thể coi CloudWatch Events như hệ thống thần kinh trung ương cho môi trường AWS của bạn. Nó được kết nối với mọi ngóc ngách của các dịch vụ hỗ trợ và trở nên nhận thức được những thay đổi hoạt động khi chúng xảy ra."
Đến năm 2019, AWS nhận ra rằng hệ thống đứng sau CloudWatch Events có thể trở thành một sản phẩm độc lập và EventBridge đã ra đời. Kể từ đó, nó đã nhận được một loạt các cải tiến, khiến nó trở thành dịch vụ ưa thích của tôi cho các kiến trúc dựa trên sự kiện.
Tôi nhóm một bus với nhà sản xuất của nó; nó là một phần của kiến trúc của người gửi, không phải của người nhận.
Dòng dữ liệu
Ngay từ cái nhìn đầu tiên, bạn có thể gặp khó khăn trong việc phân biệt một dòng dữ liệu với một hàng đợi, và điều này là dễ hiểu. Chúng chia sẻ nhiều đặc điểm giống nhau, chẳng hạn như thứ tự và khả năng lưu trữ, nhưng chúng khác nhau chủ yếu ở cách chúng được sử dụng.
Một dòng dữ liệu quan tâm đến các luồng dữ liệu, một cái nhìn tổng quát về cách dữ liệu di chuyển qua một hệ thống. Các mối quan hệ giữa các phần tử dữ liệu là điều quan trọng để phân tích dòng dữ liệu. Ngược lại, một hàng đợi quan tâm đến mỗi thông điệp dữ liệu riêng biệt như một đơn vị riêng biệt, tách biệt với các thông điệp khác.
Hãy nghĩ về một hệ thống đường cao tốc trong một thành phố. Các nhà điều hành quan tâm đến những điều như: "Có bao nhiêu xe đi qua mỗi giờ?", "Những thời điểm nào có tỷ lệ giao thông cao nhất?", và "Tỷ lệ xe ô tô so với xe tải lớn trong mỗi giờ là bao nhiêu?" Trong trường hợp này, chúng ta ít quan tâm đến từng phương tiện (thông điệp) và nhiều hơn đến lưu lượng (dòng dữ liệu). Dòng dữ liệu này, nếu được ghi lại, có thể được "phát lại" để trả lời các câu hỏi mới vào thời điểm sau.
AWS đã ra mắt dịch vụ phát trực tuyến theo thời gian thực được quản lý, Kinesis, vào năm 2013. Nó có thể ghi lại và xử lý hàng gigabyte dữ liệu mỗi giây từ nhiều nguồn khác nhau. Kể từ đó, AWS đã cung cấp các biến thể khác nhau của Kinesis để tập trung vào các mối quan tâm khác nhau về dòng dữ liệu:
- Kinesis Data Streams (bản gốc)
- Kinesis Data Firehose (để chuyển lớn lượng dữ liệu đến một điểm đến)
- Kinesis Data Analytics (để phân tích dòng dữ liệu giống như Flink)
- Kinesis Video Streams (để ghi lại/xử lý video)
Một dòng dữ liệu AWS khác mà tôi thường gặp là Dòng DynamoDB. Được giới thiệu vào năm 2014, nó cung cấp một trình tự các thay đổi cấp mục theo thời gian cho một bảng DynamoDB như là một dòng dữ liệu. Tôi thường sử dụng điều này như một nguồn để phát ra các sự kiện cho các dịch vụ khác (DynamoDB Stream -> EventBridge). Dòng này ít tùy chỉnh hơn (quản lý nhiều hơn) so với Kinesis.
AWS cũng hỗ trợ một dịch vụ có tên là MSK, viết tắt của Managed Streaming for Apache Kafka. Nó đơn giản hóa việc vận hành một cụm Apache Kafka, mặc dù bạn vẫn có trách nhiệm về kích thước phiên bản và cấu hình lưu trữ EBS. Họ có một phiên bản "serverless" quản lý hơn của MSK mà loại bỏ một số cấu hình, nhưng không mở rộng đến không (do đó, theo ý kiến của tôi, nó không đủ điều kiện cho danh hiệu "serverless"). Hãy xem xét MSK nếu bạn đã sử dụng Apache Kafka và đang tìm kiếm một chiến thắng vận hành nhanh chóng.
Việc nhóm kiến trúc dòng dữ liệu không rõ ràng như trong hàng đợi và bus. Tôi đã thấy những ví dụ mà dòng dữ liệu là một phần của người tiêu dùng. Chúng tôi có ví dụ về dòng dữ liệu như một phần của người sản xuất (Chào bạn, dòng DynamoDB!). Và tôi đã làm việc trên các ứng dụng được xây dựng xung quanh dòng dữ liệu, như các bộ xử lý sự kiện cho phân tích cổ phiếu.
Nhầm lẫn về Kafka
Apache Kafka có thể hoạt động như một hàng đợi, một bus, hoặc một dòng dữ liệu tùy thuộc vào cách sử dụng của nó. Thực tế, các cuộc trò chuyện ban đầu đã thúc đẩy bài viết này đã diễn ra với các kỹ sư có kinh nghiệm với Kafka nhưng hạn chế tiếp xúc với các thành phần AWS cụ thể hơn. Dưới nắp ca-pô, Kafka đang kết hợp bus, hàng đợi và dòng dữ liệu.
Bạn có thể xây dựng các hành vi tương tự bằng cách kết hợp các thành phần AWS để tạo ra các bộ xử lý thông điệp phức tạp hơn. Ví dụ, khi tôi còn nhỏ, nếu tôi không muốn bỏ lỡ một buổi phát sóng radio của King Biscuit Flour Hour (hãy tìm kiếm nó), tôi sẽ lấy một băng ghi âm, nhấn nút ghi, và đặt nó bên cạnh loa của radio. Điều này tương tự như việc kết nối một hàng đợi với một bus. Chúng ta đã tiến xa, em yêu.
Tóm tắt
Hàng đợi, bus và dòng dữ liệu chia sẻ một số chức năng chung; tất cả chúng đều di chuyển thông điệp. Những khác biệt xuất hiện khi chúng ta nhìn vào cách mỗi loại xử lý các thông điệp đó và cách mà chúng ta nhóm chúng theo kiến trúc.
Nếu bạn được yêu cầu giải thích sự khác biệt giữa bus, hàng đợi và dòng dữ liệu (hoặc bất kỳ tập hợp khái niệm liên quan nào khác), hãy có sẵn các ví dụ để giúp bạn minh họa các điểm tương đồng và khác biệt. Bằng cách chuyển từ những cuộc trò chuyện chung chung về kiến trúc phần mềm và hướng tới các ví dụ thực tế, chẳng hạn như cửa hàng tạp hóa, radio và hệ thống đường cao tốc, bạn có thể giúp các kỹ sư định hình suy nghĩ của họ.
Chúc bạn xây dựng thành công!
Câu hỏi thường gặp
1. Hàng đợi là gì?
Hàng đợi là một cấu trúc dữ liệu cho phép thêm và loại bỏ các phần tử theo thứ tự.
2. Bus nhắn tin là gì?
Bus nhắn tin cho phép phát thông điệp từ một nhà sản xuất đến nhiều người tiêu dùng mà không biết nhau.
3. Dòng dữ liệu là gì?
Dòng dữ liệu là một luồng liên tục của dữ liệu, được phân tích theo thời gian.
Thực tiễn tốt nhất
- Sử dụng hàng đợi khi bạn cần quản lý lưu lượng truy cập không đồng đều.
- Chọn bus khi bạn muốn một thông điệp được gửi đến nhiều người nhận mà không cần biết danh tính của họ.
- Áp dụng dòng dữ liệu khi bạn cần phân tích dữ liệu theo thời gian và theo mối quan hệ.
Cảnh báo và lưu ý quan trọng
- Đảm bảo theo dõi hiệu suất của các dịch vụ AWS để tối ưu hóa chi phí.
- Cẩn thận khi thiết lập cấu hình cho các dịch vụ như MSK để tránh các vấn đề về hiệu suất.
