Thèmes de Publish/subscribe

Matériaux préliminaires : Architecture Pub/sub.

Vue d'ensemble

Dans un système point à point typique, les applications s'envoient directement des messages, en sachant généralement qui sera le ou les destinataires.

D'autre part, les flux de travail de publish/subscribe sont organisés autour d'un concept de messages publiés vers des sujets avec éventuellement de nombreux abonnés dont l'endpoint de publication peut ne pas avoir connaissance.

Par exemple, un système de gestion de la relation client (CRM) peut vouloir publier des événements concernant des modifications apportées à des comptes clients. Dans un système d'entreprise, plusieurs destinataires seront intéressés par ces informations, mais le CRM lui-même n'a pas besoin de savoir de qui il s'agit.

Un autre exemple peut être un système de taux de change publiant des informations sur les derniers taux - il peut y avoir des dizaines ou des centaines d'applications abonnées à ce flux de mises à jour, chacune consommant l'information de manière indépendante, mais le système source n'a pas besoin de savoir qui elles sont, il se concentre simplement sur les publications et la livraison aux abonnés est effectuée par Zato.

Chaque sujet a un nom unique qui représente l'objet de l'information qui peut y être publiée, c'est-à-dire que les noms sont descriptifs et se rapportent à l'objet du sujet.

Les noms des rubriques suivent un arbre hiérarchique d'éléments, des moins spécifiques aux plus spécifiques. La barre oblique / a une signification particulière et est utilisée pour séparer les éléments commerciaux du nom. Il appartient aux utilisateurs de décider de la profondeur de l'imbrication du nom d'une rubrique, le cas échéant. Les noms doivent être en ASCII uniquement et ne peuvent pas dépasser 200 caractères.

Un exemple de sujet pourrait appartenir à un réseau d'appareils IoT dont l'un des sujets serait /asia/sg/changi/building/3/floor/9 - utilisé pour représenter les événements liés aux appareils du 9ème étage du Building 3 dans le Changi Business Park à Singapour, en Asie.

Un autre exemple de nom pourrait être /customer/new utilisé par des applications pour publier et consommer des messages sur les nouveaux clients dans un système particulier.

Configuration

Chaque nom doit être unique - les détails sur la façon de former les noms sont présentés dans l'aperçu de ce chapitre.

Un sujet peut être actif ou inactif. S'il est inactif, aucun nouveau message ne peut y être publié. Si les clients essaient de le faire, ils recevront un message d'erreur.

Lorsqu'un message est publié dans le sujet, sa liste de destinataires est établie une fois, au moment où le message est publié. Si des abonnés apparaissent pendant que le message est remis aux destinataires originaux, les nouveaux ne recevront pas le message.

Chaque sujet peut avoir la garantie de livraison (GD) activée. Ce paramètre indique si les messages publiés sur le sujet doivent être couverts par défaut par la GD, bien qu'il puisse également être défini ou remplacé sur une base individuelle pour chaque message.

Si un message utilise la GD, son contenu sera stocké dans une base de données SQL jusqu'à ce que tous les abonnés du sujet existant au moment de la publication du message confirment qu'ils l'ont reçu.

Les messages destinés à des sujets non GD qui n'ont pas d'abonnés au moment de leur publication sont transformés en messages GD.

Pour chaque rubrique, il est possible de définir un indicateur qui permet aux clients API externes de s'y abonner. Si cette option n'est pas cochée, seuls les administrateurs pourront créer de nouveaux abonnements à cette rubrique. Dans certains cas, une surveillance étroite est nécessaire pour savoir quelles applications s'abonnent à une rubrique et les abonnements API peuvent être désactivés. Dans d'autres cas, il peut y avoir tellement d'abonnés dynamiques et transitoires que l'administration manuelle ne sera pas possible, dans cette situation, les abonnements API peuvent être activés.

Les clients basés sur les WebSockets s'abonnent toujours par le biais d'appels API et dans les scénarios utilisant des clients WebSockets, les abonnements API doivent être activés pour les sujets correspondants.

Les sujets ont leurs profondeurs - maintenues individuellement pour les messages GD et non-GD (in-RAM). Si la profondeur actuelle atteint le maximum, tous les nouveaux messages seront rejetés. La profondeur d'un sujet n'a pas de limites fixes, mais notez que les messages in-RAM sont en effet conservés dans la RAM des serveurs, qui est généralement une ressource plus rare que le stockage sur disque pour les messages GD - il faut faire attention à ne pas manquer de RAM.

La fréquence de vérification de la profondeur spécifie après un dans combien de messages la profondeur actuelle sera vérifiée pour savoir si elle a atteint sa valeur maximale. Par exemple, supposons qu'un sujet ait une profondeur de 1000 et que la fréquence soit de 100. Puisque la profondeur sera vérifiée après 1 message publié sur 100, il est possible que la profondeur atteigne 1100 dans le pire des cas avant que l'on découvre qu'aucun nouveau message ne doit être autorisé.

La raison pour laquelle la profondeur n'est pas vérifiée exactement avant chaque publication est l'efficacité - dans la plupart des applications professionnelles, il n'y a presque jamais de différence s'il y a quelques dizaines de messages supplémentaires dans le sujet, mais les performances peuvent être visiblement améliorées si seulement 1 sur 100 est vérifié. Si une exactitude absolue est requise, la fréquence peut être fixée à 1, ce qui signifie que chaque message publié déclenchera une vérification en profondeur.

Pour les messages non GD, la profondeur du sujet actuel est calculée séparément pour chaque serveur Zato. Pour les sujets GD, elle est comptée globalement.

Les intervalles de synchronisation et de livraison concernent la fréquence à laquelle les serveurs synchronisent en interne l'état actuel des livraisons à un sujet particulier. Pour chaque sujet, il y a exactement un serveur qui sera responsable des livraisons à ce sujet. L'intervalle de livraison indique à quelle fréquence ce serveur enverra ses messages aux destinataires. Inversement, l'intervalle de synchronisation détermine la fréquence à laquelle les autres serveurs envoient les messages qu'ils ont reçus pour le sujet à ce serveur de livraison.

Pour chaque sujet, il est possible d'assigner un service qui s'exécutera à des moments spécifiques, par exemple, avant que le message soit publié ou avant qu'il soit livré à un abonné. Le service a accès à toutes les données et métadonnées de l'entreprise. Cela permet, par exemple, de transformer les messages en fonction du destinataire, en modifiant éventuellement le format des données ou en les enrichissant avec des données obtenues en invoquant d'autres services.

Sujets connexes