Tere kõigile!
Alustasin väikese raamatu tõlkimist:
««,
autor: Jakub Korab, väljaandja: O’Reilly Media, Inc., väljaandmise kuupäev: juuni 2017, ISBN: 9781492049296.
Raamatu sissejuhatusest:
«… See raamat õpetab teid mõtlema sõnumite vahetamise süsteemide üle, võrreldes ja vastandades kahte populaarset vahenditehnoloogiat: Apache ActiveMQ-d ja Apache Kafka-d. Siin esitame kasutusnäiteid ja arendusstiimule, mis viisid selleni, et nende arendajad kasutasid sama valdkonna — sõnumite vahetamine süsteemide vahel vahebrokero kaudu — jaoks täiesti erinevaid lähenemisviise. Uurime neid tehnoloogiaid nullist ja rõhutame erinevate disainivalikute mõju sellel teel. Saate põhjaliku arusaama mõlemast tootest, teadlikkuse sellest, kuidas neid tuleks ja ei tohiks kasutada, ja arusaamise, millele tuleks tähelepanu pöörata teiste sõnumite vahetamise tehnoloogiate kaalumisel tulevikus. …»
Kuni praeguseni tõlgitud osad:
Avaldan lõpetatud peatükke tõlke edenemise järgi.
PEATÜKK 1
Sissejuhatus
Süsteemidevaheline sõnumivahetus on üks vähem mõistetud IT-valdkondi. Arendajana või arhitektina võite olla tuttav erinevate raamistike ja andmebaasidega. Siiski on tõenäoline, et olete ainult pindmisesse kokku puutunud sõnumivahetustehnoloogiatega, mis põhinevad vahendajal. Kui te tunnete end nii, siis ärge muretsege, te pole üksi.
Inimesed puutuvad näiteks sõnumivahetuse infrastruktuuriga kokku väga piiratud ulatuses. Tihti liituvad nad süsteemiga, mis on kunagi ammu loodud, või laadivad internetist alla paketi, installivad selle PROMsse ja hakkavad selle jaoks koodi kirjutama. Kui infrastruktuur PROMs üles seada, võivad tulemused olla kaheldavad: sõnumite kadumine süsteemihäirete korral, saatmine ei toimi oodatud viisil või vahendajad „hanguvad” teie tootjatega või ei edasta sõnumeid teie tarbijatele.
Kas kõlab tuttavalt?
Levinud stsenaarium, kus teie sõnumside kood töötab suurepäraselt, kuni hetkeni, mil see enam ei toimi. See periood uinutab valvsuse ja loob vale turvatunde, mis toob kaasa veelgi suurema koodi, mis põhineb vale ettekujutustel tehnoloogia alusloogikast. Kui asjad hakkavad minema valesti, seisate silmitsi ebamugava tõega: te ei mõista tegelikult toote põhikäitumist või autorite valitud kompromisse, näiteks jõudluse ja usaldusväärsuse vahel või transaktsioonide ja horisontaalse skaleeritavuse vahel.
Ilma sügava arusaamiseta sellest, kuidas maaklerid töötavad, teevad inimesed näiliselt mõistlikke väiteid nende sõnumitehnoloogia kohta, näiteks:
- Süsteem ei kaota kunagi sõnumeid
- Sõnumeid töödeldakse järjestikku
- Tarbijate lisamine teeb süsteemi kiiremaks
- Sõnumid toimetatakse ainult üks kord
Kahjuks põhinevad mõned neist väidetest eeldustel, mis kehtivad ainult teatud olukordades, samas kui teised on lihtsalt valed.
See raamat õpetab teid mõtlema sõnumivahetussüsteemide üle, mis põhinevad vahendajatel, võrreldes ja vastandades kahte populaarset vahendi tehnoloogiat: Apache ActiveMQ ja Apache Kafka. Siin tutvustatakse kasutusnäiteid ja arendusstiimuleid, mis on viinud selleni, et nende arendajad on kasutanud täiesti erinevaid lähenemisviise samale valdkonnale — sõnumite edastamisele süsteemide vahel vahendaja kaudu. Uurime neid tehnoloogiaid nullist ja rõhutame erinevate disainivalikute mõju sellel teel. Saate sügava arusaama mõlemast tootest, mõistmise, kuidas neid kasutada ja kuidas mitte, ning teadlikkuse, millele tähelepanu pöörata, kaaludes tulevikus teisi sõnumivahetustehnoloogiaid.
Enne kui alustame, ülevaade alustest.
Mis on sõnumivahetussüsteem ja milleks see on vajalik
Kaks rakendust saavad omavahel suhelda, kui nad on eelnevalt määratlenud liidese. Selle liidese määratlemine hõlmab transpordi või protokolli valimist, nagu HTTP, MQTT või SMTP, ning sõnumite vormaatide kokkuleppimist, mida süsteemid omavahel vahetavad. See võib olla range protsess, näiteks XML-skeemi määratlemine koormuse (payload) sõnumi nõudmistega, või palju vähem formaalne, näiteks kahe arendaja kokkulepe, et mõni osa HTTP-päringust sisaldab kliendi identifikaatorit.
Nii kaua kui sõnumite formaat ja nende edastamise kord on süsteemide vahel kokku lepitud, saavad nad omavahel suhelda, muretsemata teise süsteemi rakenduse üle. Nende süsteemide sisemised aspektid, nagu programmeerimiskeel või kasutatav raamistik, võivad aja jooksul muutuda. Niikaua kui leping ise on säilinud, võib suhtlemine jätkuda muutumatuna teiselt poolt. Need kaks süsteemi on tõhusalt lahti seotud (eraldatud) selle liidese kaudu.
Sõnumivahetussüsteemid hõlmavad tavaliselt vahendajat kahe süsteemi vahel, mis suhtlevad edasiseks eraldamiseks (saataja ja saaja või saajate lahutamiseks). Sõnumivahetussüsteem võimaldab saatjal saata sõnumi, teadmata, kus saaja asub, kas ta on aktiivne või kui palju saajaid on.
Vaatleme paar analooge probleemidest, mida sõnumivahetussüsteem lahendab, ja tutvustame mõned põhiterminoloogiad.
Point-to-Point
Alexandra läheb postkontorisse, et saata Adami pakk. Ta läheneb aknale ja annab töötajale paki. Töötaja võtab paki ja annab Alexandrale kviitungi. Adam ei pea olema kodus, kui pakk saadetakse. Alexandra on kindel, et pakk jõuab Adamile mingil hetkel tulevikus, ja ta saab jätkata oma asjade tegemist. Hiljem, mingil hetkel, saab Adam paki.
See on näide sõnumivahetusmudelist. punktpunkti. Postkontor siin toimib pakettide jaotussüsteemina, tagades, et iga pakett saadetakse üks kord. Postkontori kasutamine eraldab paketi saatmise akti selle kohaletoimetamisest.
Klassikalistes sõnumivahetussüsteemides rakendatakse „punkt-punkt” mudelit läbi reageeringud. Reageering toimib FIFO-pufferina (esimene, kes tuli, esimene, kes läks), millele saavad registreeruda üks või mitu tarbijat. Iga sõnum saadetakse ainult ühele registreeritud tarbijale. Reageeringud püüavad tavaliselt õiglaselt jaotada sõnumeid tarbijate vahel. Ainult üks tarbija saab antud sõnumi.
Reageeringutele rakendatakse mõistet „usaldusväärne” ("durable"). Usaldusväärsus — see on teenuse omadus, mis garanteerib, et sõnumivahetussüsteem salvestab sõnumid, kui aktiivseid tellijaid ei ole, kuni tarbija registreerub reageeringusse sõnumite kohaletoimetamiseks.
Usaldusväärsust aetakse sageli segamini püsivusega Kuigi need kaks mõistet on omavahel asendatavad, täidavad nad erinevaid funktsioone. Püsivus määrab, kas sõnum salvestatakse sõnumivahetuse süsteemis mingisugusesse salvestusse enne selle edastamist tarbijale. Queues'isse saadetud sõnumid võivad olla kas püsivad või mitte.
Punkt-punkt sõnumivahetust kasutatakse siis, kui kasutusjuht nõuab sõnumiga ühtset toimingut. Näiteks võib tuua esile raha lisamise kontole või kohaletoimetamise tellimise. Arutame hiljem, miks sõnumivahetuse süsteem ise ei suuda kindlustada ühtset kohaletoimetamist ja miks järjekorrad suudavad tagada kohaletoimetamise kõige paremal juhul. kas või üks kord.
Väljaandja-Postitaja
Gabriella helistab konverentsi numbrile. Kui ta on konverentsiga ühendatud, kuuleb ta kõike, mida räägib esineja, koos teiste kõne osalejatega. Kui ta katkestab, jääb ta kuulmata, mida öeldakse. Taaskohtudes kuuleb ta, mida räägitakse.
See on näide sõnumivahetusmudelist. väljaandmine-otluste tegemine. Конференц-связь выступает, как широковещательный механизм. Говорящий человек не заботится о том, сколько людей в настоящее время присоединились к звонку — система гарантирует, что любой подключившийся в настоящий момент услышит, что говорится.
В классических системах обмена сообщениями модель обмена сообщениями «публикация-подписка» реализуется через топики. Топик предоставляет такой же способ широковещания, как и механизм конференц-связи. Когда сообщение отправляется в топик, оно распределяется по всем подписанным пользователям.
Топики обычно ненадежные (nondurable). Как и слушатель, который не слышит, что говорится на конференц-звонке, когда слушатель отключается, подписчики топика пропускают любые сообщения, которые отправляются в тот момент, когда они находятся в автономном режиме. По этой причине можно сказать, что топики предоставляют гарантию доставки не более одного раза для каждого потребителя.
Õigustekstid, mis on seotud 'postituse-tellimise' tüübiga, kasutatakse tavaliselt siis, kui sõnumid on informatiivse iseloomuga ja ühe sõnumi kaotus ei ole eriti oluline. Näiteks võib teema edastada temperatuuri andmeid sensorigruppidelt kord sekundis. Süsteem, mis huvitub praegusest temperatuurist ja mis on teemale tellitud, ei muretse, kui ta mõne sõnumi vahele jätab — järgmine jõuab peagi.
Hübriidmudelid
Poelehe veebisaidi kaudu paigutatakse tellimuse teated 'sõnumijärjekorda'. Peamine nende teadete tarbija on täitmisüsteem. Lisaks peab auditeerimissüsteem saama koopiaid nendest tellimuste teadetest edasise jälgimise jaoks. Mõlemad süsteemid ei tohi sõnumeid vahele jätta, isegi kui need süsteemid ei ole mõnda aega kättesaadavad. Veebisait ei tohi teadlik olla teistest süsteemidest.
Kasutusskenaarid nõuavad sageli sõnumivahetusmudelite „väljaandmine-tellimine” ja „punkt-punkt” kombineerimist, näiteks juhul, kui mitmetele süsteemidele on vaja sõnumi koopiat ning sõnumi kaotuse vältimiseks on vajalik nii usaldusväärsus kui ka püsimine.
Sellistel juhtudel on vajalik sihtkoht (destination) (üldtermin järjekordade ja teemade jaoks), mis jaotab sõnumeid peamiselt nagu teema, nii et iga sõnum saadetakse eraldi süsteemi, mis on nende sõnumite vastu huvitatud, kuid ka nii, et iga süsteem võib määrata mitmeid tarbijaid, kes saavad sissetulevaid sõnumeid, mis rohkem sarnaneb järjekorraga. Sellisel juhul on lugemisviis — üks kord iga huvirühma jaoks. Need hübriidsed sihtkohad nõuavad sageli usaldusväärsust (durability), nii et kui tarbija katkestatakse, aktsepteeritakse sel ajal saatmiseks saadetud sõnumeid pärast tarbija taaskäivitamist.
Hübriidsed mudelid pole uued ja neid saab rakendada enamikus suhtlus süsteemides, sealhulgas nii ActiveMQ-s (virtuaalsete või komposiit-aadresside kaudu, mis ühendavad teemasid ja järjekordi) kui ka Kafka-s (kaudselt, kui selle adressaadi disaini põhijoonena).
Nüüd, kui meil on mõned põhitereenid ja arusaam sellest, miks meil võiks olla vajalik suhtlussüsteem, liikuge detailselt edasi.
Tõlge on tehtud:
Järgnev tõlgitud osa:
Jätkub…
Allikas: habr.com
