ProHoster > Blogs > Administrācija > Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 1. nodaļa

Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 1. nodaļa

Sveiki visiem!

Es sāku tulkot mazu grāmatu:
Ā«Izpratne par ziņojumu brokeriem",
autors: Jakubs Korabs, izdevējs: O'Reilly Media, Inc., publicÄ“Å”anas datums: 2017. gada jÅ«nijs, ISBN: 9781492049296.

No grāmatas ievada:
"... Å Ä« grāmata iemācÄ«s jums domāt par brokeru ziņojumapmaiņas sistēmām, salÄ«dzinot divas populāras brokeru tehnoloÄ£ijas: Apache ActiveMQ un Apache Kafka. Tajā tiks izklāstÄ«ti lietoÅ”anas gadÄ«jumi un izstrādes stimuli, kas lika izstrādātājiem izmantot ļoti dažādas pieejas vienai un tai paÅ”ai jomai ā€” ziņojumapmaiņai starp sistēmām ar starpposma starpnieku. Mēs aplÅ«kosim Ŕīs tehnoloÄ£ijas no paÅ”a sākuma un uzsvērsim dažādu dizaina izvēļu ietekmi. JÅ«s iegÅ«sit dziļu izpratni par abiem produktiem, izpratni par to, kā tos vajadzētu un nevajadzētu lietot, un sapratni par to, kas jāņem vērā, apsverot citas ziņojumapmaiņas tehnoloÄ£ijas nākotnē. ... "

Līdz Ŕim tulkotās daļas:
1. nodaļa. Ievads
3. nodaļa. Kafka

Pabeigtās nodaļas ievietoŔu, tiklīdz tās ir tulkotas.

1. NODAĻA

Ievads

Ziņojumapmaiņa no sistēmas uz sistēmu ir viena no vismazāk saprotamajām IT jomām. Kā izstrādātājs vai arhitekts jÅ«s, iespējams, ļoti labi pārzināt dažādas sistēmas un datu bāzes. Tomēr ir iespējams, ka jÅ«s tikai Ä«slaicÄ«gi zināt, kā darbojas uz brokeriem balstÄ«tas ziņojumapmaiņas tehnoloÄ£ijas. Ja jÅ«taties Ŕādi, neuztraucieties, jÅ«s esat labā kompānijā.

Cilvēkiem parasti ir ļoti ierobežots kontakts ar ziņojumapmaiņas infrastruktÅ«ru. Viņi bieži pieslēdzas sistēmai, kas izveidota jau sen, vai lejupielādē no interneta izplatÄ«Å”anu, instalē to PROM un sāk rakstÄ«t tai kodu. Pēc infrastruktÅ«ras palaiÅ”anas PROM, rezultāti var bÅ«t dažādi: ziņojumi tiek pazaudēti kļūmju dēļ, sÅ«tÄ«Å”ana nedarbojas, kā jÅ«s gaidÄ«jāt, vai arÄ« brokeri ā€œapčakarēā€ jÅ«su ražotājus vai nenosÅ«ta ziņojumus jÅ«su patērētājiem.

Izklausās pazīstami?

IzplatÄ«ts scenārijs ir tāds, ka jÅ«su ziņojumapmaiņas kods pagaidām darbojas lieliski. LÄ«dz pārstāj darboties. Å is periods iemidzina sargu maldÄ«gā droŔības sajÅ«tā, radot vairāk koda, kas balstās uz maldÄ«giem uzskatiem par tehnoloÄ£ijas pamatuzvedÄ«bu. Kad lietas sāk iet greizi, jÅ«s saskaraties ar neērtu patiesÄ«bu: ka neesat Ä«sti sapratis produkta uzvedÄ«bu vai autoru izvēlētos kompromisus, piemēram, veiktspēju pret uzticamÄ«bu vai darÄ«jumu spēju pret horizontālo mērogojamÄ«bu. .

