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

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

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

Основна проблема, яку я маю на даний момент, - це біт "Обробник повідомлень", який буде моїм "сортуванням 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, коли запит менеджера сповіщень просто перейде через останні два каталоги попередження, щоб вирішити, які електронні листи потрібно надсилати (звичайно, залежно від пріоритету).

У цій проблемі є багато корисних речей, а збереження бази даних на малюнку на ранніх етапах призведе до усунення безлічі випадкових шумів та непотрібного вирішення проблем. Звичайно, можливо, у вас є прихована любов до створення реляційних моделей даних і мрієте написати SQL. У цьому випадку ця відповідь є абсолютно неправильною. Але взагалі навіть найспритніші бази даних є жахливими платформами додатків, і вони включаються в системи лише через те, що вони фахівці за довговічністю та індексованим запитом.

Удачі!