Sõnumivahendaja mõistmine. Sõnumite saatmise mehaanika õppimine ActiveMQ ja Kafka abil. 1. peatükk

Tere kõigile!

Hakkasin tõlkima väikest raamatut:
«Sõnumimaaklerite mõistmine"
autor: Jakub Korab, väljaandja: O'Reilly Media, Inc., avaldamise kuupäev: juuni 2017, ISBN: 9781492049296.

Raamatu sissejuhatusest:
"... See raamat õpetab teile, kuidas mõelda maakleri sõnumsidesüsteemidele, võrrelda ja vastandada kahte populaarset maakleritehnoloogiat: Apache ActiveMQ ja Apache Kafka. See kirjeldab kasutusjuhtumeid ja arendusstiimuleid, mis ajendasid nende arendajaid kasutama väga erinevaid lähenemisviise samale valdkonnale – süsteemidevahelisele sõnumivahetusele vahepealse maakleriga. Vaatleme neid tehnoloogiaid algusest peale ja tõstame esile erinevate disainivalikute mõju. Saate sügava arusaamise mõlemast tootest, mõistate, kuidas neid tuleks ja mitte kasutada, ning mõistate, mida otsida, kui kaalute tulevikus muid sõnumsidetehnoloogiaid. ... "

Seni tõlgitud osad:
Peatükk 1. Sissejuhatus
3. peatükk. Kafka

Postitan valminud peatükid tõlgituna.

1. PEATÜKK

Sissejuhatus

Süsteemidevaheline sõnumivahetus on IT üks kõige vähem mõistetavaid valdkondi. Arendaja või arhitektina võite olla väga tuttav erinevate raamistike ja andmebaasidega. Siiski on tõenäoline, et tunnete maakleripõhiste sõnumsidetehnoloogiate toimimist vaid mööduvalt. Kui tunnete end nii, ärge muretsege, olete heas seltskonnas.

Inimestel on tavaliselt väga piiratud kontakt sõnumside infrastruktuuriga. Sageli ühenduvad nad ammu loodud süsteemiga või laadivad Internetist distributsiooni alla, installivad selle PROM-i ja hakkavad sellele koodi kirjutama. Pärast infrastruktuuri käivitamist PROM-is võivad tulemused olla segased: sõnumid lähevad tõrgete tõttu kaduma, saatmine ei toimi ootuspäraselt või maaklerid “poovad üles” teie tootjad või ei saada sõnumeid teie tarbijatele.

Kõlab tuttavalt?

Levinud stsenaarium on see, et teie sõnumikood töötab praegu suurepäraselt. Kuni see lakkab töötamast. See periood uinutab valvuri valesse turvatunnesse, mis toob kaasa rohkem koodi, mis põhineb valedel veendumustel tehnoloogia põhikäitumise kohta. Kui asjad hakkavad valesti minema, seisate silmitsi ebamugava tõega: te ei ole tegelikult aru saanud toote käitumisest või autorite valitud kompromissidest, nagu toimivus versus usaldusväärsus või tehingulisus versus horisontaalne skaleeritavus. .

Ilma maaklerite tööpõhimõttest sügava arusaamata teevad inimesed oma sõnumisüsteemide kohta näiliselt mõistlikke avaldusi, näiteks:

  • Süsteem ei kaota kunagi sõnumeid
  • Sõnumeid töödeldakse järjestikku
  • Tarbijate lisamine muudab süsteemi kiiremaks
  • Sõnumid toimetatakse kohale ainult üks kord

Kahjuks põhinevad mõned neist väidetest eeldustel, mis kehtivad ainult teatud asjaoludel, teised aga on lihtsalt valed.

See raamat õpetab teile, kuidas mõelda maakleripõhistele sõnumsidesüsteemidele, võrrelda ja vastandada kahte populaarset maakleritehnoloogiat: Apache ActiveMQ ja Apache Kafka. See kirjeldab kasutusjuhtumeid ja arendusstiimuleid, mis ajendasid nende arendajaid kasutama väga erinevaid lähenemisviise samale valdkonnale – süsteemidevahelisele sõnumivahetusele vahepealse maakleriga. Vaatleme neid tehnoloogiaid algusest peale ja tõstame esile erinevate disainivalikute mõju. Saate sügava arusaamise mõlemast tootest, mõistate, kuidas neid tuleks ja mida mitte kasutada, ning mõistate, mida otsida, kui kaalute tulevikus muid sõnumsidetehnoloogiaid.

