Message broker je software, který dovoluje, jak už název vypovídá, různým aplikacím či službám komunikovat a vyměňovat si mezi sebou informace. Tyto brokery využívají ke komunikaci různých protokolů (např. AMQP), což dovoluje aplikacím být na sobě nezávislé a komunikovat mezi sebou i přes to, že jsou napsány v různých jazycích či běží na rozdílných strojích.
Message brokery tvoří tzv. prostředníka mezi ostatními aplikacemi a poskytují možnost odeslat jakoukoliv zprávu bez nutné znalosti komu je zpráva odeslána, jestli a jak bude zpracována či kolik takových příjemců existuje.
Jednou z hlavních částí těchto brokerů je message queue, která ukládá a řadí příchozí zprávy, dokud je cílová aplikace není schopna přijmout. Zprávy si tedy zachovávají přesně takové pořadí, v jakém je zdrojová aplikace odeslala.
Jednou z implementací message brokera je RabbitMQ, který aktuálně podporuje několik komunikačních protokolů, jako například AMQP, MQTT, STOMP aj.
RabbitMQ je vysoce dostupný, škálovatelný a lze jej dostatečně nakonfigurovat ke splnění požadavků na službu. Též nabízí vlastní management rozhraní, díky kterému lze celého brokera ovládat či monitorovat. Pro práci s brokerem existují různé knihovny pro mnoho programovacích jazyků. My se budeme v dnešním článku zabývat hlavně komunikací přes samostatné queue a následně přes exchange.
Jako první si vysvětlíme jednotlivé pojmy, které budeme dále používat.
Pro názorovou ukázku dále uvažujme, že je naše aplikace rozdělena na jednotlivé mikroslužby, které musí mezi sebou komunikovat. Následně si proto popíšeme, jak by taková komunikace probíhala v případě využití právě queue a exchange.
Nejjednodušším způsobem komunikace je využití „holé“ fronty. Princip spočívá v tom, že jedna ze služeb (v tomto případě producer) vytvoří zprávu a odešle ji do fronty. Na stejnou frontu je napojená druhá služba (consumer), která čeká na jakoukoliv zprávu přijatou z této fronty, a tu poté zpracuje.
Samotné fronty lze různě konfigurovat. Můžeme například nastavit ukládání zpráv takovým způsobem, dokud některý z consumerů tuto zprávu neoznačí za přijatou, resp. zpracovanou. Tímto nastavením se vyvarujeme případné ztrátě zpráv v případě, kdy dojde k neočekávanému výpadku některé ze služeb.
Stejně tak, jako může do fronty posílat zprávy více producerů, může i více consumerů tyto zprávy zpracovávat. Na základě toho můžeme nastavit různá chování těchto consumerů.
Ať už jde o zpracování jedné zprávy odeslané do fronty všemi consumery nebo dále možnost mezi všechny consumery rozložit zátěž zpracování zpráv - tzn., že pokud první consumer již zprávu zpracovává a ve frontě se objeví zpráva další, je tato předána jinému volnému consumerovi.
Pokud nám komunikace za pomoci jednoduchých front nestačí, můžeme využít již zmíněných služeb exchange. Co si ale pod pojmem exchange představit?
V reálném světě jej lze přirovnat k často využívanému odběru novinek, které nabízí všemožné portály. Tzn. že my jako odběratelé se zavážeme k odběru těchto novinek na základě určitých preferencí. Následně dojde ke vzniku novinky s určitou povahou (typem), kterou portál (můžeme si jej představit jako producer) odešle na jiný server a dále neřeší, komu má jaký email odeslat. Tento server zastává tedy roli exchange a na základě našich preferencí (consumer preferencí) nám patřičné emaily rozešle.
Existuje několik typů exchange:
Cílem tohoto článku bylo se primárně seznámit s message brokery jako takovými, a také si přiblížit základní prvky implementace s RabbitMQ.
Samozřejmě způsobů, jak využít message brokery je mnoho. Proto se v dalším pokračování zaměříme na možnosti využití již zmiňovaného exchange, a přiblížíme si ještě o něco více právě užití typu topic.
Sledujte nás i nadále! 🙂
Zdroj: www.rabbitmq.com