Înțelegerea brokerilor de mesaje. Învățarea mecanismelor de mesagerie cu ActiveMQ și Kafka. Capitolul 1

Bună ziua tuturor!

Am început să traduc o carte mică:
«Înțelegerea brokerilor de mesaje“,
autor: Jakub Korab, editor: O'Reilly Media, Inc., data publicării: iunie 2017, ISBN: 9781492049296.

Din introducerea cărții:
«... Această carte vă va învăța cum să vă gândiți la sistemele de mesagerie intermediate, comparând și contrastând două tehnologii de intermediere populare: Apache ActiveMQ și Apache Kafka. Acesta va schița cazurile de utilizare și stimulentele de dezvoltare care i-au determinat pe dezvoltatorii lor să adopte abordări foarte diferite în aceeași zonă de mesagerie intermediată între sisteme. Vom arunca o privire asupra acestor tehnologii de la zero și vom evidenția impactul diferitelor alegeri de design pe parcurs. Veți dobândi o înțelegere profundă a ambelor produse, o înțelegere a modului în care ar trebui și nu ar trebui să fie utilizate și o înțelegere la ce să aveți în vedere atunci când luați în considerare alte tehnologii de mesagerie în viitor. ... »

Părți traduse până acum:
Capitolul 1 Introducere
Capitolul 3. Kafka

Voi posta capitolele finalizate pe măsură ce sunt traduse.

CAPITOLUL 1

Introducere

Mesageria intersistem este una dintre cele mai puțin înțelese domenii ale IT. În calitate de dezvoltator sau arhitect, este posibil să fiți foarte familiarizat cu diverse cadre și baze de date. Cu toate acestea, este probabil să aveți doar o privire asupra modului în care funcționează tehnologiile de mesagerie bazate pe broker. Dacă așa simți, nu-ți face griji, ești într-o companie bună.

Oamenii au de obicei un contact foarte limitat cu infrastructura de mesagerie. Adesea se conectează la un sistem creat cu mult timp în urmă sau descarcă un kit de distribuție de pe Internet, îl instalează în PROM și încep să scrie cod pentru el. Odată ce infrastructura este pusă în funcțiune în PROM, rezultatele pot fi amestecate: mesajele se pierd la blocări, trimiterile nu funcționează așa cum vă așteptați sau brokerii vă agăță producătorii sau nu trimit mesaje consumatorilor.

Sună cunoscut?

Un scenariu comun în care codul de mesagerie funcționează bine, deocamdată. Până nu mai funcționează. Această perioadă liniștește vigilența și dă un fals sentiment de securitate, ceea ce duce la și mai mult cod bazat pe idei false despre comportamentul fundamental al tehnologiei. Când lucrurile încep să meargă prost, te confrunți cu un adevăr inconfortabil: că într-adevăr nu ai înțeles comportamentul de bază al produsului sau compromisurile alese de autori, cum ar fi performanță vs robustețe sau tranzacțional vs. scalabilitate orizontală.

Fără o înțelegere profundă a modului în care funcționează brokerii, oamenii fac afirmații aparent rezonabile despre sistemele lor de mesagerie, cum ar fi:

  • Sistemul nu va pierde niciodată mesajele
  • Mesajele vor fi procesate secvenţial
  • Adăugarea de consumatori va face sistemul mai rapid
  • Mesajele vor fi livrate o singură dată

Din păcate, unele dintre aceste afirmații se bazează pe presupuneri care se aplică numai în anumite circumstanțe, în timp ce altele pur și simplu nu sunt adevărate.

Această carte vă va învăța cum să raționați despre sistemele de mesagerie intermediate, comparând și contrastând două tehnologii de broker populare: Apache ActiveMQ și Apache Kafka. Acesta va schița cazurile de utilizare și stimulentele de dezvoltare care i-au determinat pe dezvoltatorii lor să adopte abordări foarte diferite în aceeași zonă de mesagerie intermediată între sisteme. Vom arunca o privire asupra acestor tehnologii de la zero și vom evidenția impactul diferitelor alegeri de design pe parcurs. Veți dobândi o înțelegere profundă a ambelor produse, o înțelegere a modului în care ar trebui și nu ar trebui să fie utilizate și o înțelegere la ce să aveți în vedere atunci când luați în considerare alte tehnologii de mesagerie în viitor.

