Архитектура системы оповещения

Я хотел бы создать систему, которая обрабатывает предупреждающие сообщения от различных программ и может обрабатывать эти оповещения для потребителей, использующих новейшие технологии, по электронной почте. Все это будет содержаться в одной внутренней сети.

Я думаю, что я хочу, чтобы базовая архитектура выглядела примерно так:

Основная проблема, с которой я столкнулся в настоящее время, - это бит «Обработчик сообщений», который и будет моим «своего рода API». Я хочу, чтобы все компоненты этой системы отправляли данные в API, который обрабатывает все записи в базу данных. Я думаю, что этот подход проще, потому что он упрощает безопасность и позволяет мне содержать множество более сложных запросов к БД в одной программе.

Проблема заключается в том, что я хочу, чтобы это не зависело от языка - это означает, что любой код должен иметь возможность отправлять сообщения в мой обработчик - что будет их интерпретировать. Я надеюсь сделать это с помощью плоских файлов JSON - или с помощью REST-вызовов программы (предоставляя гибкость приложениям нижестоящего потока).

Мой вопрос-

Должен ли я беспокоиться об обработчике сообщений - или это добавит простоты, чтобы просто разрешить прямой доступ к базе данных для приложений нижестоящего потока, а также двух других компонентов (Консоль управления и Диспетчер предупреждений)?

Таким образом, они могут вставлять любое предупреждение, которое они хотят - до тех пор, пока INSERT в таблицу / таблицы БД действительна.

По профессии я не дизайнер программного обеспечения, так что извините - я просто хочу, чтобы проект занимался в свободное время.

Вы изучили AMQP (расширенный протокол очереди сообщений: https://www.rabbitmq.com/protocol.html )?

Я думаю, что RabbitMQ - отличный инструмент для чего-то подобного (есть и другие, MSMQ, службы Azure / AWS и т. Д.). Вы получаете не только один обработчик сообщений, не зависящий от языка (просто «отправить сообщение на сервер сообщений с данными json»), вы также отключаете обработку нижестоящих сообщений и делаете ее хорошо изолированной. Запустите службу сообщений, которая обрабатывает входящие сообщения из нужных вам очередей и выкладывает уведомления.

Одна из причин, по которой мне действительно нравится использовать AMQP, заключается в том, что вы начинаете, как и сейчас, с каким-то домашним решением, но понимаете, что со временем вам придется обрабатывать сообщения немного по-разному в зависимости от типа, к кому он должен обратиться и т. Д. Таким образом, в конечном итоге вы в конечном итоге создаете свою собственную реализацию AMQP.

Что вы делаете, если сообщение должно быть отправлено 5 разным получателям? Что делать, если у вас есть сообщение, которое должно быть повернуто на нескольких процессорах (подумайте о длительных задачах и наличии X одновременных процессоров, где вы можете циклически пересылать сообщения определенного типа). Что, если сообщение должно быть отправлено одному человеку, но если оно недоступно / находится в сети, оно должно перейти к другому? AMQP уже обрабатывает все это (довольно хорошо!), С очень хорошей категоризацией, очередями, каналами, устойчивым постоянством, всевозможными функциями.

Вот основной обзор сценариев, с которыми он может справиться (обратите внимание, что это не относится к RabbitMQ: это вещь AMQP, но RabbitMQ хорошо объясняет это) - https://www.rabbitmq.com/getstarted.html

Очень хорошо сформулированный вопрос!

Итак, все архитектурные решения связаны с компромиссами. Если вам интересно обсудить компромиссы, возможно, отредактируйте свой вопрос в этом направлении. Вместо этого, поскольку вопрос просто требует позиции, я возьму на себя аргументы в пользу MessageHandler. Я сделаю еще один шаг, чтобы предложить НЕ включать базу данных - по крайней мере, не базу данных SQL, по крайней мере, не начинать. Просто пусть MessageHandler сохранит JSON в файловую систему, скажем, оповещения о часе получения (в зависимости от объема, конечно), и используйте API, когда его запрашивает диспетчер оповещений, просто просматривая последние 2 каталога оповещения, чтобы решить, какие электронные письма доставить (конечно, в зависимости от приоритета).

В этой задаче есть масса полезных вещей, которые можно обдумать, а сохранение базы данных на начальном этапе позволит избежать большого количества побочных шумов и ненужного решения проблемы. Конечно, возможно, у вас есть скрытая любовь к созданию реляционных моделей данных и мечта о написании SQL. В этом случае этот ответ совершенно неверен. Но, вообще говоря, даже самые гибкие базы данных являются ужасными прикладными платформами, и они включаются в системы только потому, что они специалисты по долговечности и индексированным запросам.

Удачи!