Salut tuturor!
Am început traducerea unei cărți mici:
««,
autor: Jakub Korab, editura: O’Reilly Media, Inc., data publicării: iunie 2017, ISBN: 9781492049296.
Din introducerea cărții:
«… Această carte vă va învăța să gândiți despre sistemele de schimb de mesaje prin compararea și contrastarea a două tehnologii populare de mediere: Apache ActiveMQ și Apache Kafka. Vor fi prezentate exemple de utilizare și motivele dezvoltării care au condus la faptul că dezvoltatorii lor au adoptat abordări complet diferite în aceeași arie - schimbul de mesaje între sisteme cu un broker intermediar. Vom explora aceste tehnologii de la zero și vom evidenția influența diferitelor opțiuni de design pe parcurs. Veți obține o înțelegere profundă a ambelor produse, cunoașterea modului în care ar trebui și nu ar trebui utilizate, precum și înțelegerea a ceea ce trebuie să aveți în vedere când analizați alte tehnologii de schimb de mesaje în viitor. …»
Părțile traduse până în prezent:
Voi publica capitolele finalizate pe măsură ce le traduc.
CAPITOLUL 1
Introducere
Schimbul de mesaje între sisteme este una dintre cele mai puțin înțelese domenii din IT. Ca dezvoltator sau arhitect, este posibil să fiți familiarizat cu diverse cadre și baze de date. Cu toate acestea, este foarte probabil să aveți doar o cunoaștere superficială a modului în care funcționează tehnologiile de schimb de mesaje bazate pe broker. Dacă așa vă simțiți, nu vă faceți griji, sunteți într-o companie bună.
Oamenii interacționează de obicei cu infrastructura de schimb de mesaje într-un mod foarte limitat. Adesea, se conectează la un sistem creat cu mult timp în urmă sau descarcă un pachet de pe internet, îl instalează în PROCE și încep să scrie cod pentru acesta. După ce infrastructura a fost lansată în PROCE, rezultatele pot fi ambigue: pierderi de mesaje în caz de eșecuri, livrările nu funcționează așa cum ați așteptat sau brokerii „blochează” producătorii dvs. sau nu trimit mesaje consumatorilor dvs.
Pare cunoscut?
Un scenariu comun este că codul dvs. de mesagerie funcționează excelent, până în momentul în care se oprește. Această perioadă vă face să pierdeți vigilența și vă oferă un fals sentiment de siguranță, ceea ce duce la un cod și mai mare bazat pe false impresii despre comportamentul fundamental al tehnologiei. Când ceva începe să meargă prost, vă confruntați cu o adevărată realitate incomodă: că, de fapt, nu ați înțeles comportamentul de bază al produsului sau compromisurile făcute de dezvoltatori, cum ar fi performanța vs. fiabilitatea sau tranzacționalitatea vs. scalabilitatea orizontală.
Fără o înțelegere profundă a modului în care funcționează brokerii, oamenii fac afirmații care par raționale despre sistemele lor de mesagerie, cum ar fi:
- Sistemul nu va pierde niciodată mesaje
- Mesajele vor fi procesate în mod secvențial
- Adăugarea consumatorilor 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 sunt valabile doar în anumite circumstanțe, în timp ce altele sunt pur și simplu false.
Această carte vă va învăța să gândiți critic despre sistemele de mesagerie bazate pe brokeri, comparând și contrastând două tehnologii populare de brokeri: Apache ActiveMQ și Apache Kafka. Vor fi prezentate exemple de utilizare și stimulente de dezvoltare, care au dus dezvoltatorii lor să adopte abordări complet diferite în același domeniu — mesageria între sisteme cu un broker intermediar. Vom explora aceste tehnologii de la zero și vom evidenția impactul diferitelor opțiuni de design pe parcurs. Veți obține o înțelegere profundă a ambelor produse, o conștientizare a modului în care ar trebui și nu ar trebui utilizate, și o claritate asupra aspectelor pe care ar trebui să le luați în considerare atunci când analizați alte tehnologii de mesagerie în viitor.
Înainte de a începe, să trecem prin noțiunile de bază.
Ce este un sistem de mesagerie și de ce este necesar
Pentru ca două aplicații să poată comunica între ele, mai întâi trebuie să definească interfața. Definirea acestei interfețe include alegerea transportului sau protocolului, cum ar fi HTTP, MQTT sau SMTP și acordul asupra formatelor mesajelor care vor fi schimbate între sisteme. Acest proces poate fi strict, cum ar fi definirea unei scheme XML cu cerințe pentru sarcina utilă (payload) a mesajului, sau poate fi mult mai puțin formal, de exemplu, un acord între doi dezvoltatori că o anumită parte a cererii HTTP va conține un identificator al clientului.
Atâta timp cât formatul mesajelor și ordinea în care sunt trimise între sisteme sunt convenite, ele vor putea interacționa între ele, fără a se îngrijora de implementarea celeilalte sisteme. Interiorul acestor sisteme, cum ar fi limbajul de programare sau cadrul utilizat, poate să se schimbe în timp. Atâta timp cât contractul însuși este menținut, interacțiunea poate continua fără modificări din partea cealaltă. Aceste două sisteme sunt eficient decuplate (separate) prin această interfață.
Sistemele de mesagerie prevăd, de obicei, implicarea unui intermediar între cele două sisteme care interacționează, pentru a separa expeditorul de destinatari. În acest fel, sistemul de mesagerie permite expeditorului să trimită un mesaj, fără a ști unde se află destinatarul, dacă acesta este activ sau câte instanțe există.
Să analizăm câteva analogii ale problemelor tipice pe care le rezolvă un sistem de mesagerie și să introducem câțiva termeni de bază.
Punct pe punct
Alexandra merge la oficiul poștal pentru a trimite un pachet lui Adam. Se apropie de fereastră și înmânează pachetul angajatului. Angajatul ia pachetul și îi oferă Alexandrei o chitanță. Adam nu trebuie să fie acasă în momentul expediției pachetului. Alexandra este sigură că pachetul va fi livrat lui Adam la un moment dat în viitor și poate continua cu activitățile sale. Mai târziu, Adam primește pachetul.
Acesta este un exemplu de model de mesagerie punct-pe-punct. Oficiul poștal acționează aici ca un mecanism de distribuire a pachetelor, garantând că fiecare pachet va fi livrat o singură dată. Utilizarea oficiului poștal separă actul de expediere a pachetului de livrarea acestuia.
În sistemele tradiționale de mesagerie, modelul "punct-la-punct" este implementat prin de prioritate. Coada funcționează ca un buffer FIFO (primul intrat, primul ieșit), la care se poate abona un sau mai mulți consumatori. Fiecare mesaj este livrat doar unui singur consumator abonat. Cozile încearcă în mod obișnuit să distribuie mesajele în mod echitabil între consumatori. Numai un consumator va primi acest mesaj.
La cozi se aplică termenul "fiabile" ("durable"). Fiabilitate — acesta este un atribut al serviciului care garantează că sistemul de mesagerie va păstra mesajele în absența abonaților activi, până când un consumator se abonează la coadă pentru livrarea mesajelor.
Fiabilitatea este adesea confundată cu persistența și, deși acești doi termeni sunt interschimbabili, ei îndeplinesc funcții diferite. Persistența determină dacă sistemul de mesagerie stochează un mesaj într-un anumit tip de depozit între primirea acestuia și livrarea către consumator. Mesajele trimise într-o coadă pot fi sau nu persistente.
Mesajele de tip "punct-la-punct" sunt utilizate atunci când cazul de utilizare necesită o acțiune unică asupra mesajului. De exemplu, se poate menționa adăugarea de fonduri într-un cont sau plasarea unei comenzi de livrare. Vom discuta mai târziu de ce sistemul de mesagerie în sine nu poate garanta livrarea unică și de ce cozile pot asigura în cel mai bun caz o garanție de livrare cel puțin o dată.
Publicare-Abonare
Gabriela formează numărul conferinței. Atunci când este conectată la conferință, ea aude tot ce spune vorbitorul, împreună cu ceilalți participanți la apel. Când se deconectează, pierde ceea ce s-a spus. La reconectare, continuă să audă ce se spune.
Acesta este un exemplu de model de mesagerie publicare-abonare. Conferința acționează ca un mecanism de difuzare. Vorbitorul nu se îngrijorează câți oameni sunt acum conectați la apel — sistemul garantează că oricine se conectează în acel moment va auzi ceea ce se spune.
În sistemele tradiționale de mesagerie, modelul de schimb de mesaje "publicare-abonare" este implementat prin topiciTopicul oferă un mod de difuzare similar cu cel al mecanismului de conferință. Atunci când un mesaj este trimis în topic, acesta este distribuit tuturor utilizatorilor abonați..
Topicurile sunt de obicei nefiabile (nondurable).La fel ca un ascultător care nu aude ceea ce se spune într-un apel de conferință atunci când se deconectează, abonații la topic ratează orice mesaj trimis în timpul în care sunt offline. Din acest motiv, se poate spune că topicurile oferă o garanție de livrare de cel mult o dată pentru fiecare consumator.
Mesajele de tip „publicare-abonare” sunt de obicei folosite atunci când mesajele au un caracter informativ, iar pierderea unui singur mesaj nu este foarte semnificativă. De exemplu, un topic poate transmite citirile de temperatură de la un grup de senzori o dată pe secundă. Sistemul care este interesat de temperatura actuală și care se abonează la topic, nu va fi îngrijorat dacă ratează un mesaj — altul va veni în curând.
Modele hibride
Site-ul magazinului plasează mesajele despre comenzi î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 despre comenzi pentru urmărirea ulterioară. Ambele sisteme nu pot rata mesaje, chiar dacă sistemele în sine sunt indisponibile pentru o anumită perioadă de timp. Site-ul nu trebuie să știe despre celelalte sisteme.
Scenariile de utilizare necesită adesea combinarea modelelor de schimb de mesaje „publicare-abonare” și „punct-la-punct”, de exemplu, când mai multor sisteme le este necesară o copie a mesajului și pentru a preveni pierderea mesajelor este necesară atât fiabilitatea, cât și persistența.
În aceste cazuri, este necesar un destinatar (destination) (termen general pentru cozi și topicuri), care distribuie mesajele în principal ca un topic, astfel încât fiecare mesaj să fie trimis într-un sistem separat interesat de aceste mesaje, dar și fiecare sistem poate avea mai mulți consumatori care primesc mesajele în intrare, ceea ce seamănă mai mult cu o coadă. Tipul de citire în acest caz este o dată pentru fiecare parte interesată.Aceste destinații hibride necesită adesea fiabilitate (durabilitate), așa că, dacă consumatorul se deconectează, mesajele trimise în acel moment sunt acceptate după reconectarea consumatorului.
Modelele hibride nu sunt noi și pot fi aplicate în majoritatea sistemelor de schimb de mesaje, inclusiv atât ActiveMQ (prin adrese virtuale sau compuse, care combină subiecte și cozi), cât și Kafka (implicit, ca o proprietate fundamentală a designului adresei sale).
Acum că avem o terminologie de bază și o înțelegere a scopului pentru care ne-ar putea fi util un sistem de schimb de mesaje, să trecem la detalii.
Traducerea a fost realizată:
Partea următoare tradusă:
Continuarea urmează...
Sursa: habr.com