Înainte de a începe, să trecem peste elementele de bază.

Ce este un sistem de mesagerie și de ce este necesar

Pentru ca două aplicații să comunice între ele, trebuie mai întâi să definească o interfață. Definiția acestei interfețe include alegerea unui transport sau a unui protocol precum HTTP, MQTT sau SMTP și negocierea formatelor de mesaj pe care sistemele le vor schimba. Acesta poate fi un proces strict, cum ar fi definirea unei scheme XML cu cerințe de costuri utile pentru un mesaj, sau poate fi mult mai puțin formal, cum ar fi un acord între doi dezvoltatori conform căruia o parte a unei cereri HTTP va conține un identificator de client.

Atâta timp cât formatul mesajelor și ordinea în care sunt trimise sunt consecvente între sisteme, acestea pot comunica între ele fără a-și face griji cu privire la implementarea celuilalt sistem. Elementele interne ale acestor sisteme, cum ar fi limbajul de programare sau cadrul utilizat, se pot schimba în timp. Atâta timp cât contractul în sine este menținut, interacțiunea poate continua fără modificări din partea cealaltă. Cele două sisteme sunt efectiv decuplate (separate) de această interfață.

Sistemele de mesagerie implică de obicei un intermediar între două sisteme care interacționează pentru a decupla (separa) în continuare expeditorul de destinatar sau destinatari. În acest caz, sistemul de mesagerie permite expeditorului să trimită un mesaj fără a ști unde se află destinatarul, dacă este activ sau câte dintre instanțe ale acestuia.

Să ne uităm la câteva analogii pentru tipurile de probleme pe care le rezolvă un sistem de mesagerie și să introducem câțiva termeni de bază.

Punct la punct

Alexandra merge la poștă pentru a trimite un pachet lui Adam. Ea se duce la fereastră și întinde coletul angajatului. Angajatul ridică coletul și îi dă Alexandrei o chitanță. Adam nu trebuie să fie acasă când este trimis coletul. Alexandra este încrezătoare că pachetul îi va fi livrat lui Adam la un moment dat în viitor și poate continua să-și facă treaba. Mai târziu, la un moment dat, Adam primește un pachet.

Acesta este un exemplu de model de mesagerie punct la punct. Oficiul poștal de aici acționează ca un mecanism de distribuire a coletelor, asigurându-se că fiecare colet este livrat o singură dată. Utilizarea unui oficiu poștal separă acțiunea de a trimite un colet de livrarea coletului.
În sistemele clasice de mesagerie, modelul punct la punct este implementat prin cozi. Coada acționează ca un buffer FIFO (primul intrat, primul ieșit) la care se pot abona unul sau mai mulți consumatori. Fiecare mesaj este livrat numai unul dintre consumatorii abonati. Cozile de aşteptare încearcă de obicei să distribuie mesajele în mod corect între consumatori. Un singur consumator va primi acest mesaj.

Termenul „durabil” este aplicat cozilor. Încredere este o proprietate de serviciu care garantează că sistemul de mesagerie va păstra mesajele în absența abonaților activi până când consumatorul se abonează la coada de livrare a mesajelor.

Fiabilitatea este adesea confundată cu persistenţă și, deși cei doi termeni sunt interschimbabili, ei îndeplinesc funcții diferite. Persistența determină dacă un mesaj este scris de sistemul de mesagerie într-un fel de stocare între primirea lui și trimiterea acestuia către consumator. Mesajele trimise în coadă pot fi persistente sau nu.
Mesageria punct la punct este utilizată atunci când un caz de utilizare necesită o singură acțiune asupra unui mesaj. Exemplele includ depunerea de fonduri într-un cont sau îndeplinirea unei comenzi de livrare. Vom discuta mai târziu de ce un sistem de mesagerie în sine este incapabil să ofere o livrare unică și de ce cozile pot oferi, în cel mai bun caz, o garanție de livrare. cel puțin o dată.

