Ahoj všetci!
Začal som prekladať malú knihu:
«",
autor: Jakub Korab, vydavateľ: O'Reilly Media, Inc., dátum vydania: jún 2017, ISBN: 9781492049296.
Z úvodu ku knihe:
"... Táto kniha vás naučí, ako premýšľať o systémoch sprostredkovania správ porovnaním a porovnaním dvoch populárnych technológií sprostredkovania: Apache ActiveMQ a Apache Kafka. Načrtne prípady použitia a vývojové stimuly, ktoré viedli ich vývojárov k výrazne odlišným prístupom k rovnakej oblasti sprostredkovaných správ medzi systémami. Pozrieme sa na tieto technológie od základov a upozorníme na vplyv rôznych dizajnových možností. Získate hlboké porozumenie obom produktom, pochopíte, ako by sa mali a nemali používať, a pochopíte, na čo si dávať pozor pri zvažovaní iných technológií odosielania správ v budúcnosti. … »
Doteraz preložené časti:
Dokončené kapitoly uverejním tak, ako budú preložené.
KAPITOLA 1
Úvod
Medzisystémové zasielanie správ je jednou z najmenej pochopených oblastí IT. Ako vývojár alebo architekt možno dobre poznáte rôzne rámce a databázy. Je však pravdepodobné, že máte len letmý pohľad na to, ako fungujú technológie zasielania správ založené na makléroch. Ak sa tak cítite, nebojte sa, ste v dobrej spoločnosti.
Ľudia majú zvyčajne veľmi obmedzený kontakt s infraštruktúrou správ. Často sa pripájajú k dávno vytvorenému systému alebo si z internetu stiahnu distribučnú súpravu, nainštalujú ju do PROM a začnú pre ňu písať kód. Po spustení infraštruktúry v PROM môžu byť výsledky zmiešané: správy sa strácajú pri pádoch, odosielanie nefungujú tak, ako očakávate, alebo makléri zavesia vašich producentov alebo neposielajú správy vašim spotrebiteľom.
Znie povedome?
Bežný scenár, keď váš kód na odosielanie správ zatiaľ funguje dobre. Kým to prestane fungovať. Toto obdobie upokojuje ostražitosť a dáva falošný pocit bezpečia, čo vedie k ešte väčšiemu kódu založenému na falošných predstavách o základnom správaní technológie. Keď sa veci začnú kaziť, stretnete sa s nepríjemnou pravdou: že ste skutočne nepochopili základné správanie produktu alebo kompromisy, ktoré autori zvolili, ako napríklad výkon vs. robustnosť alebo transakčné vs. horizontálna škálovateľnosť.
Bez hlbokého pochopenia toho, ako makléri fungujú, ľudia robia zdanlivo rozumné tvrdenia o svojich systémoch zasielania správ, ako napríklad:
- Systém nikdy nestratí správy
- Správy budú spracované postupne
- Pridaním spotrebiteľov bude systém rýchlejší
- Správy budú doručené iba raz
Bohužiaľ, niektoré z týchto tvrdení sú založené na predpokladoch, ktoré platia len za určitých okolností, zatiaľ čo iné jednoducho nie sú pravdivé.
Táto kniha vás naučí, ako uvažovať o systémoch sprostredkovania správ porovnaním a porovnaním dvoch populárnych technológií brokerov: Apache ActiveMQ a Apache Kafka. Načrtne prípady použitia a vývojové stimuly, ktoré viedli ich vývojárov k výrazne odlišným prístupom k rovnakej oblasti sprostredkovaných správ medzi systémami. Pozrieme sa na tieto technológie od základov a upozorníme na vplyv rôznych dizajnových možností. Získate hlboké porozumenie obom produktom, pochopíte, ako by sa mali a nemali používať, a pochopíte, na čo si dávať pozor pri zvažovaní iných technológií na odosielanie správ v budúcnosti.
Skôr než začneme, prejdeme si základy.
Čo je to systém zasielania správ a prečo je potrebný
Aby mohli dve aplikácie medzi sebou komunikovať, musia si najprv definovať rozhranie. Definícia tohto rozhrania zahŕňa výber prenosu alebo protokolu, ako je HTTP, MQTT alebo SMTP, a dohodnutie formátov správ, ktoré si systémy budú vymieňať. Môže to byť prísny proces, ako napríklad definovanie schémy XML s požiadavkami na náklady na prenos správy, alebo to môže byť oveľa menej formálne, ako napríklad dohoda medzi dvoma vývojármi, že niektorá časť požiadavky HTTP bude obsahovať identifikátor klienta.
Pokiaľ bude formát správ a poradie, v akom sa odosielajú, medzi systémami konzistentné, budú môcť navzájom komunikovať bez obáv z implementácie druhého systému. Vnútorné časti týchto systémov, ako napríklad použitý programovací jazyk alebo rámec, sa môžu časom meniť. Pokiaľ je zachovaná samotná zmluva, interakcia môže na druhej strane pokračovať bez zmeny. Tieto dva systémy sú týmto rozhraním účinne oddelené (oddelené).
Systémy správ zvyčajne zahŕňajú sprostredkovateľa medzi dvoma systémami, ktoré interagujú, aby ďalej oddeľovali (oddeľovali) odosielateľa od príjemcu alebo príjemcov. V tomto prípade systém správ umožňuje odosielateľovi odoslať správu bez toho, aby vedel, kde sa príjemca nachádza, či je aktívny alebo koľko ich inštancií.
Pozrime sa na niekoľko analógií pre druhy problémov, ktoré systém zasielania správ rieši, a predstavme si niektoré základné pojmy.
Z bodu do bodu
Alexandra ide na poštu poslať Adamovi balík. Podíde k okienku a podá balík zamestnancovi. Zamestnanec vyzdvihne balík a vydá Alexandre potvrdenie. Adam nemusí byť pri odosielaní balíka doma. Alexandra je presvedčená, že balík bude Adamovi doručený niekedy v budúcnosti a môže pokračovať vo svojej práci. Neskôr, v určitom okamihu, Adam dostane balíček.
Toto je príklad modelu zasielania správ bod k bodu. Pošta tu funguje ako mechanizmus distribúcie balíkov a zabezpečuje, že každý balík je doručený raz. Použitie pošty oddeľuje úkon odoslania balíka od doručenia balíka.
V klasických systémoch zasielania správ je model bod-bod implementovaný prostredníctvom fronta. Front funguje ako vyrovnávacia pamäť FIFO (prvý dovnútra, prvý von), do ktorej sa môže prihlásiť jeden alebo viac spotrebiteľov. Každá správa je iba doručená jedného z prihlásených spotrebiteľov. Fronty sa zvyčajne snažia spravodlivo distribuovať správy medzi spotrebiteľmi. Túto správu dostane iba jeden spotrebiteľ.
Pojem „trvanlivý“ sa používa na fronty. Spoľahlivosť je vlastnosť služby, ktorá zaručuje, že systém zasielania správ bude uchovávať správy v neprítomnosti aktívnych účastníkov, kým sa spotrebiteľ neprihlási do frontu na doručovanie správ.
Spoľahlivosť sa často zamieňa s vytrvalosť a hoci sú tieto dva pojmy zameniteľné, plnia rôzne funkcie. Perzistencia určuje, či je správa zapísaná systémom zasielania správ do nejakého úložiska medzi jej prijatím a odoslaním spotrebiteľovi. Správy odoslané do frontu môžu alebo nemusia byť trvalé.
Posielanie správ z bodu do bodu sa používa, keď prípad použitia vyžaduje jednu akciu so správou. Príklady zahŕňajú vloženie prostriedkov na účet alebo splnenie objednávky na doručenie. Neskôr si rozoberieme, prečo samotný systém zasielania správ nie je schopný poskytnúť jednorazové doručenie a prečo môžu fronty v najlepšom prípade poskytnúť záruku doručenia. aspoň raz.
Vydavateľ-predplatiteľ
Gabriella vytočí číslo konferencie. Kým je pripojená ku konferencii, počuje všetko, čo hovoriaci, spolu so zvyškom účastníkov hovoru. Keď sa zatmie, uniká jej, čo sa hovorí. Keď sa znova pripojí, naďalej počuje, čo sa hovorí.
Toto je príklad modelu zasielania správ zverejniť-prihlásiť sa. Konferenčný hovor funguje ako mechanizmus vysielania. Osoba, ktorá hovorí, sa nestará o to, koľko ľudí práve telefonuje – systém zabezpečuje, že každý, kto je práve pripojený, bude počuť, čo sa hovorí.
V klasických systémoch zasielania správ je model zasielania správ typu zverejnenie a predplatenie implementovaný prostredníctvom vrcholy. Téma poskytuje rovnakú metódu vysielania ako mechanizmus konferencie. Keď je správa uverejnená v téme, je distribuovaná pre všetkých prihlásených používateľov.
Témy zvyčajne nespoľahlivý (netrvalý). Podobne ako poslucháč, ktorý nepočuje, čo sa hovorí počas konferenčného hovoru, keď poslucháč prejde do režimu offline, predplatiteľom témy zmeškajú všetky správy odoslané v čase, keď sú offline. Z tohto dôvodu môžeme povedať, že topy poskytujú záruku doručenia. nie viac ako raz pre každého spotrebiteľa.
Správy typu Publish-Subscribe sa zvyčajne používajú, keď majú správy informačný charakter a strata jednej správy nie je zvlášť významná. Napríklad téma môže prenášať údaje o teplote zo skupiny senzorov raz za sekundu. Systém, ktorý sa zaujíma o aktuálnu teplotu a ktorý sa prihlási k téme, si nebude robiť starosti, ak mu chýba správa – čoskoro príde ďalšia.
hybridné modely
Webová stránka obchodu zaraďuje správy o objednávke do „poradia správ“. Hlavným konzumentom týchto správ je výkonný systém. Okrem toho by mal mať systém auditu kópie týchto správ o objednávkach na neskoršie sledovanie. Oba systémy nemôžu minúť správy, aj keď samotné systémy sú nejaký čas nedostupné. Webová stránka by nemala poznať iné systémy.
Prípady použitia si často vyžadujú kombináciu modelov publikovania a predplatenia a posielania správ z bodu do bodu, napríklad keď viaceré systémy potrebujú kópiu správy a na zabránenie strate správy sa vyžaduje spoľahlivosť a vytrvalosť.
V týchto prípadoch je potrebný cieľ (všeobecný termín pre fronty a témy), ktorý distribuuje správy v podstate ako tému, takže každá správa je odoslaná samostatnému systému, ktorý má o tieto správy záujem, ale v ktorom môže každý systém definovať niekoľko spotrebiteľov. ktoré prijímajú prichádzajúce správy, čo je skôr rad. Typ čítania je v tomto prípade - raz pre každú zainteresovanú stranu. Tieto hybridné destinácie často vyžadujú trvanlivosť, takže ak sa spotrebiteľ odpojí, správy odoslané v tom čase budú akceptované, keď sa spotrebiteľ znova pripojí.
Hybridné modely nie sú nové a možno ich aplikovať na väčšinu systémov zasielania správ, vrátane ActiveMQ (prostredníctvom virtuálnych alebo zložených destinácií, ktoré kombinujú témy a fronty) a Kafka (implicitne, ako základná vlastnosť jeho dizajnu destinácií).
Teraz, keď máme základnú terminológiu a rozumieme tomu, na čo by mohol byť systém zasielania správ užitočný, poďme do detailov.
Preklad hotový:
Ďalšia preložená časť:
Ak sa chcete pokračovať ...
Zdroj: hab.com