J'ai besoin d'écrire un gestionnaire de système de notification.
Voici mes exigences:
Je dois pouvoir envoyer une notification sur différentes plates-formes, qui peuvent être totalement différentes (par exemple, je dois pouvoir envoyer un SMS ou un e-mail).
Parfois, la notification peut être la même pour tous les destinataires pour une plate-forme donnée, mais parfois elle peut être une notification par destinataire (ou plusieurs) par plate-forme.
Chaque notification peut contenir une charge utile spécifique à la plateforme (par exemple, un MMS peut contenir un son ou une image).
Le système doit être évolutif , je dois pouvoir envoyer une très grande quantité de notifications sans planter ni l'application ni le serveur.
Il s'agit d'un processus en deux étapes, tout d'abord un client peut taper un message et choisir une plate-forme vers laquelle envoyer, et la ou les notifications doivent être créées pour être traitées en temps réel ou plus tard.
Ensuite, le système doit envoyer la notification au fournisseur de la plate-forme.
Pour l'instant, je me retrouve avec certains mais je ne sais pas comment il sera évolutif ou si c'est un bon design.
J'ai pensé aux objets suivants (dans un pseudo langage):
un Notificationobjet générique :
class Notification {
String $message;
Payload $payload;
Collection<Recipient> $recipients;
}
Le problème avec les objets suivants est que si j'ai 1.000.000 destinataires? Même si l' Recipientobjet est très petit, cela prendra trop de mémoire.
Je pourrais également créer une notification par destinataire, mais certains fournisseurs de plate-forme m'obligent à l'envoyer par lots, ce qui signifie que je dois définir une notification avec plusieurs destinataires.
Chaque notification créée peut être stockée dans un stockage persistant comme une base de données ou Redis.
Serait-il bon d'agréger cela plus tard pour vous assurer qu'il est évolutif?
À la deuxième étape, je dois traiter cette notification.
Mais comment distinguer la notification au bon fournisseur de plateforme?
Dois-je utiliser un objet comme l' MMSNotificationextension d'un abstract Notification? ou quelque chose comme ça Notification.setType('MMS')?
Pour permettre de traiter beaucoup de notifications en même temps, je pense qu'un système de file d'attente de messagerie comme RabbitMQ peut être le bon outil. C'est ça?
Cela me permettrait de mettre en file d'attente beaucoup de notifications et de demander à plusieurs travailleurs de les afficher et de les traiter. Mais que faire si j'ai besoin de regrouper les destinataires comme indiqué ci-dessus?
Ensuite, j'imagine qu'un NotificationProcessorobjet pour lequel je pourrais ajouter NotificationHandlerchacun NotificationHandlerserait en charge de connecter le fournisseur de la plateforme et d'effectuer une notification.
Je peux également utiliser un EventManagerpour autoriser le comportement enfichable.
Des retours ou des idées?
Merci d'avoir donné de votre temps.
Remarque: j'ai l'habitude de travailler en PHP et c'est probablement la langue de mon choix.
Modifier (selon la réponse de morphunreal)
- Combien de messages par seconde envoyez-vous (Définissez les niveaux actuels / initiaux, définissez un niveau maximum que le système doit gérer avant d'être repensé)
- De quelles contraintes matérielles le système dispose-t-il (mémoire, cpu, etc. disponibles pour le système)
- Comment le matériel évoluera-t-il (c'est-à-dire en ajoutant plus de serveurs, le cloud computing, etc.)
- Quels langages / systèmes vont générer des notifications?
C'est moi-même, je suis en charge de créer la notification par programmation mais construite à partir d'une interface utilisateur.
- Le générateur connaît-il les destinataires du message (?) Ou sont-ils fournis par d'autres moyens (c.-à-d. Que les règles commerciales pour certains types d'alerte sont transmises à certains destinataires)
Il devrait être possible de créer une notification pour un destinataire spécifique, un groupe de destinataires (par exemple à l'aide d'un système de balises) ou pour une plate-forme entière.
- Existe-t-il des règles commerciales pour ajouter des reçus CC / BCC / Lire
Oui. Notez que cela est vraiment spécifique à la plate-forme et la lecture ou le cc ne sont pas disponibles sur toutes les plates-formes.
- Le générateur sait-il le type de message qu'il envoie (par exemple, SMS / e-mail) ou est-il basé sur le destinataire
Il est basé sur le destinataire, cependant, comme le destinataire est lié à la plate-forme et que les plates-formes ont une manière différente de gérer les données, l'interface utilisateur est susceptible d'être spécifique à la plate-forme pour permettre de configurer des images, un son ou quelque chose.
- Le générateur nécessite-t-il une confirmation des messages envoyés / reçus / lus (envoi asynchrone ou synchrone)
Eh bien, le système devrait être sujet aux erreurs, mais nous aimerions traiter l'erreur pour définir un ensemble de règles, par exemple, si le serveur est inaccessible, la notification doit être remise en file d'attente pour un processus ultérieur, mais si la notification est incorrecte (ou a été défini par le fournisseur de la plate-forme), il ne doit pas être remis en file d'attente mais notifié.
- Y a-t-il des exigences pour stocker un historique des sources / destinataires des messages (combien de temps?)
Oui, nous voulons probablement faire des statistiques et faire un rapport. * Définir les points de fin de notification
Quels services sont utilisés pour envoyer des messages? Cela dépend, certains sont des services Web REST classiques, d'autres sont des protocoles exotiques, c'est vraiment au fournisseur.
Quels commentaires / confirmations sont fournis (synchronisation / async)
Cela dépend, certains sont synchrones et répondent avec une erreur tandis que d'autres doivent être extraits par la suite pour vérifier les erreurs.
- Est-il susceptible d'ajouter de nouveaux points d'extrémité [même si c'est le cas, doit-il même être résumé]
Oui, en fait, notre application se développe et nous souhaitons probablement pouvoir ajouter un nouveau fournisseur, mais c'est un ratio de quelque chose comme 1 ou 2 par an.