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 au livre :
«... Ce livre vous apprendra comment penser aux systèmes de messagerie négociés en comparant et en opposant deux technologies de courtage populaires : Apache ActiveMQ et Apache Kafka. Il décrira les cas d'utilisation et les incitations au développement qui ont conduit leurs développeurs à adopter des approches très différentes dans le même domaine de la messagerie négociée entre les systèmes. Nous examinerons ces technologies de fond en comble et soulignerons l'impact des différents choix de conception en cours de route. Vous acquerrez 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. ... "
Parties traduites jusqu'à présent :
Je publierai les chapitres terminés au fur et à mesure qu'ils seront traduits.
CHAPITRE 1
introduction
La messagerie intersystème est l'un des domaines les moins compris de l'informatique. En tant que développeur ou architecte, vous connaissez peut-être très bien divers frameworks et bases de données. Cependant, il est probable que vous n'ayez qu'un aperçu du fonctionnement des technologies de messagerie basées sur les courtiers. Si c'est ce que vous ressentez, 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 la PROM et commencent à écrire du code pour celui-ci. Une fois que l'infrastructure est opérationnelle en PROM, les résultats peuvent être mitigés : les messages sont perdus en cas de plantage, les envois ne fonctionnent pas comme prévu, ou les courtiers suspendent vos producteurs ou n'envoient pas de messages à vos consommateurs.
Sonne familier?
Un scénario courant où 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 les choses commencent à mal tourner, vous êtes confronté à une vérité inconfortable : vous n'avez vraiment pas compris le comportement sous-jacent du produit, ou les compromis choisis par les auteurs, tels que la performance par rapport à la robustesse, ou le transactionnel par rapport à l'horizontal. évolutivité.
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 rendra le système plus rapide
- 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 fausses.
Ce livre vous apprendra à raisonner sur les systèmes de messagerie négociés en comparant et en opposant deux technologies de courtier populaires : Apache ActiveMQ et Apache Kafka. Il décrira les cas d'utilisation et les incitations au développement qui ont conduit leurs développeurs à adopter des approches très différentes dans le même domaine de la messagerie négociée entre les systèmes. Nous examinerons ces technologies de fond en comble et soulignerons l'impact des différents choix de conception en cours de route. Vous acquerrez 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 inclut le choix d'un transport ou d'un protocole tel que HTTP, MQTT ou SMTP, et la négociation des formats de messages que les systèmes échangeront. Cela peut être un processus strict, comme la définition d'un schéma XML avec des exigences de coût de charge utile pour un message, ou cela peut être beaucoup moins formel, comme un accord entre deux développeurs selon lequel une partie d'une requête HTTP contiendra un identifiant client. .
Tant que le format des messages et l'ordre dans lequel ils sont envoyés sont cohérents entre les systèmes, ils pourront communiquer entre eux sans se soucier de la mise en œuvre de l'autre système. Les composants internes de ces systèmes, tels que le langage de programmation ou le cadre utilisé, peuvent changer au fil du temps. Tant que le contrat lui-même est maintenu, l'interaction peut continuer sans changement de l'autre côté. Les deux systèmes sont effectivement découplés (séparés) par cette interface.
Les systèmes de messagerie impliquent généralement un intermédiaire entre deux systèmes qui interagissent pour découpler (séparer) davantage l'expéditeur 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 de ses instances.
Examinons quelques analogies pour les types de problèmes qu'un système de messagerie résout et introduisons quelques termes de base.
Point à point
Alexandra se rend à la poste pour envoyer un colis à Adam. Elle va à la fenêtre et tend le colis à l'employé. L'employé récupère le colis et remet un reçu à Alexandra. Adam n'a pas besoin d'être à la maison lorsque le colis est envoyé. Alexandra est convaincue que le colis sera livré à Adam à un moment donné dans le futur et pourra continuer à vaquer à ses occupations. Plus tard, à un moment donné, Adam reçoit un colis.
Ceci 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 est livré une seule fois. L'utilisation de la poste dissocie 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 les 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 délivré uniquement un des consommateurs abonnés. Les files d'attente tentent généralement de distribuer équitablement les messages entre les consommateurs. Un seul consommateur recevra ce message.
Le terme "durable" s'applique aux files d'attente. Fiabilité est une propriété de service qui garantit que le système de messagerie conservera les messages en l'absence d'abonnés actifs jusqu'à ce que le consommateur s'abonne à la file d'attente de livraison des messages.
La fiabilité est souvent confondue avec persistance et, bien que les deux termes soient interchangeables, ils remplissent des fonctions différentes. La persistance détermine si un message est écrit par le système de messagerie dans une sorte de stockage entre sa réception et son envoi au consommateur. Les messages envoyés à la file d'attente peuvent ou non être persistants.
La messagerie point à point est utilisée lorsqu'un cas d'utilisation nécessite une action unique sur un message. Les exemples incluent le dépôt de fonds sur un compte ou l'exécution d'un bon de livraison. Nous verrons plus tard pourquoi un système de messagerie en lui-même est incapable de fournir une livraison unique et pourquoi les files d'attente peuvent au mieux fournir une garantie de livraison. au moins une fois.
Éditeur-Abonné
Gabriella compose le numéro de la conférence. Lorsqu'elle est connectée à la conférence, elle entend tout ce que dit l'orateur, ainsi que les autres participants à l'appel. Quand elle s'évanouit, elle manque ce qui se dit. Lors de la reconnexion, elle continue d'entendre ce qui se dit.
Ceci est un exemple de modèle de messagerie publier-s'abonner. La conférence téléphonique agit comme un mécanisme de diffusion. La personne qui parle ne se soucie pas du nombre de personnes actuellement en ligne - le système garantit que toute personne actuellement connectée entendra ce qui se dit.
Dans les systèmes de messagerie classiques, le modèle de messagerie de publication-abonnement est mis en œuvre via hauts. Une rubrique fournit la même méthode de diffusion que le mécanisme de conférence. Lorsqu'un message est publié dans un sujet, il est distribué pour tous les utilisateurs abonnés.
Sujets généralement peu fiable (non durable). Comme un auditeur qui ne peut pas entendre ce qui se dit lors d'une conférence téléphonique, lorsque l'auditeur se déconnecte, les abonnés au sujet ratent tous les messages envoyés lorsqu'ils sont hors ligne. Pour cette raison, on peut dire que les tops offrent une garantie de livraison. pas plus d'une fois pour chaque consommateur.
La messagerie Publish-Subscribe est généralement utilisée lorsque les messages sont de nature informative et que la perte d'un seul message n'est pas particulièrement importante. Par exemple, un sujet peut transmettre les relevés de température d'un groupe de capteurs une fois par seconde. Un système qui s'intéresse à la température actuelle et qui s'abonne à un sujet ne s'inquiétera pas s'il manque un message - un autre arrivera 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 exécutif. En outre, le système d'audit doit disposer de copies de ces messages de commande pour un suivi ultérieur. Les deux systèmes ne peuvent pas manquer de messages, même si les systèmes eux-mêmes sont indisponibles pendant un certain temps. Le site Web ne doit pas être au courant d'autres systèmes.
Les cas d'utilisation nécessitent souvent une combinaison de modèles de messagerie de publication-abonnement et point à point, par exemple lorsque plusieurs systèmes ont besoin d'une copie d'un message et que la fiabilité et la persistance sont nécessaires pour éviter la perte de message.
Dans ces cas, une destination (terme général désignant les files d'attente et les sujets) est requise, qui distribue les messages essentiellement comme un sujet, de sorte que chaque message soit envoyé à un système séparé intéressé par ces messages, mais aussi dans lequel chaque système peut définir plusieurs consommateurs qui reçoivent les messages entrants, qui ressemble plus à une file d'attente. Le type de lecture dans ce cas est − une fois pour chaque partie prenante. Ces destinations hybrides nécessitent souvent de la durabilité afin que si un consommateur se déconnecte, les messages envoyés à ce moment-là soient acceptés lorsque le consommateur se reconnecte.
Les modèles hybrides ne sont pas nouveaux et peuvent être appliqués à 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 sa conception de destination).
Maintenant que nous avons une terminologie de base et une compréhension de ce à quoi un système de messagerie pourrait être utile, entrons dans les détails.
Traduction faite :
Prochaine partie traduite :
A suivre ...
Source: habr.com