Enne alustamist tutvume põhitõdedega.

Mis on sõnumsidesüsteem ja miks seda vaja on?

Selleks, et kaks rakendust saaksid omavahel suhelda, peavad nad esmalt määratlema liidese. Selle liidese määratlemine hõlmab transpordi või protokolli (nt HTTP, MQTT või SMTP) valimist ja läbirääkimisi süsteemide vahel vahetatavate sõnumivormingute üle. See võib olla range protsess, näiteks XML-skeemi määratlemine koos sõnumite kasuliku koormuse kulunõuetega, või see võib olla palju vähem formaalne, näiteks kahe arendaja vaheline kokkulepe, et mõni HTTP-päringu osa sisaldab kliendi identifikaatorit .

Kuni sõnumite formaat ja nende saatmise järjekord on süsteemide vahel ühtsed, saavad nad omavahel suhelda, muretsemata teise süsteemi rakendamise pärast. Nende süsteemide sisemised omadused, näiteks kasutatav programmeerimiskeel või raamistik, võivad aja jooksul muutuda. Kuni lepingut ennast säilitatakse, võib suhtlus jätkuda ilma teise poole muutusteta. Need kaks süsteemi on selle liidesega tõhusalt lahti ühendatud (eraldatud).

Sõnumisüsteemid hõlmavad tavaliselt vahendajat kahe süsteemi vahel, mis suhtlevad saatja edasiseks lahtisidumiseks (eraldamiseks) adressaadist või adressaatidest. Sel juhul võimaldab sõnumite süsteem saatjal sõnumi saata, teadmata, kus adressaat on, kas ta on aktiivne või mitu eksemplari on.

Vaatame paari analoogiat selliste probleemide kohta, mida sõnumsidesüsteem lahendab, ja tutvustame mõningaid põhitermineid.

Punktist punktini

Alexandra läheb postkontorisse Adamile pakki saatma. Ta läheb akna juurde ja ulatab töötajale paki. Töötaja tuleb pakile järele ja annab Alexandrale kviitungi. Adam ei pea paki saatmise ajal kodus olema. Alexandra on kindel, et pakk toimetatakse kunagi tulevikus Adamile ja saab jätkata oma äri. Hiljem saab Adam mingil hetkel paki.

See on näide sõnumivahetuse mudelist punktist punktini. Siinne postkontor toimib pakkide jaotusmehhanismina, tagades iga paki ühekordse kättetoimetamise. Postkontori kasutamine eraldab paki saatmise toimingu paki kättetoimetamisest.
Klassikalistes sõnumisüsteemides rakendatakse punktist punkti mudelit läbi järjekorrad. Järjekord toimib FIFO (first in, first out) puhvrina, mida saab tellida üks või mitu tarbijat. Iga sõnum saadetakse ainult kohale ühele tellitud tarbijale. Järjekorrad püüavad tavaliselt sõnumeid tarbijate vahel õiglaselt jaotada. Selle teate saab ainult üks tarbija.

Järjekordade puhul kasutatakse mõistet "vastupidamine". Usaldusväärsus on teenuse atribuut, mis tagab, et sõnumsidesüsteem säilitab aktiivsete abonentide puudumisel sõnumeid seni, kuni tarbija tellib sõnumite edastamise järjekorra.

Tihti aetakse segi usaldusväärsust püsivus ja kuigi neid kahte terminit kasutatakse vaheldumisi, täidavad nad erinevaid funktsioone. Püsivus määrab, kas sõnumsidesüsteem kirjutab sõnumi vastuvõtmise ja tarbijale saatmise vahel mingisse salvestusruumi. Järjekorda saadetud sõnumid võivad, kuid ei pruugi olla püsivad.
Punkt-punkti sõnumivahetust kasutatakse juhul, kui kasutusjuhtum nõuab sõnumiga ühekordset toimingut. Näited hõlmavad raha deponeerimist kontole või tarnetellimuse täitmist. Arutame hiljem, miks sõnumsidesüsteem üksi ei suuda pakkuda ühekordset kohaletoimetamist ja miks järjekorrad võivad parimal juhul pakkuda kohaletoimetamise garantiid vähemalt korra.

