Architecture du système d'alerte

Je voudrais créer un système qui gère les messages d'alerte de divers programmes et peut traiter ces alertes par e-mail auprès des consommateurs en aval. Tout cela serait contenu sur un seul réseau interne.

Je pense que je veux que l'architecture de base ressemble à ceci:

La principale préoccupation que j'ai actuellement est le bit "Message Handler", qui sera mon "sort-of-API". Je veux que tous les composants de ce système envoient des données à l'API, qui gère toutes les écritures dans la base de données. Je pense que cette approche est plus facile car elle simplifie la sécurité et me permet de contenir un grand nombre des requêtes DB les plus compliquées dans un seul programme.

Le souci est que je veux que ce soit indépendant du langage - ce qui signifie que tout code devrait être capable d'envoyer des messages à mon gestionnaire - qui les interprétera. J'espère le faire via des fichiers plats JSON - ou via des appels REST au programme (ce qui donne de la flexibilité aux applications en aval).

Ma question est-

Dois-je me soucier du gestionnaire de messages - ou ajouterait-il de la simplicité pour permettre uniquement l'accès direct à la base de données aux applications en aval, ainsi qu'aux deux autres composants (Management Console et Alert Manager)?

De cette façon, ils peuvent insérer l'alerte qu'ils souhaitent - tant que l'INSERT dans la / les table (s) DB est valide.

Je ne suis pas un concepteur de logiciels de métier alors excusez-moi - je veux juste un projet à faire pendant mon temps libre.

Avez-vous étudié AMQP (Advanced Message Queuing Protocol: https://www.rabbitmq.com/protocol.html )?

RabbitMQ est un outil génial pour quelque chose comme ça, je pense (il y en a aussi d'autres, MSMQ, Azure / AWS, etc.). Non seulement vous obtenez un gestionnaire de messages indépendant de la langue (simple "envoyer le message au serveur de messages avec des données json"), vous détachez le traitement des messages en aval et le rendez bien isolé. Exécutez un service de messagerie qui traite les messages entrants de la ou des files d'attente dont vous avez besoin et crachez vos notifications.

L'une des raisons pour lesquelles j'aime vraiment utiliser AMQP est que vous commencez comme si vous étiez maintenant avec une solution maison, mais réalisez que vous devez gérer les messages légèrement différemment selon le type, vers qui il doit aller, etc. , vous finissez donc par créer votre propre implémentation AMQP.

Que faites-vous si un message doit être envoyé à 5 destinataires différents? Que se passe-t-il si vous avez un message qui doit être tourné sur un certain nombre de processeurs (pensez aux tâches de longue durée et au nombre X de processeurs simultanés, où vous pouvez faire un tour de table des messages d'un type spécifique). Et si le message devait aller à une personne, mais s'il n'est pas disponible / en ligne, il devrait aller à une autre? L'AMQP gère déjà tout cela (très bien!), Avec une très bonne catégorisation, des files d'attente, des canaux, une persistance durable, toutes sortes de fonctionnalités.

Voici un aperçu de base des scénarios qu'il peut gérer (notez que ce n'est pas spécifique à RabbitMQ: c'est une chose AMQP, mais RabbitMQ arrive à bien l'expliquer) - https://www.rabbitmq.com/getstarted.html

Question très bien cadrée!

Ainsi, toutes les décisions architecturales impliquent des compromis. Si vous êtes curieux de discuter des compromis, modifiez peut-être votre question dans ce sens. Au lieu de cela, puisque la question demande simplement une position, je prendrai le parti de plaider en faveur du MessageHandler. Je vais aller plus loin pour suggérer de ne PAS inclure de base de données - du moins pas une base de données SQL, du moins de ne pas commencer. Demandez simplement au MessageHandler d'enregistrer le JSON dans le système de fichiers, par exemple un répertoire par heure de réception des alertes (en fonction du volume, bien sûr), et disposez de l'API lorsque le gestionnaire d'alertes l'interroge, parcourez simplement les 2 derniers répertoires de des alertes pour décider quels e-mails envoyer (en fonction de la priorité, bien sûr).

Il y a une tonne de bonnes choses à mâcher dans ce problème, et garder une base de données hors de l'image dès les premiers stades supprimera beaucoup de bruit incident et de résolution de problème inutile. Bien sûr, vous avez peut-être un amour caché de créer des modèles de données relationnelles et rêvez d'écrire du SQL. Dans ce cas, cette réponse est totalement fausse. Mais de manière générale, même les bases de données les plus agiles sont de terribles plates-formes d'application, et elles ne sont incluses dans les systèmes que parce qu'elles sont spécialistes de la durabilité et des requêtes indexées.

Bonne chance!