Bez dziļas izpratnes par to, kā darbojas brokeri, cilvēki sniedz Ŕķietami pamatotus paziņojumus par savām ziņojumapmaiņas sistēmām, piemēram:

  • Sistēma nekad nezaudēs ziņojumus
  • Ziņojumi tiks apstrādāti secÄ«gi
  • Patērētāju pievienoÅ”ana padarÄ«s sistēmu ātrāku
  • Ziņojumi tiks piegādāti tikai vienu reizi

Diemžēl daži no Å”iem apgalvojumiem ir balstÄ«ti uz pieņēmumiem, kas ir spēkā tikai noteiktos apstākļos, bet citi ir vienkārÅ”i nepareizi.

Å Ä« grāmata iemācÄ«s domāt par uz brokeriem balstÄ«tām ziņojumapmaiņas sistēmām, salÄ«dzinot divas populāras brokeru tehnoloÄ£ijas: Apache ActiveMQ un Apache Kafka. Tajā tiks izklāstÄ«ti lietoÅ”anas gadÄ«jumi un izstrādes stimuli, kas lika izstrādātājiem izmantot ļoti dažādas pieejas vienai un tai paÅ”ai jomai ā€” ziņojumapmaiņai starp sistēmām ar starpposma starpnieku. Mēs aplÅ«kosim Ŕīs tehnoloÄ£ijas no paÅ”a sākuma un uzsvērsim dažādu dizaina izvēļu ietekmi. JÅ«s iegÅ«sit dziļu izpratni par abiem produktiem, izpratni par to, kā tos vajadzētu un nevajadzētu lietot, un sapratni par to, kas jāņem vērā, apsverot citas ziņojumapmaiņas tehnoloÄ£ijas nākotnē.

Pirms sākam, apskatīsim pamatus.

Kas ir ziņojumapmaiņas sistēma un kāpēc tā ir nepiecieÅ”ama?

Lai divas lietojumprogrammas varētu sazināties viena ar otru, tām vispirms ir jādefinē saskarne. Å Ä«s saskarnes definÄ“Å”ana ietver transporta vai protokola, piemēram, HTTP, MQTT vai SMTP, atlasi un pārrunas par ziņojumu formātiem, ar kuriem tiks apmaiņa starp sistēmām. Tas var bÅ«t stingrs process, piemēram, XML shēmas noteikÅ”ana ar ziņojuma slodzes izmaksu prasÄ«bām, vai arÄ« tas var bÅ«t daudz mazāk formāls, piemēram, vienoÅ”anās starp diviem izstrādātājiem, ka kāda HTTP pieprasÄ«juma daļa ietvers klienta identifikatoru .

Kamēr ziņojumu formāts un to nosÅ«tÄ«Å”anas secÄ«ba ir konsekventa starp sistēmām, tās var sazināties savā starpā, neuztraucoties par otras sistēmas ievieÅ”anu. Å o sistēmu iekŔējās Ä«paŔības, piemēram, izmantotā programmÄ“Å”anas valoda vai ietvars, laika gaitā var mainÄ«ties. Kamēr tiek uzturēts pats lÄ«gums, mijiedarbÄ«ba var turpināties bez izmaiņām no otras puses. Abas sistēmas ir efektÄ«vi atsaistÄ«tas (atdalÄ«tas) ar Å”o saskarni.

Ziņojumapmaiņas sistēmas parasti ietver starpnieku starp divām sistēmām, kas mijiedarbojas, lai vēl vairāk atdalÄ«tu (atdalÄ«tu) sÅ«tÄ«tāju no adresāta vai adresātiem. Å ajā gadÄ«jumā ziņojumapmaiņas sistēma ļauj sÅ«tÄ«tājam nosÅ«tÄ«t ziņojumu, nezinot, kur atrodas adresāts, vai viņŔ ir aktÄ«vs un cik gadÄ«jumu ir.

Apskatīsim dažas analoģijas par problēmām, kuras risina ziņojumapmaiņas sistēma, un ieviesīsim dažus pamatterminus.

Punkts-punkts

