Comprendre les courtiers de messages. Apprentissage de la mécanique de la messagerie via ActiveMQ et Kafka. Chapitre 1

Bonjour à tous!

A commencé à traduire un petit livre:
" Comprendre les courtiers de messages ",
auteur: Jakub Korab, éditeur: O'Reilly Media, Inc., date de publication: juin 2017, ISBN: 9781492049296.

De l'introduction au livre:
"... Ce livre vous apprendra à parler des systèmes de messagerie sur les courtiers en comparant et en contrastant deux technologies de courtier populaires: Apache ActiveMQ et Apache Kafka. Vous trouverez ici des exemples d'incitations à l'utilisation et au développement qui ont conduit leurs développeurs à utiliser des approches complètement différentes pour dans le même domaine - la messagerie entre les systèmes avec un courtier intermédiaire.Nous examinerons ces technologies à partir de zéro et soulignerons l'influence des différentes options de conception en cours de route.Vous obtiendrez une compréhension approfondie des deux produits, une compréhension de la façon dont ils doivent et ne doivent pas être utilisés, et une compréhension de ce qu'il faut rechercher lorsque l'on envisage d'autres technologies de messagerie à l'avenir ... "

Pièces traduites à ce jour:
Chapitre 1. Introduction
Chapitre 2. ActiveMQ
Chapitre 3. Kafka

Traduction terminée: tele.gg/middle_java

Je publierai les chapitres terminés au fur et à mesure de leur traduction.

CHAPITRE 1

Présentation

La messagerie intersystème est l'un des domaines informatiques les moins bien compris. En tant que développeur ou architecte, vous connaissez peut-être divers cadres et bases de données. Cependant, il est probable que vous ne connaissiez que de façon temporaire le fonctionnement des technologies de messagerie basées sur les courtiers. Si vous ressentez cela, ne vous inquiétez pas, vous êtes en bonne compagnie.

Les gens ont généralement un contact très limité avec l'infrastructure de messagerie. Souvent, ils se connectent à un système créé il y a longtemps ou téléchargent un kit de distribution sur Internet, l'installent dans PROM et commencent à écrire du code pour cela. Après le lancement de l'infrastructure dans PROM, les résultats peuvent être mitigés: perte de messages lors d'échecs, l'envoi ne fonctionne pas comme prévu, ou les courtiers «suspendent» vos producteurs ou n'envoient pas de messages à vos consommateurs.

Cela vous semble familier?

Un scénario courant est lorsque votre code de messagerie fonctionne correctement, pour le moment. Jusqu'à ce qu'il cesse de fonctionner. Cette période endort la vigilance et donne un faux sentiment de sécurité, ce qui conduit à encore plus de code basé sur de fausses idées sur le comportement fondamental de la technologie. Lorsque quelque chose commence à mal tourner, vous êtes confronté à une vérité inconfortable: vous n'avez vraiment pas compris le comportement de base du produit ou les compromis choisis par les auteurs, tels que performance contre fiabilité, ou transactionnalité contre évolutivité horizontale.

Sans une compréhension approfondie du fonctionnement des courtiers, les gens font des déclarations apparemment raisonnables sur leurs systèmes de messagerie, telles que:

• Le système ne perdra jamais de messages
• Les messages seront traités séquentiellement
• L'ajout de consommateurs accélérera le système
• Les messages ne seront livrés qu'une seule fois.

Malheureusement, certaines de ces déclarations sont basées sur des hypothèses qui ne s'appliquent que dans certaines circonstances, tandis que d'autres sont tout simplement incorrectes.

