Kiến trúc hướng sự kiện với hàng đợi tin nhắn: Hướng dẫn thực hành

Kiến trúc hướng sự kiện với hàng đợi tin nhắn là một mô hình sản xuất trong đó các dịch vụ xuất bản các sự kiện hoặc nhiệm vụ cho người môi giới và người tiêu dùng độc lập xử lý chúng một cách không đồng bộ. Nó giúp các nhóm tách rời các dịch vụ, đệm khối lượng công việc tăng đột biến, cách ly lỗi và tránh khiến mọi quy trình làm việc phụ thuộc vào một chuỗi lệnh gọi API đồng bộ.

Vấn đề của người mua là thực tế: quy trình thanh toán, quy trình giới thiệu, đồng bộ hóa dữ liệu, công việc thu thập dữ liệu hoặc quy trình đánh giá AI bắt đầu không thành công do một phần phụ thuộc xuôi dòng chậm, không khả dụng hoặc quá tải. Đối tượng của hướng dẫn này là những người sáng lập kỹ thuật, lãnh đạo kỹ thuật và nhóm dữ liệu đang quyết định xem hàng đợi có phải là nền tảng phù hợp để tự động hóa đáng tin cậy hơn hay không.

Tại Van Data Team, chúng tôi bắt đầu bằng việc ánh xạ các tín hiệu quy trình làm việc, ranh giới quyền sở hữu, đường dẫn thử lại, bảng thông tin và cổng xem xét trước khi chọn nhà môi giới. Mô hình vận hành tương tự đó áp dụng cho quy trình làm việc của tác nhân AI sản xuất, đường dẫn dữ liệu thời gian thực và tự động hóa nền tảng: hàng đợi chỉ hữu ích khi hệ thống xung quanh biết phải làm gì với sự chậm trễ, trùng lặp, lỗi và sự leo thang của con người.

Hướng dẫn này cung cấp cho bạn một khung sẵn sàng cho sản xuất về kiến trúc, lựa chọn mẫu, triển khai, khả năng quan sát, khôi phục lỗi và xem xét các điểm kiểm tra.

Bài học chính

• Sử dụng hàng đợi tin nhắn khi công việc có thể diễn ra không đồng bộ và cần lưu vào bộ đệm, thử lại hoặc cách ly người tiêu dùng.
• Không chọn Kafka, RabbitMQ, Redis Streams hoặc SQS chỉ theo mức độ phổ biến. Kết hợp nhà môi giới với nhu cầu đặt hàng, nhu cầu chơi lại, gánh nặng hoạt động và kỹ năng nhóm.
• Người tiêu dùng đáng tin cậy phải bình thường, có thể quan sát được và được thiết kế để phân phối trùng lặp, thông điệp độc hại, thay đổi lược đồ và tăng trưởng tồn đọng.
• Đối với quy trình làm việc tự động hóa và AI, số lần thử lại ảnh hưởng đến chi phí, ngân sách mã thông báo, độ trễ, gánh nặng xem xét và chất lượng báo cáo.
• Quá trình triển khai sẵn sàng sản xuất cần có hợp đồng sự kiện, xử lý thư chết, chuyển nhượng chủ sở hữu, bảng thông tin và kế hoạch khôi phục trước khi khởi chạy.

Kiến trúc hướng sự kiện có thay đổi gì với hàng đợi tin nhắn

Hình minh họa sau đây tóm tắt công việc xếp hàng đợi phân biệt tốc độ và khả năng phục hồi:

Sự thay đổi cốt lõi là từ sự phụ thuộc trực tiếp sang công việc qua trung gian. Nhà sản xuất tạo ra một tin nhắn, nhà môi giới lưu trữ hoặc định tuyến nó và người tiêu dùng xử lý nó khi họ sẵn sàng. Thông báo đó có thể đại diện cho một sự kiện kinh doanh, chẳng hạn như invoice.created hoặc một lệnh, chẳng hạn như generate_monthly_report.