Editor-Abonat

Gabriella formează numărul conferinței. În timp ce este conectată la conferință, aude tot ce spune vorbitorul, împreună cu restul participanților la apel. Când se stinge, e dor de ceea ce se spune. La reconectare, ea continuă să audă ce i se spune.

Acesta este un exemplu de model de mesagerie publica-aboneaza-te. Apelul conferință acționează ca un mecanism de difuzare. Persoanei care vorbește nu îi pasă câte persoane sunt în prezent la apel - sistemul asigură că oricine este conectat în prezent va auzi ceea ce se spune.
În sistemele clasice de mesagerie, modelul de mesagerie publish-subscribe este implementat prin vârfuri. Un subiect oferă aceeași metodă de difuzare ca și mecanismul de conferință. Când un mesaj este postat pe un subiect, acesta este distribuit pentru toți utilizatorii abonați.

Subiecte de obicei nesigur (nedurabil). Asemenea unui ascultător care nu aude ce se spune la un apel conferință, atunci când ascultătorul este offline, abonații subiectului pierd orice mesaj trimis în timp ce sunt offline. Din acest motiv, putem spune că blaturile oferă o garanție de livrare. nu mai mult de o dată pentru fiecare consumator.

Mesajele Publicare-Abonare sunt utilizate de obicei atunci când mesajele sunt de natură informațională și pierderea unui singur mesaj nu este deosebit de semnificativă. De exemplu, un subiect poate transmite citiri de temperatură de la un grup de senzori o dată pe secundă. Un sistem care este interesat de temperatura actuală și care se abonează la un subiect nu își va face griji dacă ratează un mesaj - în curând va sosi un altul.

modele hibride

Site-ul magazinului pune mesajele de comandă într-o „coadă de mesaje”. Principalul consumator al acestor mesaje este sistemul executiv. În plus, sistemul de audit trebuie să aibă copii ale acestor mesaje de comandă pentru urmărirea ulterioară. Ambele sisteme nu pot pierde mesaje, chiar dacă sistemele în sine sunt indisponibile de ceva timp. Site-ul web nu ar trebui să cunoască alte sisteme.

Cazurile de utilizare necesită adesea o combinație de modele de publicare-abonare și de mesagerie punct la punct, cum ar fi atunci când mai multe sisteme au nevoie de o copie a unui mesaj și sunt necesare atât fiabilitatea, cât și persistența pentru a preveni pierderea mesajului.

În aceste cazuri este necesară o destinație (termen general pentru cozi și subiecte), care distribuie mesajele practic ca un subiect, astfel încât fiecare mesaj să fie trimis către un sistem separat interesat de aceste mesaje, dar și în care fiecare sistem poate defini mai mulți consumatori. care primesc mesaje primite, ceea ce este mai mult ca o coadă. Tipul de citire în acest caz este − o dată pentru fiecare parte interesată. Aceste destinații hibride necesită adesea durabilitate, astfel încât, dacă un consumator se deconectează, mesajele care sunt trimise în acel moment sunt acceptate atunci când consumatorul se reconecta.

Modelele hibride nu sunt noi și pot fi aplicate la majoritatea sistemelor de mesagerie, inclusiv la ActiveMQ (prin destinații virtuale sau compuse care combină subiecte și cozi) și Kafka (implicit, ca proprietate fundamentală a designului destinației sale).

Acum că avem o terminologie de bază și o înțelegere a ceea ce ar putea fi util un sistem de mesagerie, să intrăm în detalii.

Traducerea facuta: tele.gg/middle_java

Următoarea parte tradusă: Capitolul 3. Kafka

Pentru a fi continuat ...

Sursa: www.habr.com

Adauga un comentariu