Bonjour à tous !
J'ai commencé à traduire un petit livre :
««,
auteur : Jakub Korab, éditeur : O’Reilly Media, Inc., date de publication : juin 2017, ISBN : 9781492049296.
De l'introduction du livre :
«… Ce livre vous apprendra à réfléchir sur les systèmes d'échange de messages sur des courtiers, en comparant et en opposant deux technologies de courtage populaires : Apache ActiveMQ et Apache Kafka. Des exemples d'utilisation et des incitations au développement seront exposés pour montrer comment leurs développeurs ont adopté des approches complètement différentes dans le même domaine — l'échange de messages entre systèmes via un courtier intermédiaire. Nous examinerons ces technologies depuis le début et mettrons en évidence l'influence des diverses options de conception en chemin. Vous obtiendrez une compréhension approfondie des deux produits, de la manière dont ils doivent et ne doivent pas être utilisés, et des éléments à considérer lors de l'examen d'autres technologies d'échange de messages à l'avenir. …»
Les parties traduites jusqu'à présent :
Je publierai les chapitres terminés au fur et à mesure de la traduction.
CHAPITRE 1
Introduction
L'échange de messages inter-systèmes est l'un des domaines les moins compris de l'IT. En tant que développeur ou architecte, vous pouvez être bien familiarisé avec divers frameworks et bases de données. Cependant, il est fort probable que vous n'ayez qu'une connaissance superficielle du fonctionnement des technologies d'échange de messages basées sur des courtiers. Si vous ressentez cela, ne vous inquiétez pas, vous n'êtes pas seul.
Les gens interagissent généralement avec l'infrastructure d'échange de messages de manière très limitée. Ils se connectent souvent à un système créé il y a longtemps, ou téléchargent une distribution depuis Internet, l'installent dans l'environnement de production et commencent à écrire du code pour cela. Une fois l'infrastructure en place en production, les résultats peuvent être ambigus : perte de messages en cas de panne, 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 que votre code de messagerie fonctionne parfaitement, mais seulement jusqu'à ce qu'il cesse de fonctionner. Cette période endort la vigilance et procure un faux sentiment de sécurité, ce qui mène à encore plus de code basé sur de fausses représentations du comportement fondamental de la technologie. Lorsque les choses commencent à mal tourner, vous êtes confronté à la vérité inconfortable : vous n'avez en réalité pas compris le comportement de base du produit ou les compromis choisis par ses auteurs, tels que la performance contre la fiabilité, ou la transactionnalité contre la scalabilité horizontale.
Sans une compréhension approfondie du fonctionnement des brokers, les gens font des affirmations apparemment sensées sur leurs systèmes de messagerie, telles que :
- Le système ne perdra jamais de messages.
- Les messages seront traités de manière séquentielle.
- Ajouter des consommateurs rendra le système plus rapide.
- Les messages ne seront livrés qu'une seule fois.
Malheureusement, certaines de ces affirmations 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 à réfléchir sur les systèmes de messagerie basés sur des brokers, en comparant et en opposant deux technologies de brokers populaires : Apache ActiveMQ et Apache Kafka. Il présentera des cas d'utilisation et des motivations de développement qui ont poussé leurs créateurs à adopter des approches complètement différentes pour le même domaine : la messagerie entre systèmes avec un broker intermédiaire. Nous examinerons ces technologies depuis le début et mettrons en évidence l'influence de différentes options de conception en cours de route. Vous acquerrez une compréhension approfondie des deux produits, comprendrez comment ils devraient et ne devraient pas être utilisés, et saurez ce qu'il faut surveiller lorsque vous considérez 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 à quoi sert-il ?
Pour que deux applications puissent communiquer entre elles, elles doivent d'abord définir une interface. La définition de cette interface comprend le choix d'un transport ou d'un protocole, tel que HTTP, MQTT ou SMTP, et l'accord sur les formats de messages que les systèmes échangeront. Cela peut être un processus rigoureux, comme la définition d'un schéma XML avec des exigences sur la charge utile, ou cela peut être beaucoup moins formel, comme un accord entre deux développeurs indiquant qu'une certaine partie de la requête HTTP contiendra un identifiant client.
Tant que le format des messages et l'ordre dans lequel ils sont envoyés entre les systèmes sont convenus, ils pourront interagir les uns avec les autres sans se soucier de l'implémentation de l'autre système. Les entrailles de ces systèmes, telles que le langage de programmation ou le framework utilisé, peuvent changer au fil du temps. Tant que le contrat lui-même est maintenu, l'interaction peut continuer sans que l'autre côté ne change. Ces deux systèmes sont efficacement découplés par cette interface.
Les systèmes de messagerie prévoient généralement la participation d'un intermédiaire entre les deux systèmes qui interagissent, pour un découplage supplémentaire de l'expéditeur et du destinataire ou des destinataires. Dans ce cas, 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 d'exemplaires il y a.
Considérons quelques analogies des types de problèmes que résout un système de messagerie, et introduisons quelques termes de base.
Point à Point
Alexandra se rend à la poste pour envoyer un colis à Adam. Elle s'approche du comptoir et remet le colis à l'employé. L'employé prend le colis et remet à Alexandra un reçu. 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 peut continuer à vaquer à ses occupations. Plus tard, à un moment donné, Adam reçoit le colis.
C'est un exemple de modèle de messagerie point à point. Le bureau de poste agit ici comme un mécanisme de distribution de colis, garantissant que chaque colis sera livré une fois. L'utilisation du bureau de poste dissocie l'acte d'envoi d'un colis de la livraison du colis.
Dans les systèmes classiques de messagerie, le modèle « point à point » est mis en œuvre via un ordre. La file d'attente agit comme un tampon FIFO (premier arrivé, premier servi), auquel un ou plusieurs consommateurs peuvent s'abonner. Chaque message est livré uniquement à un des consommateurs abonnés. Les files d'attente essaient généralement de distribuer équitablement les messages entre les consommateurs. Un seul consommateur recevra ce message.
Le terme « fiable » (« durable ») est appliqué aux files d'attente. Fiabilité — c'est une propriété du service qui garantit que le système de messagerie conservera les messages en l'absence d'abonnés actifs jusqu'à ce qu'un consommateur s'abonne à la file d'attente pour la livraison des messages.
La fiabilité est souvent confondue avec la persistance et, bien que ces deux termes soient interchangeables, ils remplissent des fonctions différentes. La persistance détermine si le système de messagerie enregistre un message dans un type de stockage entre sa réception et son envoi au consommateur. Les messages envoyés à la file d'attente peuvent être ou ne pas être persistants.
La messagerie de type « point à point » est utilisée lorsque le cas d'utilisation nécessite une action unique sur un message. Un exemple pourrait être le dépôt de fonds sur un compte ou la passation d'une commande de livraison. Nous expliquerons plus tard pourquoi le système de messagerie ne peut pas garantir une livraison unique et pourquoi les files d'attente peuvent au mieux garantir la livraison au moins une fois.
Publication-abonnement
Gabriella compose le numéro de la conférence. Tant qu'elle est connectée à la conférence, elle entend tout ce que dit le conférencier, avec les autres participants à l'appel. Lorsqu'elle se déconnecte, elle manque ce qui a été dit. En se reconnectant, elle continue d'entendre ce qui est dit.
C'est un exemple de modèle de messagerie publication-abonnement. La conférence agit comme un mécanisme de diffusion. Le locuteur ne se soucie pas du nombre de personnes actuellement connectées à l'appel — le système garantit que toute personne connectée à ce moment-là entendra ce qui est dit.
Dans les systèmes classiques de messagerie, le modèle de messagerie « publication-abonnement » est mis en œuvre via des sujetsUn topic fournit un moyen de diffusion similaire à celui du mécanisme de conférence. Lorsqu'un message est envoyé à un topic, il est distribué à tous les utilisateurs abonnés..
Les topics sont généralement non fiables (nondurable).Tout comme un auditeur qui n'entend pas ce qui est dit lors d'un appel de conférence lorsqu'il se déconnecte, les abonnés à un topic manquent tout message envoyé pendant qu'ils sont hors ligne. C'est pourquoi on peut dire que les topics garantissent la livraison au plus une fois pour chaque consommateur.
Les messages de type « publication-abonnement » sont généralement utilisés lorsque les messages ont un caractère informatif, et la perte d'un message n'est pas très significative. Par exemple, un topic peut transmettre des lectures de température d'un groupe de capteurs une fois par seconde. Un système qui s'intéresse à la température actuelle et est abonné au topic ne s'inquiétera pas s'il manque un message - un autre viendra bientôt.
Modèles hybrides
Le site Web du magasin place les messages de commande dans une « file d'attente de messages ». Le principal consommateur de ces messages est le système d'exécution. 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 manquer de messages, même s'ils sont hors ligne pendant un certain temps. Le site Web ne doit pas connaître les autres systèmes.
Les scénarios d'utilisation nécessitent souvent une combinaison des modèles de messagerie « publication-abonnement » et « point à point », par exemple, lorsque plusieurs systèmes ont besoin d'une copie du message, et pour éviter la perte de message, à la fois la fiabilité et la persistance sont nécessaires.
Dans ces cas, un destinataire (destination) est requis (terme général pour les files d'attente et les topics), qui distribue les messages principalement comme un topic, de sorte que chaque message est envoyé à chaque système intéressé par ces messages, mais où chaque système peut également définir plusieurs consommateurs qui reçoivent les 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 exigent souvent de la fiabilité, donc si le consommateur se déconnecte, les messages envoyés à ce moment-là sont reçus après la reconnexion du 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 destinataires virtuels ou composites qui combinent des topics 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 certaine terminologie de base et une compréhension de ce que pourrait être un système de messagerie, passons aux détails.
Traduction effectuée par :
La prochaine partie traduite :
À suivre...
Source : habr.com
