Ahoj všichni!
Začal jsem překládat malou knihu:
«",
autor: Jakub Korab, vydavatel: O'Reilly Media, Inc., datum vydání: červen 2017, ISBN: 9781492049296.
Z úvodu ke knize:
"... Tato kniha vás naučí přemýšlet o systémech zasílání zpráv brokerů, porovnává a dává do kontrastu dvě populární technologie brokerů: Apache ActiveMQ a Apache Kafka. Nastíní případy použití a pobídky k vývoji, které vedly jejich vývojáře k velmi odlišným přístupům ke stejné oblasti – zasílání zpráv mezi systémy se zprostředkujícím zprostředkovatelem. Podíváme se na tyto technologie od základu a zdůrazníme dopad různých designových voleb. Získáte hluboké porozumění oběma produktům, pochopíte, jak by se měly a neměly používat, a pochopíte, na co se zaměřit při zvažování dalších technologií zasílání zpráv v budoucnu. ... “
Dosud přeložené díly:
Dokončené kapitoly zveřejním tak, jak budou přeloženy.
KAPITOLA 1
úvod
Zasílání zpráv ze systému do systému je jednou z nejméně pochopených oblastí IT. Jako vývojář nebo architekt možná velmi dobře znáte různé frameworky a databáze. Je však pravděpodobné, že s tím, jak fungují technologie zasílání zpráv založené na zprostředkovatelích, znáte jen letmo. Pokud se tak cítíte, nebojte se, jste v dobré společnosti.
Lidé mají obvykle velmi omezený kontakt s infrastrukturou zasílání zpráv. Často se připojí k již dávno vytvořenému systému, nebo si stáhnou distribuci z internetu, nainstalují ji do PROM a začnou pro ni psát kód. Po spuštění infrastruktury v PROM mohou být výsledky smíšené: zprávy se ztrácejí kvůli selhání, odesílání nefunguje tak, jak jste očekávali, nebo makléři „zavěšují“ vaše producenty nebo neposílají zprávy vašim spotřebitelům.
Zní to povědomě?
Běžným scénářem je situace, kdy váš kód pro zasílání zpráv prozatím funguje skvěle. Dokud to nepřestane fungovat. Toto období ukolébá něčí stráž do falešného pocitu bezpečí, což vede k dalšímu kódu založenému na falešných přesvědčeních o základním chování technologie. Když se věci začnou kazit, stojíte před nepohodlnou pravdou: že jste ve skutečnosti nepochopili základní chování produktu nebo kompromisy, které autoři zvolili, jako je výkon versus spolehlivost nebo transakční versus horizontální škálovatelnost. .
Bez hlubokého pochopení toho, jak makléři fungují, dělají lidé zdánlivě rozumná prohlášení o svých systémech zasílání zpráv, jako například:
- Systém nikdy neztratí zprávy
- Zprávy budou zpracovány postupně
- Přidáním spotřebitelů bude systém rychlejší
- Zprávy budou doručeny pouze jednou
Bohužel některá z těchto tvrzení jsou založena na předpokladech, které platí pouze za určitých okolností, zatímco jiná jsou prostě nesprávná.
Tato kniha vás naučí, jak přemýšlet o systémech zasílání zpráv založených na zprostředkovatelích, porovnává a staví do kontrastu dvě populární technologie zprostředkovatelů: Apache ActiveMQ a Apache Kafka. Nastíní případy použití a pobídky k vývoji, které vedly jejich vývojáře k velmi odlišným přístupům ke stejné oblasti – zasílání zpráv mezi systémy se zprostředkujícím zprostředkovatelem. Podíváme se na tyto technologie od základu a zdůrazníme dopad různých designových voleb. Získáte hluboké porozumění oběma produktům, pochopíte, jak by se měly a neměly používat, a pochopíte, na co se zaměřit při zvažování dalších technologií zasílání zpráv v budoucnu.
Než začneme, pojďme si projít základy.
Co je to systém zpráv a proč je potřeba?
Aby spolu mohly dvě aplikace komunikovat, musí si nejprve definovat rozhraní. Definování tohoto rozhraní zahrnuje výběr přenosu nebo protokolu, jako je HTTP, MQTT nebo SMTP, a vyjednávání o formátech zpráv, které si budou systémy vyměňovat. Může se jednat o přísný proces, jako je definování schématu XML s požadavky na náklady na užitečné zatížení zprávy, nebo může být mnohem méně formální, jako je dohoda mezi dvěma vývojáři, že některá část požadavku HTTP bude obsahovat identifikátor klienta .
Pokud je formát zpráv a pořadí, v jakém jsou odesílány, mezi systémy konzistentní, mohou spolu komunikovat, aniž by se museli starat o implementaci druhého systému. Vnitřní části těchto systémů, jako je použitý programovací jazyk nebo framework, se mohou v průběhu času měnit. Dokud je zachována samotná smlouva, může interakce pokračovat beze změn z druhé strany. Tyto dva systémy jsou tímto rozhraním účinně odděleny (odděleny).
Systémy zasílání zpráv obvykle zahrnují prostředníka mezi dvěma systémy, které interagují za účelem dalšího oddělení (oddělení) odesílatele od příjemce nebo příjemců. V tomto případě systém zasílání zpráv umožňuje odesílateli odeslat zprávu, aniž by věděl, kde se příjemce nachází, zda je aktivní nebo kolik instancí existuje.
Podívejme se na několik analogií pro druhy problémů, které systém zasílání zpráv řeší, a zavedeme některé základní pojmy.
Bod-k-bod
Alexandra jde na poštu poslat Adamovi balíček. Přejde k oknu a předá zaměstnanci balíček. Zaměstnanec vyzvedne balíček a vydá Alexandre účtenku. Adam nemusí být doma, když je balíček odeslán. Alexandra je přesvědčena, že balíček bude Adamovi někdy v budoucnu doručen a může pokračovat ve své práci. Později v určitém okamžiku Adam obdrží balíček.
Toto je příklad modelu zasílání zpráv point-to-point. Pošta zde funguje jako mechanismus distribuce balíků a zajišťuje, že každý balík je doručen jednou. Použití pošty odděluje akt odeslání balíku od doručení balíku.
V klasických systémech zasílání zpráv je model point-to-point implementován prostřednictvím fronty. Fronta funguje jako vyrovnávací paměť FIFO (first in, first out), kterou si může předplatit jeden nebo více spotřebitelů. Každá zpráva je pouze doručena jednomu z přihlášených spotřebitelů. Fronty se obvykle snaží spravedlivě distribuovat zprávy mezi zákazníky. Tuto zprávu obdrží pouze jeden spotřebitel.
Termín „trvanlivý“ se používá pro fronty. Spolehlivost je vlastnost služby, která zajišťuje, že systém zasílání zpráv bude přetrvávat zprávy v nepřítomnosti aktivních účastníků, dokud se spotřebitel nepřihlásí do fronty pro doručování zpráv.
Spolehlivost je často zaměňována s vytrvalost a přestože se tyto dva termíny používají zaměnitelně, plní různé funkce. Perzistence určuje, zda systém zasílání zpráv zapisuje zprávu do nějakého úložiště mezi jejím přijetím a odesláním spotřebiteli. Zprávy odeslané do fronty mohou nebo nemusí být trvalé.
Zasílání zpráv z bodu do bodu se používá, když případ použití vyžaduje jednorázovou akci se zprávou. Mezi příklady patří vložení finančních prostředků na účet nebo dokončení objednávky dodávky. Později probereme, proč systém zasílání zpráv sám o sobě není schopen zajistit jednorázové doručení a proč fronty mohou v nejlepším případě poskytnout záruku doručení alespoň jednou.
Vydavatel-předplatitel
Gabriella vytočí číslo konference. Zatímco je připojena ke konferenci, slyší vše, co řečník říká, spolu se zbytkem účastníků hovoru. Když se naladí, unikne jí, co se říká. Když je znovu připojena, stále slyší, co se říká.
Toto je příklad modelu zasílání zpráv zveřejnit-předplatit. Konferenční hovor funguje jako vysílací mechanismus. Mluvící osobě je jedno, kolik lidí právě volá – systém zajišťuje, že kdokoli aktuálně připojený uslyší, co se právě říká.
V klasických systémech zasílání zpráv je model zasílání zpráv publikovat-předplatit implementován prostřednictvím vrcholy. Téma poskytuje stejnou metodu vysílání jako konferenční mechanismus. Když je zpráva odeslána k tématu, je distribuována pro všechny přihlášené uživatele.
Témata jsou obvykle nespolehlivý (netrvanlivý). Stejně jako posluchač, který neslyší, co se říká v konferenčním hovoru, když se posluchač odpojí, odběratelé tématu zmeškají všechny zprávy odeslané, když jsou offline. Z tohoto důvodu můžeme říci, že témata poskytují záruku doručení ne více než jednou pro každého spotřebitele.
Zprávy typu Publish-subscribe se obvykle používají, když jsou zprávy informační povahy a ztráta jedné zprávy není nijak zvlášť významná. Téma může například přenášet údaje o teplotě ze skupiny senzorů jednou za sekundu. Systém, který se zajímá o aktuální teplotu a který se přihlásí k tématu, si nebude dělat starosti, pokud mu nějaká zpráva unikne – v blízké budoucnosti dorazí další.
Hybridní modely
Webové stránky obchodu zařazují zprávy o objednávce do „fronty zpráv“. Hlavním konzumentem těchto zpráv je výkonný systém. Kromě toho by měl mít systém auditu kopie těchto zpráv o objednávce pro následné sledování. Oba systémy nemohou umožnit průchod zpráv, i když samotné systémy jsou nějakou dobu nedostupné. Web by si neměl být vědom jiných systémů.
Případy použití často vyžadují kombinaci modelů publikovat-předplatit a zasílání zpráv point-to-point, například když více systémů vyžaduje kopii zprávy a aby se zabránilo ztrátě zprávy, je vyžadována spolehlivost a stálost.
Tyto případy vyžadují cíl (obecný termín pro fronty a témata), který distribuuje zprávy v podstatě jako téma, takže každá zpráva je odeslána samostatnému systému, který se o tyto zprávy zajímá, ale také ve kterém může každý systém definovat několik spotřebitelů, kteří přijímají příchozí zprávy. zpráv, což je spíše fronta. Typ čtení v tomto případě je jednou pro každou zúčastněnou stranu. Tyto hybridní destinace často vyžadují trvanlivost, takže pokud spotřebitel přejde do režimu offline, zprávy odeslané v té době jsou přijaty poté, co se spotřebitel znovu připojí.
Hybridní modely nejsou nové a lze je použít ve většině systémů pro zasílání zpráv, včetně ActiveMQ (prostřednictvím virtuálních nebo složených destinací, které kombinují témata a fronty) a Kafka (implicitně jako základní vlastnost jeho návrhu destinací).
Nyní, když máme nějakou základní terminologii a rozumíme tomu, k čemu bychom mohli systém zasílání zpráv použít, pojďme se pustit do detailů.
Překlad hotový:
Následující přeložená část:
Chcete-li se pokračovat ...
Zdroj: www.habr.com