Aleksandra dodas uz pastu, lai nosūtītu Ādamam paku. Viņa pieiet pie loga un pasniedz darbiniekam paku. Darbinieks paņem paku un iedod Aleksandrai čeku. Ādamam nav jābūt mājās, kad paciņa tiek nosūtīta. Aleksandra ir pārliecināta, ka paka Ādamam tiks piegādāta kādā brīdī nākotnē, un viņa varēs turpināt savu biznesu. Vēlāk kādā brīdī Ādams saņem paku.

Å is ir ziņojumapmaiņas modeļa piemērs punkts uz punktu. Pasta nodaļa Å”eit darbojas kā paku sadales mehānisms, nodroÅ”inot katras pakas piegādi vienu reizi. Izmantojot pasta nodaļu, pakas nosÅ«tÄ«Å”ana tiek atdalÄ«ta no pakas piegādes.
Klasiskajās ziņojumapmaiņas sistēmās no punkta uz punktu modelis tiek ieviests caur rindas. Rinda darbojas kā FIFO (first in, first out) buferis, kuru var abonēt viens vai vairāki patērētāji. Katrs ziņojums tiek piegādāts tikai kādam no abonētajiem patērētājiem. Rindas parasti mēģina godīgi izplatīt ziņojumus starp patērētājiem. Šo ziņojumu saņems tikai viens patērētājs.

Termins ā€œizturÄ«gsā€ tiek attiecināts uz rindām. UzticamÄ«ba ir pakalpojuma rekvizÄ«ts, kas nodroÅ”ina, ka ziņojumapmaiņas sistēma saglabās ziņojumus, ja nav aktÄ«vu abonentu, lÄ«dz patērētājs abonē ziņojumu piegādes rindu.

UzticamÄ«ba bieži tiek sajaukta ar neatlaidÄ«ba un, lai gan abi termini tiek lietoti kā sinonÄ«mi, tie pilda dažādas funkcijas. NoturÄ«ba nosaka, vai ziņojumapmaiņas sistēma ieraksta ziņojumu uz kāda veida krātuvi starp tā saņemÅ”anu un nosÅ«tÄ«Å”anu patērētājam. Ziņojumi, kas nosÅ«tÄ«ti uz rindu, var bÅ«t un var nebÅ«t pastāvÄ«gi.
TieÅ”a ziņojumapmaiņa tiek izmantota, ja lietoÅ”anas gadÄ«jumā ir nepiecieÅ”ama vienreizēja darbÄ«ba ar ziņojumu. Piemēri: lÄ«dzekļu iemaksa kontā vai piegādes pasÅ«tÄ«juma aizpildÄ«Å”ana. Mēs apspriedÄ«sim vēlāk, kāpēc ziņojumapmaiņas sistēma pati par sevi nespēj nodroÅ”ināt vienreizēju piegādi un kāpēc rindas labākajā gadÄ«jumā var nodroÅ”ināt piegādes garantiju vismaz vienreiz.

Izdevējs-abonents

Gabriella sastāda konferences numuru. Kamēr viņa ir savienota ar konferenci, viņa dzird visu, ko runā runātājs, kā arī pārējie sarunas dalībnieki. Kad viņa noskaņojas, viņa palaiž garām teikto. Atjaunojot savienojumu, viņa turpina dzirdēt, kas tiek teikts.

Å is ir ziņojumapmaiņas modeļa piemērs publicēt-abonēt. Konferences zvani darbojas kā apraides mehānisms. Personai, kas runā, ir vienalga, cik cilvēku paÅ”laik piedalās sarunā ā€“ sistēma nodroÅ”ina, ka ikviens, kas paÅ”laik ir savienots, dzirdēs teikto.
Klasiskajās ziņojumapmaiņas sistēmās publicÄ“Å”anas un abonÄ“Å”anas ziņojumapmaiņas modelis tiek ieviests, izmantojot topi. Topic nodroÅ”ina tādu paÅ”u apraides metodi kā konferenču mehānisms. Kad ziņa tiek nosÅ«tÄ«ta uz tēmu, tā tiek izplatÄ«ta visiem abonētajiem lietotājiem.

