Kiến trúc hệ thống cảnh báo

Tôi muốn tạo một hệ thống xử lý các thông điệp cảnh báo từ các chương trình khác nhau và có thể xử lý các cảnh báo đó cho người tiêu dùng thông qua email. Tất cả điều này sẽ được chứa trên một mạng nội bộ.

Tôi nghĩ rằng tôi muốn kiến ​​trúc cơ bản trông giống như thế này:

Mối quan tâm chính hiện tại tôi có là bit "Trình xử lý thư", đây sẽ là "API sắp xếp" của tôi. Tôi muốn tất cả các thành phần của hệ thống này gửi dữ liệu tới API, xử lý tất cả ghi vào cơ sở dữ liệu. Tôi nghĩ cách tiếp cận này dễ dàng hơn vì nó đơn giản hóa bảo mật và cho phép tôi chứa rất nhiều truy vấn DB phức tạp hơn vào một chương trình.

Mối quan tâm là tôi muốn đây là ngôn ngữ bất khả tri - có nghĩa là bất kỳ mã nào cũng có thể gửi tin nhắn đến Handler của tôi - sẽ giải thích chúng. Tôi hy vọng sẽ thực hiện điều này thông qua các tệp phẳng JSON - hoặc thông qua các cuộc gọi REST đến chương trình (mang lại sự linh hoạt cho các ứng dụng truyền phát).

Câu hỏi của tôi là-

Tôi có nên bận tâm với trình xử lý tin nhắn - hay nó sẽ thêm đơn giản để chỉ cho phép truy cập cơ sở dữ liệu trực tiếp vào các ứng dụng dòng xuống, cũng như hai thành phần khác (Bảng điều khiển quản lý và Trình quản lý cảnh báo)?

Bằng cách đó, họ có thể chèn bất kỳ cảnh báo nào họ muốn - miễn là INSERT vào bảng / s DB là hợp lệ.

Tôi không phải là nhà thiết kế phần mềm bằng thương mại nên xin lỗi - tôi chỉ muốn một dự án thực hiện trong thời gian rảnh.

Bạn đã xem qua AMQP (Giao thức xếp hàng tin nhắn nâng cao: https://www.rabbitmq.com/protatio.html ) chưa?

RabbitMQ là một công cụ tuyệt vời cho những thứ như thế này, tôi nghĩ (cũng có những dịch vụ khác, dịch vụ MSMQ, Azure / AWS, v.v.). Bạn không chỉ nhận được một trình xử lý tin nhắn bất khả tri ngôn ngữ (đơn giản "gửi tin nhắn đến máy chủ tin nhắn dữ liệu w / json"), bạn tách rời việc xử lý tin nhắn xuôi dòng và làm cho nó cách ly tốt. Chạy một dịch vụ tin nhắn xử lý các tin nhắn đến từ (các) hàng đợi bạn cần và đưa ra các thông báo của bạn.

Một trong những lý do tôi thực sự thích sử dụng AMQP là bạn bắt đầu như bây giờ với một số giải pháp nướng tại nhà, nhưng nhận ra sau thời gian bạn cần xử lý các thông báo hơi khác nhau tùy thuộc vào loại, người cần đến, v.v. , vì vậy cuối cùng bạn sẽ xây dựng triển khai AMQP của riêng mình.

Bạn sẽ làm gì nếu một tin nhắn cần đến 5 người nhận khác nhau? Điều gì sẽ xảy ra nếu bạn có một thông điệp nên được xoay trong một số bộ xử lý (nghĩ rằng các tác vụ chạy dài và có số lượng bộ xử lý đồng thời X, trong đó bạn có thể luân chuyển các tin nhắn thuộc một loại cụ thể). Điều gì sẽ xảy ra nếu tin nhắn sẽ được gửi đến một người, nhưng nếu chúng không có sẵn / trực tuyến, nó sẽ chuyển đến một người khác? AMQP xử lý tất cả những điều này (khá độc đáo!), Với phân loại, hàng đợi, kênh rất bền, bền bỉ, tất cả các loại tính năng.

Dưới đây là tổng quan cơ bản về các tình huống có thể xử lý (lưu ý điều này không cụ thể đối với RabbitMQ: đó là điều AMQP, nhưng RabbitMQ tình cờ giải thích rõ về nó) - https://www.rabbitmq.com/getstarted.html

Câu hỏi đóng khung rất tốt!

Vì vậy, tất cả các quyết định kiến ​​trúc liên quan đến sự đánh đổi. Nếu bạn tò mò cho một cuộc thảo luận về sự đánh đổi có lẽ sẽ chỉnh sửa câu hỏi của bạn theo hướng đó. Thay vào đó, vì câu hỏi chỉ yêu cầu một vị trí, tôi sẽ đứng về phía tranh luận để ủng hộ MessageHandler. Tôi sẽ đi thêm một bước nữa để đề xuất KHÔNG bao gồm cơ sở dữ liệu - ít nhất không phải là cơ sở dữ liệu SQL, ít nhất là không bắt đầu. Chỉ cần MessageHandler lưu JSON vào hệ thống tệp, giả sử một cảnh báo thư mục mỗi giờ nhận được (tất nhiên tùy thuộc vào âm lượng) và có API khi được Trình quản lý cảnh báo truy vấn chỉ qua 2 thư mục cuối của thông báo để quyết định email nào sẽ được gửi (tất nhiên tùy thuộc vào mức độ ưu tiên).

Có rất nhiều thứ hay ho để giải quyết vấn đề này, và giữ cho cơ sở dữ liệu ra khỏi hình ảnh ở giai đoạn đầu sẽ loại bỏ rất nhiều tiếng ồn ngẫu nhiên và giải quyết vấn đề không cần thiết. Tất nhiên, có lẽ bạn có một tình yêu tiềm ẩn trong việc tạo các mô hình dữ liệu quan hệ và ước mơ viết SQL. Trong trường hợp đó, câu trả lời này là hoàn toàn sai. Nhưng nói chung, ngay cả các cơ sở dữ liệu nhanh nhất cũng là các nền tảng ứng dụng khủng khiếp và chúng chỉ được đưa vào các hệ thống vì chúng là các chuyên gia về độ bền và truy vấn được lập chỉ mục.

Chúc may mắn!