Ce livre vous apprendra à parler des systèmes de messagerie basés sur un courtier en comparant et en contrastant deux technologies de courtier populaires: Apache ActiveMQ et Apache Kafka. Nous décrirons ici des exemples d'incitations à l'utilisation et au développement qui ont conduit leurs développeurs à utiliser des approches complètement différentes pour le même domaine - la messagerie entre les systèmes avec un courtier intermédiaire. Nous examinerons ces technologies à partir de zéro et soulignerons l'impact des différentes options de conception en cours de route. Vous allez acquérir une compréhension approfondie des deux produits, une compréhension de la façon dont ils doivent et ne doivent pas être utilisés, et une compréhension de ce qu'il faut rechercher lors de l'examen d'autres technologies de messagerie à l'avenir.

Avant de commencer, passons en revue les bases.

Qu'est-ce qu'un système de messagerie et pourquoi est-il nécessaire

Pour que deux applications communiquent entre elles, elles doivent d'abord définir une interface. La définition de cette interface comprend la sélection d'un transport ou d'un protocole, tel que HTTP, MQTT ou SMTP, et la négociation des formats de message que les systèmes échangeront. Il peut s'agir d'un processus rigoureux, tel que la définition d'un schéma XML avec les exigences de charge utile d'un message, ou il peut être beaucoup moins formel, par exemple, un accord entre deux développeurs qu'une partie de la demande HTTP contiendra un identifiant client .

Tant que le format du message et l'ordre d'envoi entre les systèmes sont cohérents, ils pourront interagir entre eux sans se soucier de la mise en œuvre d'un autre système. Les composants internes de ces systèmes, tels qu'un langage de programmation ou un framework utilisé, peuvent changer avec le temps. Tant que le contrat lui-même est pris en charge, l'interaction peut continuer inchangée de l'autre côté. Les deux systèmes sont effectivement déconnectés (séparés) par cette interface.

Les systèmes de messagerie, en règle générale, prévoient la participation d'un intermédiaire entre deux systèmes qui interagissent pour désengager (séparer) davantage l'expéditeur du ou des destinataires. Dans le même temps, le système de messagerie permet à l'expéditeur d'envoyer un message sans savoir où se trouve le destinataire, s'il est actif ou combien se trouvent.

Examinons quelques analogies des variétés de problèmes qu'un système de messagerie résout et introduisons quelques termes de base.

Point à point

Alexandra se rend au bureau de poste pour envoyer un colis à Adam. Elle se dirige vers la fenêtre et tend un paquet à l'employé. L'employé prend le colis et donne un reçu à Alexandra. Adam n'a pas besoin d'être à la maison au moment de l'envoi du colis. Alexandra est convaincue que le colis sera livré à Adam à un moment donné dans le futur et pourra continuer à faire son propre travail. Plus tard, à un moment donné, Adam reçoit le colis.

Ceci est un exemple de modèle de messagerie point à point . Le bureau de poste agit ici comme un mécanisme de distribution des colis, garantissant que chaque colis est livré une fois. L'utilisation de la poste sépare l'acte d'envoi du colis de la livraison du colis.
Dans les systèmes de messagerie classiques, le modèle point à point est implémenté via des files d'attente . La file d'attente agit comme un tampon FIFO (premier entré, premier sorti) auquel un ou plusieurs consommateurs peuvent s'abonner. Chaque message est remis à un seul des consommateurs abonnés . Les files d'attente tentent généralement de répartir équitablement les messages entre les consommateurs. Un seul consommateur recevra ce message.

Le terme "durable" est appliqué aux files d'attente. La fiabilité est une caractéristique du service qui garantit que le système de messagerie enregistre les messages lorsqu'il n'y a pas d'abonnés actifs jusqu'à ce que le consommateur s'abonne à la file d'attente pour la remise des messages.

La fiabilité est souvent confondue avec la persistance et, bien que les deux termes soient utilisés de manière interchangeable, ils remplissent des fonctions différentes. La persistance détermine si le message est échangé par le système de messagerie dans tout type de stockage entre sa réception et son envoi au consommateur. Les messages envoyés à la file d'attente peuvent être persistants ou non.
La messagerie point à point est utilisée lorsqu'un cas d'utilisation nécessite une action ponctuelle avec un message. Par exemple, déposer des fonds sur un compte ou remplir un ordre de livraison. Nous verrons plus loin pourquoi le système de messagerie lui-même n'est pas en mesure de fournir une livraison unique et pourquoi les files d'attente peuvent au mieux fournir une garantie de livraison au moins une fois .