Trong quy trình làm việc đồng bộ, Dịch vụ A gọi Dịch vụ B, chờ rồi gọi Dịch vụ C. Nếu Dịch vụ C không thành công thì trải nghiệm người dùng, giao dịch hoặc toàn bộ công việc có thể không thành công. Trong quy trình làm việc theo hướng sự kiện, Dịch vụ A xuất bản thông báo và tiếp tục. Người tiêu dùng có thể thử lại, mở rộng quy mô một cách độc lập hoặc thất bại mà không phá vỡ nhà sản xuất ban đầu.

Một kiến trúc sản xuất cơ bản có những phần sau:

• Nhà sản xuất: dịch vụ phát ra sự kiện hoặc nhiệm vụ.
• Nhà môi giới: dịch vụ xếp hàng, trao đổi, truyền phát hoặc được quản lý để lưu trữ và định tuyến tin nhắn.
• Người tiêu dùng: nhân viên hoặc dịch vụ xử lý tin nhắn.
• Xác nhận: tín hiệu cho thấy quá trình xử lý đã thành công.
• Chính sách thử lại: quy tắc dành cho các lỗi tạm thời.
• Hàng đợi thư chết: nơi chứa những tin nhắn không thể xử lý an toàn.
• Lớp giám sát: bảng thông tin và cảnh báo về tồn đọng, lỗi, thử lại và độ trễ.

Sơ đồ quy trình làm việc hữu ích sẽ hiển thị hành động của người dùng khi nhập API, API xuất bản thông báo cho nhà môi giới, phân tách người tiêu dùng xử lý thanh toán, thông báo, phân tích và đánh giá AI cũng như các thông báo không thành công khi chuyển sang hàng đợi thư chết với đường dẫn xem xét của nhà điều hành.

Sai lầm mà chúng tôi thấy là coi hàng đợi như một kiến trúc. Không phải vậy. Kiến trúc là hệ điều hành đầy đủ xung quanh hàng đợi: hợp đồng, người tiêu dùng, khả năng quan sát, kiểm soát chi phí và hành vi phục hồi.

Kiến trúc triển khai

Việc triển khai tốt bắt đầu từ quy trình làm việc của doanh nghiệp chứ không phải từ người môi giới. Ví dụ: khách hàng đăng ký, tải tệp lên hoặc gửi yêu cầu. Hành động đó tạo ra một tín hiệu. Câu hỏi đặt ra là liệu công việc xuôi dòng có phải kết thúc trước khi người dùng tiếp tục hay không.

Nếu câu trả lời là không thì quy trình làm việc có thể được đưa vào hàng đợi. Gửi tin nhắn, trả lời nhanh và để nhân viên xử lý phần còn lại.

Đối với đường dẫn dữ liệu, nhà sản xuất có thể xuất bản các sự kiện nhập khi tệp đến. Người tiêu dùng xác thực hồ sơ, làm phong phú dữ liệu, cập nhật bảng kho và kích hoạt công việc báo cáo. Đối với các hệ thống nặng về phát trực tuyến, hãy xem hướng dẫn của Van Data Team về hiện đại hóa nền tảng dữ liệu để sẵn sàng cho AI, trong đó việc phát lại, đặt hàng và nhập liên tục trở thành mối quan tâm thiết kế trọng tâm.

Đối với quy trình làm việc AI, một thông báo có thể kích hoạt phân loại, tóm tắt, trích xuất hoặc định tuyến. Điều đó làm thay đổi mô hình đánh giá. Bạn cần theo dõi không chỉ thành công và thất bại mà còn cả tỷ lệ đánh giá, chi phí mô hình, ngân sách mã thông báo, chất lượng leo thang và liệu đầu ra có vượt qua kiểm tra của con người hay tự động hay không.

Hợp đồng tin nhắn tối thiểu có thể ngắn gọn:

1. Define the Event-driven architecture with message queues decision.
2. List required inputs, owner, and stop conditions.
3. Run the smallest safe workflow.
4. Validate output quality before publishing or deployment.
5. Escalate unresolved risk to a human reviewer.

