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


10

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

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

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

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

Мой вопрос-

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

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

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

Ответы:


4

Вы изучили 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


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

2
Я был немного напуган, когда впервые попал в RabbitMQ, но после уик-энда обучения это было похоже на вау, это на самом деле очень, очень приятно, и теперь, когда я понимаю, на что я смотрю, это действительно очень просто
jleach

Мне нравится идея AMQP, но способ, которым RabbitMQ обрабатывает клиентские API-интерфейсы для каждого языкового вида, сводит на нет всю цель использования не зависящего от языка протокола. Что если у меня есть клиент, на котором работает язык, для которого не написан поддерживаемый API? Некоторые из этих функций действительно хороши ... но излишни, когда все, что мне нужно сделать, это получить 1 сообщение из точки А в точку Б, и между ними ничего нет.
Кристофер

Я думал надеть API быстрого отдыха поверх него, который бы покрыл вашу агностическую озабоченность, но согласился, что, если вам никогда не понадобятся какие-либо функции, которые предлагает AMQP, это будет излишним (извините, если бы вы меня запустили затея на нем ...)
jleach

Да - быстрый REST API, чтобы покрыть это, работал бы ... но тогда я мог бы просто сделать REST API своим собственным. И никаких извинений не требуется - это отличная технология, а обучение необходимо для прогресса :), если не сейчас - я уверен, что оно пригодится в будущем.
Кристофер

3

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

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

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

Удачи!


1
Мне просто нравится возможность контролировать группы электронной почты, участников и другие полезные вещи, связанные с использованием реляционной базы данных. Проект базы данных - это то, с чего я начал в проекте, поэтому я даже не думал о его удалении. Спасибо за этот вклад и точку зрения !!
Кристофер

Я знал это! :) Понимание того, что вы действительно хотите получить от чего-то, является самой важной вещью. Ура!
Джона Бентон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.