Abonné éditeur

Gabriella compose le numéro de la conférence. Pendant qu'elle est connectée à la conférence, elle entend tout ce que dit l'oratrice, ainsi que les autres participants à l'appel. Quand elle s'éteint, elle ignore ce qui est dit. Une fois reconnectée, elle continue d'entendre ce qu'ils disent.

Ceci est un exemple de modèle de messagerie de publication-abonnement . La conférence agit comme un mécanisme de diffusion. La personne qui parle ne se soucie pas du nombre de personnes qui se joignent actuellement à l'appel - le système garantit que toute personne connectée en ce moment entend ce qui se dit.
Dans les systèmes de messagerie classiques, le modèle de messagerie publication-abonnement est implémenté via des rubriques . La rubrique fournit la même méthode de diffusion que le mécanisme de conférence. Lorsqu'un message est envoyé au sujet, il est distribué à tous les utilisateurs abonnés .

Les sujets ne sont généralement pas fiables (non durables) . Comme un auditeur qui n'entend pas ce qui est dit lors de la conférence téléphonique, lorsque l'écouteur se déconnecte, les abonnés du sujet ignorent tous les messages envoyés lorsqu'ils sont hors ligne. Pour cette raison, on peut dire que les sujets offrent une garantie de livraison pas plus d'une fois pour chaque consommateur.

La messagerie de publication-abonnement est généralement utilisée lorsque les messages sont de nature informative et que la perte d'un message n'est pas particulièrement importante. Par exemple, un sujet peut transmettre des relevés de température à partir d'un groupe de capteurs une fois par seconde. Un système qui s'intéresse à la température actuelle et qui souscrit au sujet ne s'inquiétera pas s'il manque un message - un autre arrivera dans un avenir proche.

Modèles hybrides

Le site Web du magasin place les messages de commande dans la file d'attente des messages. Le principal consommateur de ces messages est le système exécutif. De plus, le système d'audit doit avoir des copies de ces messages de commande pour un suivi ultérieur. Les deux systèmes ne peuvent pas ignorer les messages, même si les systèmes eux-mêmes ne sont pas disponibles pendant un certain temps. Un site Web ne doit pas connaître d'autres systèmes.

Les scénarios d'utilisation nécessitent souvent la combinaison de modèles de messagerie publication-abonnement et point à point, par exemple, lorsque plusieurs systèmes nécessitent une copie du message, et que la fiabilité et la persistance sont nécessaires pour éviter la perte de message.

Dans ces cas, une destination est requise (un terme général pour les files d'attente et les sujets), qui distribue les messages principalement en tant que sujet, de sorte que chaque message est envoyé à un système distinct qui s'intéresse à ces messages, mais aussi dans lequel chaque système peut définir plusieurs les consommateurs qui reçoivent des messages entrants, ce qui ressemble plus à une file d'attente. Le type de lecture dans ce cas est une fois pour chaque partie intéressée . Ces destinataires hybrides nécessitent souvent une durabilité, donc si le consommateur se déconnecte, les messages qui sont envoyés à ce moment sont reçus après avoir reconnecté le consommateur.

Les modèles hybrides ne sont pas nouveaux et peuvent être utilisés dans la plupart des systèmes de messagerie, y compris ActiveMQ (via des destinations virtuelles ou composites qui combinent des sujets et des files d'attente), et Kafka (implicitement, en tant que propriété fondamentale de la conception de son destinataire).

Maintenant que nous avons une terminologie de base et une compréhension de l'utilité d'un système de messagerie, passons aux détails.

Traduction terminée: tele.gg/middle_java

Partie suivante: Chapitre 2. ActiveMQ

À suivre ...