Sveiki visi!
Pradėjau versti mažą knygelę:
«",
autorius: Jakub Korab, leidėjas: O'Reilly Media, Inc., išleidimo data: 2017 m. birželio mėn., ISBN: 9781492049296.
Iš knygos įžangos:
"... Ši knyga išmokys jus galvoti apie tarpininkų pranešimų sistemas, palyginti ir sugretinti dvi populiarias brokerių technologijas: Apache ActiveMQ ir Apache Kafka. Jame bus aprašyti naudojimo atvejai ir plėtros paskatos, dėl kurių jų kūrėjai pasirinko labai skirtingus požiūrius į tą pačią sritį – pranešimų siuntimą tarp sistemų su tarpiniu tarpininku. Pažvelgsime į šias technologijas nuo pat pradžių ir pabrėžsime įvairių dizaino pasirinkimų poveikį. Įgysite gilų supratimą apie abu produktus, suprasite, kaip jie turėtų būti ir nereikėtų naudoti, ir suprasite, į ką atkreipti dėmesį svarstant apie kitas pranešimų perdavimo technologijas ateityje. ... "
Iki šiol išverstos dalys:
Užbaigtus skyrius paskelbsiu taip, kaip jie bus išversti.
1 SKYRIUS
įvedimas
Sistemos į sistemą pranešimų siuntimas yra viena iš mažiausiai suprantamų IT sričių. Kaip kūrėjas ar architektas galite būti gerai susipažinęs su įvairiomis sistemomis ir duomenų bazėmis. Tačiau tikėtina, kad jūs tik trumpai žinote, kaip veikia tarpininko žinučių siuntimo technologijos. Jei taip jaučiatės, nesijaudinkite, esate geroje kompanijoje.
Žmonės paprastai turi labai ribotą ryšį su pranešimų infrastruktūra. Jie dažnai prisijungia prie seniai sukurtos sistemos arba atsisiunčia distribuciją iš interneto, įdiegia į PROM ir pradeda rašyti jai kodą. Paleidus infrastruktūrą PROM, rezultatai gali būti nevienareikšmiai: prarandami pranešimai dėl gedimų, siuntimas neveikia taip, kaip tikėjotės, arba brokeriai „pakabina“ jūsų gamintojus arba nesiunčia žinučių jūsų vartotojams.
Skamba pažįstamai?
Įprastas scenarijus yra toks, kai jūsų pranešimų kodas šiuo metu veikia puikiai. Kol nustos veikti. Šis laikotarpis užliūliuoja klaidingą saugumo jausmą, todėl atsiranda daugiau kodų, pagrįstų klaidingais įsitikinimais apie pagrindinį technologijos elgesį. Kai viskas pradeda klostytis blogai, susiduriate su nepatogia tiesa: kad jūs iš tikrųjų nesupratote pagrindinės produkto elgsenos arba autorių pasirinktų kompromisų, pvz., našumo ir patikimumo arba operacijų ir horizontalaus mastelio. .
Neturėdami gilaus supratimo apie tai, kaip veikia brokeriai, žmonės pateikia iš pažiūros pagrįstus pareiškimus apie savo pranešimų sistemas, pavyzdžiui:
- Sistema niekada nepraras pranešimų
- Laiškai bus apdorojami nuosekliai
- Pridėjus vartotojus sistema taps greitesnė
- Žinutės bus pristatytos tik vieną kartą
Deja, kai kurie iš šių teiginių yra pagrįsti prielaidomis, kurios galioja tik tam tikromis aplinkybėmis, o kiti yra tiesiog neteisingi.
Ši knyga išmokys mąstyti apie tarpininkavimu pagrįstas pranešimų siuntimo sistemas, palyginti ir sugretinti dvi populiarias brokerių technologijas: Apache ActiveMQ ir Apache Kafka. Jame bus aprašyti naudojimo atvejai ir plėtros paskatos, dėl kurių jų kūrėjai pasirinko labai skirtingus požiūrius į tą pačią sritį – pranešimų siuntimą tarp sistemų su tarpiniu tarpininku. Pažvelgsime į šias technologijas nuo pat pradžių ir pabrėžsime įvairių dizaino pasirinkimų poveikį. Įgysite gilų supratimą apie abu produktus, suprasite, kaip jie turėtų būti ir neturėtų būti naudojami, ir suprasite, į ką atkreipti dėmesį svarstant apie kitas pranešimų perdavimo technologijas ateityje.
Prieš pradėdami, pereikime prie pagrindų.
Kas yra pranešimų sistema ir kodėl ji reikalinga?
Kad dvi programos galėtų susisiekti viena su kita, jos pirmiausia turi apibrėžti sąsają. Apibrėžiant šią sąsają reikia pasirinkti transportą arba protokolą, pvz., HTTP, MQTT arba SMTP, ir derėtis dėl pranešimų formatų, kuriais bus keičiamasi tarp sistemų. Tai gali būti griežtas procesas, pvz., apibrėžti XML schemą su pranešimo naudingumo apkrovos reikalavimais, arba jis gali būti daug mažiau formalus, pvz., dviejų kūrėjų susitarimas, kad tam tikroje HTTP užklausos dalyje bus kliento identifikatorius .
Kol pranešimų formatas ir jų siuntimo tvarka yra vienodi tarp sistemų, jos gali bendrauti tarpusavyje nesijaudindamos dėl kitos sistemos įgyvendinimo. Šių sistemų vidinės dalys, pvz., naudojama programavimo kalba ar sistema, laikui bėgant gali keistis. Kol išlaikoma pati sutartis, sąveika gali tęstis be pakeitimų iš kitos pusės. Šios sąsajos dvi sistemos yra veiksmingai atsietos (atskiriamos).
Pranešimų siuntimo sistemose paprastai yra tarpininkas tarp dviejų sistemų, kurios sąveikauja toliau atsieti (atskirti) siuntėją nuo gavėjo ar gavėjų. Šiuo atveju pranešimų sistema leidžia siuntėjui išsiųsti pranešimą, nežinant, kur yra gavėjas, ar jis aktyvus, kiek atvejų yra.
Pažvelkime į keletą problemų, kurias sprendžia pranešimų sistema, analogijų ir pristatysime keletą pagrindinių terminų.
Nuo tasko iki tasko
Aleksandra eina į paštą išsiųsti Adomui paketo. Ji nueina prie lango ir paduoda darbuotojui paketą. Darbuotoja paima paketą ir Aleksandrai įteikia kvitą. Adomui nereikia būti namuose, kai siunčiama siunta. Alexandra įsitikinusi, kad paketas Adomui bus pristatytas kada nors ateityje, ir galės tęsti savo verslą. Vėliau tam tikru momentu Adomas gauna paketą.
Tai yra pranešimų modelio pavyzdys nuo tasko iki tasko. Paštas čia veikia kaip siuntų skirstymo mechanizmas, užtikrinantis, kad kiekviena siunta būtų pristatyta vieną kartą. Pašto naudojimas atskiria siuntos išsiuntimą nuo siuntos pristatymo.
Klasikinėse pranešimų sistemose „nuo taško iki taško“ modelis įgyvendinamas per eilės. Eilė veikia kaip FIFO (pirmas įėjimas, pirmasis išėjimas) buferis, kurį gali prenumeruoti vienas ar keli vartotojai. Kiekvienas pranešimas pristatomas tik vienam iš prenumeruojančių vartotojų. Eilėse paprastai bandoma teisingai paskirstyti pranešimus vartotojams. Tik vienas vartotojas gaus šį pranešimą.
Terminas „patvarus“ taikomas eilėms. Patikimumas yra paslaugos ypatybė, užtikrinanti, kad pranešimų sistema išlaikys pranešimus, kai nėra aktyvių abonentų, kol vartotojas užsiprenumeruos pranešimų siuntimo eilę.
Patikimumas dažnai painiojamas su atkaklumas ir nors abu terminai vartojami pakaitomis, jie atlieka skirtingas funkcijas. Patvarumas lemia, ar pranešimų sistema rašo pranešimą į tam tikrą saugyklą nuo jo gavimo iki išsiuntimo vartotojui. Į eilę išsiųsti pranešimai gali būti nuolatiniai arba ne.
Tiesioginis susirašinėjimas naudojamas, kai naudojant pranešimą reikia atlikti vienkartinį veiksmą. Pavyzdžiai: lėšų įnešimas į sąskaitą arba pristatymo užsakymo įvykdymas. Vėliau aptarsime, kodėl pranešimų siuntimo sistema pati negali užtikrinti vienkartinio pristatymo ir kodėl eilės geriausiu atveju gali suteikti pristatymo garantiją nors karta.
Leidėjas-Abonentas
Gabriella surenka konferencijos numerį. Prisijungusi prie konferencijos ji girdi viską, ką sako kalbėtojas, kartu su kitais pokalbio dalyviais. Kai ji atsipalaiduoja, ji pasigenda to, kas sakoma. Kai vėl prisijungia, ji ir toliau girdi, kas sakoma.
Tai yra pranešimų modelio pavyzdys publikuoti-prenumeruoti. Konferencinis skambutis veikia kaip transliavimo mechanizmas. Kalbančiam žmogui nesvarbu, kiek žmonių šiuo metu skambina – sistema užtikrina, kad visi šiuo metu prisijungę žmonės girdės, kas kalbama.
Klasikinėse pranešimų siuntimo sistemose paskelbimo ir prenumeratos pranešimų siuntimo modelis įgyvendinamas per viršūnes. Topic siūlo tą patį transliavimo metodą kaip ir konferencijų mechanizmas. Kai žinutė siunčiama į temą, ji išplatinama visiems prenumeruojantiems vartotojams.
Temos dažniausiai yra nepatikimas (nepatvarus). Kaip klausytojas, kuris negirdi, kas pasakyta konferencinio skambučio metu, kai klausytojas atsijungia, temos prenumeratoriai praleidžia bet kokius pranešimus, kurie siunčiami būdami neprisijungę. Dėl šios priežasties galime teigti, kad temos suteikia pristatymo garantiją ne daugiau kaip vieną kartą kiekvienam vartotojui.
Skelbti-prenumeruoti pranešimai paprastai naudojami, kai pranešimai yra informacinio pobūdžio ir vieno pranešimo praradimas nėra ypač reikšmingas. Pavyzdžiui, tema gali kartą per sekundę perduoti temperatūros rodmenis iš jutiklių grupės. Sistema, kuri domisi esama temperatūra ir prenumeruoja temą, nesijaudins, jei praleis pranešimą – artimiausiu metu ateis kita.
hibridiniai modeliai
Parduotuvės svetainėje užsakymo pranešimai pateikiami į „pranešimų eilę“. Pagrindinis šių pranešimų vartotojas yra vykdomoji sistema. Be to, audito sistema turėtų turėti šių užsakymų pranešimų kopijas, kad būtų galima vėliau sekti. Abi sistemos negali leisti pranešimų, net jei pačios sistemos kurį laiką nepasiekiamos. Svetainė neturėtų žinoti apie kitas sistemas.
Naudojimo atvejai dažnai reikalauja publikavimo-prenumeratos ir tiesioginio pranešimo modelių derinio, pvz., kai kelioms sistemoms reikalinga pranešimo kopija ir reikalingas patikimumas ir atkaklumas, kad būtų išvengta pranešimų praradimo.
Šiems atvejams reikia paskirties vietos (bendras eilių ir temų terminas), kuri platina pranešimus iš esmės kaip temą, kad kiekvienas pranešimas būtų siunčiamas į atskirą sistemą, kuri domisi tais pranešimais, bet taip pat, kad kiekviena sistema galėtų apibrėžti kelis vartotojus, kurie gauna gaunamus pranešimus. žinutes, kurios labiau primena eilę. Skaitymo tipas šiuo atveju yra vieną kartą kiekvienai suinteresuotajai šaliai. Šios hibridinės paskirties vietos dažnai reikalauja patvarumo, kad vartotojui atsijungus nuo interneto, tuo metu išsiųsti pranešimai būtų gaunami vartotojui vėl prisijungus.
Hibridiniai modeliai nėra nauji ir gali būti naudojami daugumoje pranešimų sistemų, įskaitant ActiveMQ (per virtualias arba sudėtines paskirties vietas, kurios sujungia temas ir eiles), ir Kafka (netiesiogiai, kaip pagrindinę paskirties vietos dizaino savybę).
Dabar, kai turime pagrindinę terminiją ir supratimą, kam galėtume naudoti pranešimų sistemą, pereikime prie smulkmenų.
Vertimas atliktas:
Ši išversta dalis:
Turi būti tęsiama ...
Šaltinis: www.habr.com