Kirjastaja-tellija

Gabriella valib konverentsi numbri. Konverentsiga ühenduses olles kuuleb ta koos ülejäänud kõnes osalejatega kõike, mida kõneleja ütleb. Kui ta häälestub, jätab ta öeldust puudust. Taasühendamisel kuuleb ta jätkuvalt, mida räägitakse.

See on näide sõnumivahetuse mudelist avalda-telli. Konverentskõne toimib edastusmehhanismina. Kõnelejat ei huvita, kui palju inimesi parasjagu kõnes on – süsteem tagab, et kõik hetkel ühenduses olevad inimesed kuulevad, mida räägitakse.
Klassikalistes sõnumsidesüsteemides rakendatakse avaldamise-tellimise sõnumside mudelit pealsed. Teema pakub sama edastusmeetodit kui konverentsimehhanism. Kui teemasse saadetakse sõnum, siis see levitatakse kõigile tellitud kasutajatele.

Teemad on tavaliselt ebausaldusväärne (mittekestev). Sarnaselt kuulajaga, kes ei kuule konverentskõnes öeldut, kui kuulaja ühenduse katkestab, jätavad teema tellijad märkamata kõik võrguühenduseta saadetud sõnumid. Sel põhjusel võime öelda, et teemad annavad kohaletoimetamise garantii mitte rohkem kui üks kord iga tarbija jaoks.

Avaldamise ja tellimise sõnumeid kasutatakse tavaliselt siis, kui sõnumid on olemuselt informatiivsed ja ühe sõnumi kadumine pole eriti oluline. Näiteks võib teema edastada andurite rühma temperatuurinäidud kord sekundis. Süsteem, mis tunneb huvi hetketemperatuuri vastu ja mis tellib mõne teema, ei muretse, kui tal mõni teade vahele jääb – lähiajal tuleb teine.

hübriidmudelid

Poe veebisait asetab tellimuse sõnumid "sõnumite järjekorda". Nende sõnumite peamine tarbija on täitevsüsteem. Lisaks peaks auditisüsteemil olema nende tellimuste teadete koopiad hilisemaks jälgimiseks. Mõlemad süsteemid ei saa lubada sõnumeid läbida, isegi kui süsteemid ise pole mõnda aega saadaval. Veebisait ei tohiks olla teadlik muudest süsteemidest.

Kasutusjuhtumid nõuavad sageli avaldamise-tellimise ja punkt-punkti sõnumside mudelite kombinatsiooni, näiteks kui mitu süsteemi nõuavad sõnumi koopiat ning sõnumi kadumise vältimiseks on vaja nii usaldusväärsust kui ka püsivust.

Nendel juhtudel on vaja sihtkohta (üldmõiste järjekordade ja teemade jaoks), mis levitab sõnumeid põhimõtteliselt teemana, nii et iga sõnum saadetakse eraldi süsteemi, mis on nendest sõnumitest huvitatud, kuid kus iga süsteem saab määrata mitu tarbijat, kes saavad sissetulevaid sõnumeid. sõnumeid, mis on rohkem nagu järjekord. Lugemise tüüp on antud juhul üks kord iga sidusrühma jaoks. Need hübriidsihtkohad nõuavad sageli vastupidavust, nii et kui tarbija läheb võrgust välja, võetakse sel ajal saadetud sõnumid vastu pärast tarbija taasühendamist.

Hübriidmudelid pole uued ja neid saab kasutada enamikus sõnumsidesüsteemides, sealhulgas nii ActiveMQ-s (virtuaalsete või liitsihtkohtade kaudu, mis ühendavad teemad ja järjekorrad) kui ka Kafkas (kaudselt selle sihtkoha disaini põhiomadusena).

Nüüd, kui meil on olemas põhiterminoloogia ja arusaam sellest, milleks võiksime sõnumsidesüsteemi kasutada, asume üksikasjadesse.

Tõlge tehtud: tele.gg/middle_java

Järgmine tõlgitud osa: 3. peatükk. Kafka

Jätkub ...

Allikas: www.habr.com

Lisa kommentaar