Ahoj všichni!
Zahájil jsem překlad malé knihy:
««,
autor: Jakub Korab, vydavatelství: O’Reilly Media, Inc., datum vydání: červen 2017, ISBN: 9781492049296.
Z úvodu knihy:
«… Tato kniha vás naučí přemýšlet o systémech pro výměnu zpráv pomocí brokerů, přičemž porovná a kontrastuje dvě populární technologie brokerů: Apache ActiveMQ a Apache Kafka. Uvedeny budou příklady použití a podněty k vývoji, které vedly k tomu, že jejich vývojáři zvolili zcela odlišné přístupy k téže problematice – výměně zpráv mezi systémy pomocí mezikrokového brokera. Prozkoumáme tyto technologie od základů a vyzdvihneme vliv různých designových variant na této cestě. Získáte hluboké porozumění oběma produktům, vědění o tom, jak by měly a neměly být používány, a také chápání toho, na co byste měli dávat pozor při zvažování jiných technologií pro výměnu zpráv v budoucnosti. …»
Přeložené části do současné doby:
Budu zveřejňovat hotové kapitoly, jakmile je přeložím.
KAPITOLA 1
Úvod
Mezizávodní výměna zpráv je jednou z nejméně pochopených oblastí IT. Jako vývojář nebo architekt můžete být velmi dobře obeznámeni s různými frameworky a databázemi. Je však velmi pravděpodobné, že máte pouze letmé povědomí o tom, jak fungují technologie výměny zpráv založené na brokerech. Pokud se tak cítíte, nebojte se, nejste sami.
Lidé obvykle přicházejí do kontaktu s infrastrukturou pro výměnu zpráv velmi omezeně. Často se připojují k systému vytvořenému dávno, nebo stáhnou distribuci z internetu, nainstalují ji do PROMu a začnou pro ni psát kód. Po spuštění infrastruktury v PROMu mohou být výsledky nejasné: ztráta zpráv během selhání, odesílání nefunguje, jak byste očekávali, nebo brokery „visí“ vaše producenty nebo neodesílají zprávy vašim spotřebitelům.
Zní to povědomě?
Běžný scénář, kdy váš kód pro zprávu funguje skvěle, dokud najednou přestane. Toto období uspává bdělost a dává falešný pocit bezpečí, což vede k ještě většímu kódu založenému na mylných představách o základním chování technologie. Když se něco začne kazit, tváří v tvář se setkáváte s nepříjemnou pravdou: že jste ve skutečnosti pořádně nepochopili základní chování produktu nebo kompromisy, které autoři učinili, jako je poměr výkonu k spolehlivosti, nebo transakčnost versus horizontální škálovatelnost.
Bez hlubokého pochopení toho, jak fungují brokery, lidé dělají na první pohled rozumná tvrzení o jejich systémech zprávy, jako například:
- Systém nikdy neztratí zprávy
- Zprávy budou zpracovávány sekvenčně
- Přidání konzumentů zrychlí systém
- 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 jednoduše nepravdivá.
Tato kniha vás naučí přemýšlet o systémech zpráv založených na brokerech porovnáváním a kontrastováním dvou populárních brokerových technologií: Apache ActiveMQ a Apache Kafka. Budou zde uvedeny příklady použití a motivace k vývoji, které vedly jejich vývojáře k použití zcela odlišných přístupů ke stejné oblasti — výměně zpráv mezi systémy s prostředním brokerem. Podíváme se na tyto technologie od základů a zdůrazníme vliv různých návrhových možností na této cestě. Získáte hluboké pochopení obou produktů, to, jak by měly a neměly být používány, a pochopení toho, na co byste měli dávat pozor při zvažování jiných technologií zpráv v budoucnu.
Než začneme, projdeme si základy.
Co je to systém zpráv a k čemu slouží
Aby si dvě aplikace mohly vzájemně komunikovat, musí nejprve definovat rozhraní. Definice tohoto rozhraní zahrnuje výběr transportu nebo protokolu, jako je HTTP, MQTT nebo SMTP, a dohodu o formátech zpráv, kterými si budou systémy vyměňovat. Může to být přísný proces, jako je definice XML schématu s požadavky na zátěž (payload) zprávy, nebo to může být mnohem méně formální, například dohoda mezi dvěma vývojáři, že určitá část HTTP požadavku bude obsahovat identifikátor zákazníka.
Jakmile jsou formáty zpráv a pořadí jejich odesílání mezi systémy dohodnuty, budou moci vzájemně spolupracovat, aniž by se staraly o implementaci druhého systému. Vnitřnosti těchto systémů, jako je programovací jazyk nebo použitý framework, se mohou v průběhu času měnit. Dokud je zachována samotná smlouva, komunikace může pokračovat bez změny z druhé strany. Tyto dva systémy jsou tímto rozhraním efektivně odděleny.
Systémy pro výměnu zpráv obvykle zahrnují zprostředkovatele mezi dvěma systémy, které spolupracují, aby dále oddělily odesílatele od příjemce nebo příjemců. Systém výměny zpráv umožňuje odesílateli poslat zprávu, aniž by věděl, kde se příjemce nachází, zda je aktivní, nebo kolik jeho instancí existuje.
Podívejme se na pár analogií různých problémů, které se systém výměny zpráv snaží vyřešit, a zavádějme některé základní pojmy.
Point-to-Point
Alexandra jde na poštu, aby poslala Adamovi balíček. Přistoupí k okénku a předá zaměstnanci balíček. Zaměstnanec si balíček vezme a vydá Alexandře potvrzení. Adam nemusí být doma v okamžiku odeslání balíčku. Alexandra si je jistá, že balíček bude Adamovi doručen v nějakém budoucím okamžiku a může se i nadále věnovat svým záležitostem. Později v určitém okamžiku Adam balíček obdrží.
To je příklad modelu výměny zpráv point-to-point. Poštovní úřad zde funguje jako mechanismus distribuce balíčků, zajišťující, že každý balíček bude doručen jednou. Použití poštovního úřadu odděluje samotný akt odesílání balíčku od doručení balíčku.
V klasických systémech výměny zpráv je model „bod-bod“ realizován prostřednictvím čekání. Fronta funguje jako FIFO (první přišel, první odešel) vyrovnávací paměť, na kterou se může přihlásit jeden nebo více spotřebitelů. Každá zpráva je dodána pouze jednomu z přihlášených spotřebitelů. Fronty obvykle usilují o spravedlivé rozdělení zpráv mezi spotřebiteli. Pouze jeden spotřebitel obdrží danou zprávu.
Na fronty se vztahuje termín „spolehlivé“ („durable“). Spolehlivost — to je vlastnost služby, která zaručuje, že systém výměny zpráv uchovává zprávy v případě, že nejsou aktivní odběratelé, dokud se spotřebitel nepřihlásí k frontě pro dodání zpráv.
Spolehlivost se často zaměňuje s perzistencí a, i když se tyto dva termíny mohou zaměňovat, plní různé funkce. Perzistence určuje, zda systém výměny 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 odesílané do fronty mohou být nebo nemusí být perzistentní.
Výměna zpráv typu „Bod-bod“ se používá, když použití vyžaduje jednorázovou akci se zprávou. Příkladem může být například vložení prostředků na účet nebo zpracování objednávky na dodání. Později se podíváme na to, proč systém výměny zpráv sám o sobě není schopen zajistit jednorázové dodání a proč fronty mohou zaručit dodání v nejlepším případě alespoň jednou.
Publish-Subscribe
Gabriela vytáčí číslo konference. Dokud je připojená ke konferenci, slyší vše, co mluvčí říká, spolu s ostatními účastníky hovoru. Když se odpojí, propouští to, co bylo řečeno. Po opětovném připojení pokračuje ve slyšení toho, co lidé říkají.
To je příklad modelu výměny zpráv publikování-odběr. Konferenční hovor funguje jako vysílací mechanismus. Mluvčí se nestará o to, kolik lidí se aktuálně připojilo k hovoru - systém zajišťuje, že každý, kdo v daném okamžiku připojuje, uslyší to, co se říká.
V klasických systémech výměny zpráv je model výměny zpráv „publikování-odběr“ realizován prostřednictvím tématTéma poskytuje stejný způsob šíření jako mechanismus konference. Když je zpráva odeslána do tématu, je distribuována všem přihlášeným uživatelům.
Témata obvykle nejsou spolehlivá (nondurable). Stejně jako posluchač, který neslyší, co se říká na konferenčním hovoru, když se posluchač odpojí, předplatitelé tématu vynechávají jakékoli zprávy, které jsou odesílány v té době, kdy jsou offline. Z tohoto důvodu lze říci, že témata poskytují záruku doručení ne více než jednou pro každého spotřebitele.
Modely výměny zpráv typu „publikování-předplatné“ se obvykle používají, když jsou zprávy informativní a ztráta jedné zprávy není příliš významná. Například téma může přenášet teplotní údaje 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, se nebude obávat, pokud vynechá zprávu — další přijde brzy.
Hybridní modely
Webová stránka obchodu umisťuje zprávy o objednávkách do „fronty zpráv“. Hlavním spotřebitelem těchto zpráv je uskutečňovací systém. Navíc musí mít systém auditu kopie těchto zpráv o objednávkách pro následné sledování. Oba systémy nemohou vynechávat zprávy, i když jsou systémy nějakou dobu nedostupné. Webová stránka by neměla vědět o dalších systémech.
Případy použití často vyžadují kombinaci modelů výměny zpráv „publikování-předplatné“ a „point-to-point“, například když několika systémům je potřeba kopie zprávy a pro prevenci ztráty zprávy jsou zapotřebí jak spolehlivost, tak perzistence.
V těchto případech je zapotřebí adresát (destination) (obecný termín pro fronty a témata), který distribuuje zprávy většinou jako téma, takže každá zpráva je odeslána do jednotlivého systému, který má o tyto zprávy zájem, ale také každé systémy mohou definovat několik spotřebitelů, kteří přijímají příchozí zprávy, což je více podobné frontě. Typ čtení v tomto případě je jednou pro každou zainteresovanou stranu. Tyto hybridní adresáty často vyžadují spolehlivost (durability), takže pokud se zákazník odpojí, zprávy odeslané během tohoto období budou přijaty po opětovném připojení zákazníka.
Hybridní modely nejsou novinkou a lze je používat ve většině systémů pro výměnu zpráv, včetně ActiveMQ (pomocí virtuálních nebo složených adresátů, které kombinují témata a fronty) a také Kafka (implicitně, jako základní vlastnost návrhu jejího adresáta).
Teď, když máme nějakou základní terminologii a chápání toho, k čemu bychom mohli potřebovat systém výměny zpráv, pojďme se zaměřit na detaily.
Překlad byl proveden:
Následující překládaná část:
Pokračování příště…
Zdroj: habr.com