Điều này không nhằm mục đích thay thế công cụ lược đồ. Nó là một hiện vật đánh giá. Trước khi triển khai, mọi người nên biết ai sở hữu sự kiện, người tiêu dùng phụ thuộc vào ai, thất bại nghĩa là gì và người điều hành sẽ nhìn nhận vấn đề như thế nào.

Hàng đợi, luồng, Pub/Sub và API đồng bộ

Các hệ thống hướng sự kiện thường kết hợp nhiều mẫu. Lựa chọn đúng đắn phụ thuộc vào việc bạn cần phân phối tác phẩm, phát lại, phát sóng hay phản hồi ngay lập tức.

Tài liệu chính thức là nơi thích hợp để xác thực hành vi của nhà môi giới trước khi sản xuất. Xem lại tài liệu về Apache Kafka để biết các phân vùng, mức lưu giữ và nhóm người tiêu dùng; Tài liệu về RabbitMQ về trao đổi, xếp hàng, định tuyến và xác nhận; Hướng dẫn xếp hàng thư chết của AWS SQS để xử lý lỗi; và Tài liệu về luồng Redis nếu bạn đang đánh giá hành vi giống như luồng trong Redis.

Quy tắc thực tế: sử dụng hàng đợi khi bạn cần phân phối công việc không đồng bộ lâu dài, luồng khi bạn cần lịch sử có thể phát lại theo thứ tự, pub/sub khi nhiều hệ thống cần cùng một tín hiệu và API đồng bộ khi người gọi thực sự cần câu trả lời ngay bây giờ.

Quy trình sản xuất để bắt đầu

Bắt đầu với bản đồ quy trình làm việc. Liệt kê hành động, nhà sản xuất, thông báo, người môi giới, người tiêu dùng, ghi cơ sở dữ liệu, lệnh gọi API bên ngoài, bảng thông tin và đường dẫn lỗi. Làm điều này trước khi viết mã.

1. Xác định ranh giới sự kiện. Nêu tên các thời điểm kinh doanh quan trọng: thanh toán đã nhận, tài liệu được tải lên, khách hàng tiềm năng đủ tiêu chuẩn, yêu cầu chuyển cấp, báo cáo được yêu cầu.
2. Phân loại tin nhắn. Đây có phải là sự kiện, lệnh hay truy vấn không? Sự kiện mô tả một cái gì đó đã xảy ra. Các lệnh yêu cầu một nhân viên làm điều gì đó. Các truy vấn thường không nằm trong hàng đợi trừ khi bạn đang xây dựng mẫu yêu cầu không đồng bộ chuyên biệt.
3. Chọn nhà môi giới và mô hình phân phối. Kết hợp công cụ này với hoạt động đặt hàng, phát lại, thông lượng, kinh nghiệm nhóm, ưu tiên dịch vụ được quản lý và khả năng vận hành.
4. Xác định lược đồ. Bao gồm phiên bản, trường bắt buộc, trường tùy chọn, quyền sở hữu và quy tắc tương thích.
5. Thử lại thiết kế và xử lý thư chết. Quyết định nội dung nào sẽ được thử lại, nội dung nào bị trì hoãn và nội dung nào cần có sự xem xét của con người.
6. Thêm khả năng quan sát trước khi ra mắt. Theo dõi tồn đọng, tuổi của tin nhắn cũ nhất, độ trễ xử lý, số lần thử lại, tỷ lệ lỗi, tình trạng người dùng và số lượng thư chết.
7. Xem xét chi phí và công suất. Số lần thử lại, công việc trùng lặp và số nhân viên nhàn rỗi có thể tạo ra khoản chi tiêu cơ sở hạ tầng tiềm ẩn. Đây là nơi đáp ứng tối ưu hóa chi phí đám mây và đánh giá kiến ​​trúc.

Điểm kiểm tra hữu ích giữa dự án là đánh giá quy trình làm việc theo phạm vi. Nhóm Van Data có thể cung cấp bản đồ sự kiện, đề xuất phù hợp với nhà môi giới, kế hoạch thử lại và thư chết, đánh giá khoảng cách trên bảng điều khiển và phạm vi triển khai cho các nhóm hiện đại hóa đường dẫn dữ liệu, hệ thống tự động hóa hoặc quy trình làm việc của tác nhân AI.

