Tere kõigile!
Hakkasin tõlkima väikest raamatut:
««,
autor: Jakub Korab, kirjastus: O’Reilly Media, Inc., väljaandmise kuupäev: juuni 2017, ISBN: 9781492049296.
Raamatust: sissejuhatus:
«… See raamat õpetab teid mõtlema sõnumite vahetamise süsteemidele, võrreldes ja vastandades kahte populaarset vahendite tehnoloogiat: Apache ActiveMQ ja Apache Kafka. Siin tuuakse välja kasutusnäiteid ja arendusi, mis viisid selleni, et nende arendajad kasutasid täiesti erinevaid lähenemisviise ühe ja sama ala — sõnumite vahetamine süsteemide vahel vahendite kaudu. Uurime neid tehnoloogiaid nullist ning keskendume erinevate disainivalikute dopaatetusele selle tee jooksul. Saate sügava arusaama mõlemast tootest, mõistate, kuidas neid peaks ja ei tohiks kasutada, ning mõistate, millele tuleks tulevikus tähelepanu pöörata, kui kaalute muid sõnumite vahetamise tehnoloogiaid. …»
Tõlgitud seni:
Avaldan lõpetatud peatükke tõlke käigus.
PEATÜKK 1
Sissejuhatus
Süsteemidevaheline sõnumite vahetamine on üks väheseid arusaamatu valdkondi IT-s. Arendajana või arhitektil võite olla hästi tuttav erinevate raamistike ja andmebaasidega. Kuid tõenäoliselt on teil ainult kiire tutvus sellega, kuidas toimivad brokeritel põhinevad sõnumite tehnoloogiad. Kui see tõepoolest nii on, siis ärge muretsege, te ei ole üksi.
Inimesed puutuvad tavaliselt sõnumite vahetamise infrastruktuuriga kokku väga piiratud määral. Sageli ühendatakse nad süsteemiga, mis on loodud ammu, või laetakse internetist alla distributiiv ja paigaldatakse PROMsse, enne kui nad hakkavad selle jaoks koodi kirjutama. Pärast infrastruktuuri ülesseadmist PROMiss võivad tulemused olla ebamugavad: sõnumite kadumine tõrgete korral, saatmine ei tööta nii, nagu ootasite, või vahendajad „hingavad” teie tootjad kinni või ei saada sõnumeid teie tarbijatele.
Kas see kõlab tuttavalt?
Levinud stsenaarium on see, et teie sõnumivahetuse kood töötab suurepäraselt, kuni see ühel hetkel enam ei tööta. See periood uinutab ettevaatlikkuse ja annab vale turvatunde, mis toob kaasa veelgi rohkem koodi, mis põhineb valehinnangutel tehnoloogia põhilise käitumise kohta. Kui midagi hakkab valesti minema, seisate silmitsi ebamugava tõega: te ei mõistnud tõeliselt toote põhikäitumist või autori valitud kompromisse, nagu näiteks jõudlust versus usaldusväärsust või tehingulisust versus horisontaalset skaleeritavust.
Ilma sügava arusaamata sellest, kuidas maaklerid töötavad, teevad inimesed näiliselt mõistlikke väiteid nende sõnumivahetussüsteemide kohta, nagu:
- Süsteem ei kaota kunagi sõnumeid
- Sõnumid töödeldakse järjestikku
- Tarbijate lisamine kiirendab süsteemi
- Sõnumid tarnitakse ainult korra
Kahjuks põhinevad mõned neist väidetest eeldustel, mis kehtivad ainult teatud tingimustel, samas kui teised on lihtsalt valed.
See raamat õpetab teid mõtlema maakleripõhiste sõnumivahetussüsteemide üle, võrreldes ja vastandades kahte populaarset maakleritehnoloogiat: Apache ActiveMQ ja Apache Kafka. Siin tutvustatakse kasutusjuhtumeid ja arendusturge, mis on viinud selleni, et nende arendajad on valinud täiesti erinevad lähenemisviisid samale valdkonnale – süsteemide vaheline sõnumivahetus vahemaakleriga. Käsitleme neid tehnoloogiaid algusest ning toome esile erinevate disainivõimaluste mõju sellel teekonnal. Saate sügava arusaama mõlemast tootest, arusaama sellest, kuidas neid tuleks ja ei tohiks kasutada, ning arusaama sellest, millele tuleks tulevikus teiste sõnumivahetustehnoloogiate kaalumisel tähelepanu pöörata.
Enne kui alustada, võtame ülevaate põhialustest.
Mis on sõnumivahetussüsteem ja miks see vajalik on
Kaks rakendust saavad omavahel suhelda ainult siis, kui nad on esmalt määranud liidese. Selle liidese määramine hõlmab transpordi või protokolli nagu HTTP, MQTT või SMTP valimist ning süsteemide vahel vahetatavate sõnumiformaatide kokkuleppimist. See võib olla range protsess, nagu XML-skeemi määramine sõnumi kasuliku koormuse (payload) nõuete jaoks, või võib see olla palju vähem ametlik, näiteks kahe arendaja kokkulepe, et teatud osa HTTP-päringust sisaldab kliendi identifikaatorit.
Niikaua kui sõnumiformaadid ja nende saatmise järjekord on süsteemide vahel kokku lepitud, saavad nad omavahel suhelda, muretsemata teise süsteemi rakenduse üle. Nende süsteemide sisemus, nagu programmeerimiskeel või kasutatud raamistik, võib ajas muutuda. Seni, kuni leping ise püsib, võivad nad jätkata koostööd muutumatuna teiselt poolt. Need kaks süsteemi on selle liidese kaudu tõhusalt eraldatud.
Sõnumite vahetamise süsteemid hõlmavad tavaliselt vahendajat kahe süsteemi vahel, mis suhtlevad, et edasiselt eraldada saatja saajast või saajatest. Selle tõttu võimaldab sõnumite vahetamise süsteem saatjal saata sõnumi, teadmata, kus saaja asub, kas ta on aktiivne või kui palju on tema koopiaid.
Vaadakem mõningaid analooge probleemide tüüpide kohta, mida sõnumite vahetamise süsteem lahendab, ja tutvustame mõningaid põhiterme.
Point-to-Point
Alexandra läheb posti, et saata Adamile pakk. Ta läheneb aknale ja annab töötajale paki. Töötaja võtab paki ja annab Alexandrale kviitungi. Adamil ei pea olema kodus paki saatmise ajal. Alexandra on kindel, et pakk toimetatakse Adami kätte mingil hetkel tulevikus ja ta saab oma asjadega edasi tegeleda. Hiljem, millegi pärast, saab Adam paki.
See on näide sõnumite vahetamise mudelist punkt-punkt. Postkontor toimib siin pakkide jagamise mehhanismina, tagades, et iga pakk toimetatakse kohale vaid üks kord. Postkontori kasutamine eraldab paki saatmise teo selle kätte toimetamisest.
Klassikalistes sõnumivahetussüsteemides rakendatakse „punkt-punkt“ mudelit läbi järjekordade. Järjekord toimib nagu FIFO (esimene sisenenud, esimene väljunud) puhversüsteem, mis võib olla ühele või mitmele tarbijale tellitud. Iga sõnum toimetatakse ainult ühele tellitud tarbijale. Järjekorrad püüavad tavaliselt sõnumeid tarbijate vahel õiglaselt jaotada. Ainult üks tarbija saab antud sõnumi.
Järjekordadele rakendatakse mõistet „usaldusväärsed“ („durable“). Usaldusväärsus — see on teenuse omadus, mis tagab, et sõnumivahetussüsteem salvestab sõnumid, kui aktiivseid tellijaid ei ole, kuni tarbija tellib järjekorra sõnumite kohaletoimetamiseks.
Usaldusväärsust segatakse sageli kokku püsivusega , ja kuigi need kaks mõistet on omavahel vahetatavad, täidavad need erinevaid funktsioone. Püsivus määrab, kas sõnum salvestatakse sõnumivahetussüsteemi mingisugusesse salvestusse enne selle vastuvõtmist ja tarnimist tarbijale. Järjekorda saadetavad sõnumid võivad olla kas püsivad või mitte.
Punkt-punkt sõnumivahetust kasutatakse, kui kasutusjuht nõuab sõnumiga ühekordset toimingut. Näiteks võib tuua raha ülekande kontole või tellimuse esitamise kohaletoimetamiseks. Arutame hiljem, miks sõnumivahetussüsteem iseenesest ei suuda tagada ühekordset kohaletoimetamist ja miks järjekorrad saavad tagada kohaletoimetamise vähemalt korra.
Avaldaja-Tellijate
Gabriella helistab konverentsi numbrile. Kui ta on konverentsiga ühendatud, kuulab ta kõike, mida räägib esineja, koos teiste kõneosalistega. Kui ta katkestab ühenduse, jääb talle kuulmata, mida öeldi. Ta jätkab kuulamist, kui ta uuesti ühendub.
See on näide sõnumite vahetamise mudelist publikatsiooni-tellimus. Konverentsi side toimib nagu ringhäälingumehhanism. Rääkija ei muretse, kui palju inimesi hetkel kõnele on — süsteem tagab, et igaühel, kes on sel hetkel ühenduses, on kuulda, mida räägitakse.
Klassikalistes sõnumivahetussüsteemides rakendatakse „publikatsiooni-tellimuse“ sõnumivahetuse mudelit läbi teemadeTeema pakub laiaulatuslikku võimalust nagu konverentskõne mehhanism. Kui teade saadetakse teemasse, jaotatakse see kõikidele tellinud kasutajatele..
Teemad on tavaliselt ebakindlad (nondurable).Nagu kuulaja, kes ei kuule, mis konverentsikõnes öeldakse, kui kuulaja end välja lülitab, jätavad teema tellijad vahele kõik sõnumid, mis saadetakse just siis, kui nad on offline. Seetõttu saab öelda, et teemad pakuvad kohaletoimetamise garantii kuni ühe korra iga tarbija jaoks.
Režiimipõhine sõnumite vahetus kasutatakse tavaliselt siis, kui sõnumid on informatiivsed ning ühe sõnumi kadumine ei ole kuigi oluline. Näiteks võib teema edastada temperatuurinäidud sensorigruppidelt kord sekundis. Süsteem, mis huvitub praegusest temperatuurist ja mis on selle teema tellija, ei muretseks, kui ta sõnumi vahele jätab — järgmine saab varsti.
Hübriidsed mudelid
Poosiv veebileht paigutab tellimuste sõnumid "sõnumite järjekorda". Nende sõnumite peamine tarbija on täideviimise süsteem. Lisaks peab auditeerimissüsteem omama koopiad neist tellimuste sõnumitest edasiseks jälgimiseks. Mõlemad süsteemid ei saa sõnumeid vahele jätta, isegi kui süsteemid ei ole mõneks ajaks kättesaadavad. Veebileht ei peaks teadma muudest süsteemidest.
Kasutusskeemid nõuavad sageli sõnumite vahetuse mudelite "publikatsioon-tellimine" ja "punkt-punkt" kombineerimist, näiteks siis, kui mitmed süsteemid vajavad sõnumi koopiaid, ja sõnumi kaotamise vältimiseks on vajalik nii usaldusväärsus kui ka püsivus.
Neis olukordades on vajalik adressaat (destination) (üldine mõisted järjekordadele ja teemadele), mis jaotab sõnumid peamiselt nagu teema, nii et iga sõnum saadetakse eraldi süsteemi, mis on nende sõnumite osas huvitatud, samuti saab iga süsteem määrata mitmeid tarbijaid, kes saavad sisenenud sõnumid, mis sarnaneb rohkem järjekorrale. Selles juhul on lugemise tüüp — üks kord iga huvitatud osapoole jaoks.. Need hybrid addresses often require reliability, so if a consumer disconnects, messages sent during that time are accepted after the consumer reconnects.
Hybrid models are not new and can be used in most messaging systems, including both ActiveMQ (through virtual or composite addresses that combine topics and queues) and Kafka (implicitly, as a fundamental design property of its address).
Now that we have some basic terminology and understanding of what we might need a messaging system for, let's move on to the details.
Translation completed:
Next translated part:
Jätkub…
Allikas: habr.com