Tēmas parasti ir neuzticams (neizturÄ«gs). Tāpat kā klausÄ«tājs, kurÅ” nedzird, kas tiek teikts konferences zvanā, kad klausÄ«tājs atvienojas, tēmas abonenti nepalaiž garām visus ziņojumus, kas tiek nosÅ«tÄ«ti, atrodoties bezsaistē. Å Ä« iemesla dēļ mēs varam teikt, ka tēmas nodroÅ”ina piegādes garantiju ne vairāk kā vienu reizi katram patērētājam.

PublicÄ“Å”anas un abonÄ“Å”anas ziņojumapmaiņa parasti tiek izmantota, ja ziņojumiem ir informatÄ«vs raksturs un viena ziņojuma zudums nav Ä«paÅ”i nozÄ«mÄ«gs. Piemēram, tēma var pārraidÄ«t temperatÅ«ras rādÄ«jumus no sensoru grupas vienu reizi sekundē. Sistēma, kuru interesē Ŕī brīža temperatÅ«ra un kas abonē kādu tēmu, neuztraucas, ja palaidÄ«s garām ziņu ā€“ tuvākajā laikā pienāks cita.

hibrīda modeļi

Veikala vietne ievieto pasÅ«tÄ«juma ziņojumus "ziņojumu rindā". Galvenais Å”o ziņojumu patērētājs ir izpildsistēma. Turklāt audita sistēmai ir jābÅ«t Å”o pasÅ«tÄ«juma ziņojumu kopijām turpmākai izsekoÅ”anas veikÅ”anai. Abas sistēmas nevar ļaut ziņojumiem iziet cauri, pat ja paÅ”as sistēmas kādu laiku nav pieejamas. Vietnei nevajadzētu bÅ«t informētai par citām sistēmām.

LietoÅ”anas gadÄ«jumos bieži ir nepiecieÅ”ama publicÄ“Å”anas-abonÄ“Å”anas un tieŔās ziņojumapmaiņas modeļu kombinācija, piemēram, ja vairākām sistēmām ir nepiecieÅ”ama ziņojuma kopija un, lai novērstu ziņojuma zudumu, ir nepiecieÅ”ama gan uzticamÄ«ba, gan noturÄ«ba.

Å ajos gadÄ«jumos ir nepiecieÅ”ams galamērÄ·is (vispārējs termins rindām un tēmām), kas izplata ziņojumus bÅ«tÄ«bā kā tēmu, lai katrs ziņojums tiktu nosÅ«tÄ«ts uz atseviŔķu sistēmu, kas interesējas par Å”iem ziņojumiem, bet arÄ« kurā katra sistēma var definēt vairākus patērētājus, kuri saņem ienākoÅ”os ziņojumus. ziņas, kas vairāk atgādina rindu. LasÄ«Å”anas veids Å”ajā gadÄ«jumā ir vienu reizi katrai ieinteresētajai pusei. Å iem hibrÄ«dajiem galamērÄ·iem bieži ir nepiecieÅ”ama izturÄ«ba, lai, ja patērētājs pāriet bezsaistē, tajā laikā nosÅ«tÄ«tie ziņojumi tiktu saņemti pēc tam, kad patērētājs ir atkārtoti izveidojis savienojumu.

HibrÄ«die modeļi nav jauni, un tos var izmantot lielākajā daļā ziņojumapmaiņas sistēmu, tostarp gan ActiveMQ (izmantojot virtuālos vai saliktos galamērÄ·us, kas apvieno tēmas un rindas), gan Kafka (netieÅ”i kā galamērÄ·a dizaina pamatÄ«paŔību).

Tagad, kad mums ir zināma pamata terminoloģija un izpratne par to, kam mēs varētu izmantot ziņojumapmaiņas sistēmu, pievērsīsimies detaļām.

Tulkojums veikts: tele.gg/middle_java

Šī tulkotā daļa: 3. nodaļa. Kafka

Lai varētu turpināt ...

Avots: www.habr.com

Pievieno komentāru