Thực tiễn tốt nhất cho hệ thống xếp hàng đáng tin cậy

Thiết kế người tiêu dùng trở nên bình thường. Người tiêu dùng nên xử lý cùng một tin nhắn nhiều lần mà không làm hỏng trạng thái. Lưu trữ các dấu hiệu xử lý, sử dụng ID hoạt động duy nhất hoặc thực hiện ghi an toàn lặp lại một cách tự nhiên.

Tách biệt sự kiện kinh doanh khỏi lệnh kỹ thuật. customer.created khác với send_welcome_email. Việc trộn lẫn chúng làm cho quyền sở hữu trở nên khó hiểu và việc thay đổi lược đồ trở nên rủi ro.

Cố ý sử dụng hàng đợi thư chết. Một thông báo độc hại không nên chặn toàn bộ quy trình làm việc mãi mãi. Nó sẽ chuyển sang đường dẫn xem xét trong đó người vận hành có thể kiểm tra tải trọng, lỗi, phiên bản dành cho người tiêu dùng, lịch sử thử lại và tác động kinh doanh.

Lược đồ phiên bản. Người tiêu dùng không nên vi phạm vì nhà sản xuất đã thêm hoặc thay đổi một lĩnh vực mà không có sự phối hợp. Đối với các quy trình công việc quan trọng, việc kiểm tra khả năng tương thích của lược đồ phải là một phần của quá trình triển khai.

Chọn vũ đạo hoặc dàn nhạc có mục đích. Biên đạo cho phép các dịch vụ phản ứng độc lập với các sự kiện. Phối hợp sử dụng bộ điều khiển quy trình công việc trung tâm. Vũ đạo ban đầu có thể đơn giản hơn nhưng khó theo dõi hơn. Sự phối hợp có thể cải thiện khả năng kiểm soát nhưng có thể trở thành sự phụ thuộc trung tâm.

Lập kế hoạch cho khả năng quan sát. Độ sâu hàng đợi thôi là không đủ. Một hàng nhỏ các tin nhắn cũ bị kẹt có thể còn tệ hơn một hàng lớn di chuyển bình thường. Theo dõi độ tuổi, số lần thử lại, độ trễ của người tiêu dùng và lý do thư chết.

Giữ tải trọng rõ ràng và ổn định. Bao gồm đủ ngữ cảnh để người tiêu dùng làm việc nhưng tránh nhồi nhét mọi bản ghi liên quan vào tin nhắn. Tải trọng lớn làm tăng rủi ro về lưu trữ, truyền tải, quyền riêng tư và khả năng tương thích.

Đối với quy trình công việc do AI điều khiển, hãy đánh giá kết quả đầu ra như một phần của vòng đời hàng đợi. Một tin nhắn tạo ra câu trả lời không tự động thành công. Nó có thể vẫn cần chấm điểm, rào chắn, đánh giá con người hoặc leo thang, đặc biệt là trong các hoạt động hỗ trợ, tài chính, tuân thủ và giao tiếp với khách hàng.

Các chế độ lỗi và kiểm tra mức độ sẵn sàng

Hệ thống xếp hàng bị lỗi khác với hệ thống đồng bộ. Người dùng có thể không nhìn thấy lỗi ngay lập tức, điều này làm cho khả năng quan sát và xem xét các cổng trở nên quan trọng hơn.

Những hoạt động kiểm tra này rất quan trọng đối với AWS và các ngăn xếp gốc trên nền tảng đám mây vì các lựa chọn kiến trúc ảnh hưởng đến mức chi tiêu nhiều như độ tin cậy. Bài viết của Van Data Team về cách các nhóm dữ liệu các biện pháp bảo vệ tối ưu hóa chi phí đám mây cho nền tảng dữ liệu cho thấy nguyên tắc hoạt động tương tự: kiểm soát chi phí hoạt động tốt nhất khi nó gắn liền với hành vi khối lượng công việc, không được áp dụng sau khi hóa đơn đến.

Trước khi sản xuất, hãy tổ chức một buổi đánh giá mức độ sẵn sàng với kỹ thuật, dữ liệu, hoạt động và chủ doanh nghiệp. Xác nhận rằng mỗi thông báo đều có chủ sở hữu, mỗi lỗi có một đường dẫn và mỗi bảng thông tin trả lời một câu hỏi vận hành thực tế.

Ví dụ thực tế

Hệ thống tự động hóa web có khối lượng lớn có thể sử dụng hàng đợi để phân phối công việc thu thập thông tin hoặc trích xuất cho các nhân viên. Nhà sản xuất tạo thông báo công việc, trang xử lý công nhân, di chuyển công việc không thành công thông qua logic thử lại và bảng thông tin hiển thị tỷ lệ thành công, tồn đọng và danh mục thất bại. Để biết ví dụ sản xuất về hình thức vận hành này, hãy xem nền tảng thu thập dữ liệu và tự động hóa web doanh nghiệp của Van Data Team.

Quy trình phân loại hỗ trợ có thể sử dụng các sự kiện để phân loại yêu cầu mới, định tuyến chúng đến hàng đợi phù hợp, chuyển các trường hợp không chắc chắn và gửi lại kết quả do con người đánh giá vào báo cáo. Đây là mô hình đằng sau các hoạt động được AI hỗ trợ: việc di chuyển hàng đợi hoạt động nhưng cổng đánh giá vẫn bảo vệ chất lượng. Hệ thống phân loại và báo cáo hỗ trợ AI của Van Data Team là tài liệu tham khảo hữu ích cho sự kết hợp giữa tự động hóa, định tuyến và đánh giá con người.

Quy trình làm việc báo cáo có thể xuất bản report.requested, cho phép nhân viên thu thập dữ liệu, tạo tệp, thông báo cho các bên liên quan và ghi lại trạng thái hoàn thành. Nếu nhà cung cấp báo cáo không thành công thì trải nghiệm sản phẩm ban đầu không nhất thiết phải thất bại. Công việc có thể thử lại, chuyển tiếp hoặc rơi vào tình trạng xếp hàng thư chết.

Tất cả các ví dụ này đều có chung một nguyên tắc: hàng đợi là vùng đệm, nhưng hệ thống sản xuất là quy trình làm việc xung quanh nó.

Kết luận

Hệ thống hướng sự kiện hoạt động khi chúng làm cho quy trình sản xuất diễn ra suôn sẻ hơn chứ không chỉ được phân tán nhiều hơn. Quyết định thực tế là liệu việc xử lý không đồng bộ, lưu vào bộ đệm, thử lại và cách ly người tiêu dùng có giải quyết được vấn đề nền tảng hoặc kinh doanh thực sự hay không.

Kiến trúc hướng sự kiện mạnh mẽ với việc triển khai hàng đợi tin nhắn bắt đầu bằng ranh giới sự kiện, sau đó thêm lựa chọn người môi giới, quyền sở hữu lược đồ, người tiêu dùng bình thường, xử lý thư chết, bảng thông tin, xem xét chi phí và kế hoạch khôi phục. Đối với hệ thống AI và tự động hóa, hãy thêm cổng đánh giá và báo cáo về con người trước khi quy trình làm việc tiếp cận khách hàng hoặc các hoạt động quan trọng.

Nếu bạn đang lập kế hoạch cho quy trình làm việc dựa trên hàng đợi, Nhóm Van Data có thể biến ý tưởng thành kế hoạch phân phối trong phạm vi: bản đồ tín hiệu, đề xuất của nhà môi giới, thiết kế thư thử lại và thư chết, xem xét khoảng trống bảng điều khiển, quy trình xem xét rủi ro và phạm vi triển khai cho đường dẫn dữ liệu, tác nhân AI hoặc nền tảng tự động hóa của bạn.