Co je RabbitMQ?
V jakékoli aplikaci nativní pro cloud musí mikroslužby komunikovat, aby získaly všechny informace, které potřebují k reakci na uživatele. Měli byste se ujistit, že je toto zasílání zpráv robustní i v případě problémů se sítí nebo selhání mezi integracemi. RabbitMQ je jeden nástroj, který můžete použít ke zvýšení spolehlivosti zasílání zpráv.
Ve svém prodejci venkovních zařízení provádíte rychlý pokrok s mikroslužbami. Při testování některých volání z jedné mikroslužby na jinou se však zdá, že při testování aplikace dojde ke ztrátě. Chcete zajistit, aby tento problém nevznikl ve vašem produkčním prostředí, kde je v sázce pověst vaší společnosti.
V této lekci se dozvíte, jak RabbitMQ může vytvořit flexibilní a odolnou komunikační platformu pro mikroslužby.
Proč používat zprostředkovatele zpráv v aplikaci nativní pro cloud?
Nativní cloudové aplikace se skládají z nezávislých mikroslužeb, které často vytvářejí samostatné týmy a používají různé technologie a jazyky. Každý tým má vlastní vývojové sprinty a plány upgradu a může průběžně nasazovat opravy a nové funkce. Když ale požadavek přijde od uživatele, mikroslužba, která ji obdrží, musí téměř vždy volat jiné mikroslužby a backing služeb a přijímat odpovědi, aby formulovala úplnou odpověď.
Samozřejmě, že formát a schéma těchto žádostí a odpovědí mezi službami musí být dohodnuty mezi vývojovými týmy a zřídka se mění. Obvykle se implementují jako rozhraní REST API. Měli byste přednostně implementovat nové funkce každého rozhraní beze změny stávajících metod a parametrů. Pokud se ale rozhodnete, že mikroslužby komunikují přímo, může nastat několik problémů:
- Když je cílová mikroslužba offline nebo zaneprázdněná, co se stane se zprávami odeslaných do ní? Jaké jsou důsledky ztráty zpráv?
- Jak můžete stejnou zprávu odeslat do více než jednoho cíle?
- Pokud je mikroslužba spuštěná ve více než jednom kontejneru, do kterého byste měli odesílat zprávy?
Zprostředkovatel zpráv je middleware, který tyto problémy řeší. Služby odesílají zprávy do zprostředkovatele zpráv místo přímo do cíle. Zprostředkovatel je ukládá do front v pořadí, ve kterém dorazí. Cílové služby se přihlásí k odběru těchto front a vyzvednou zprávy pro zpracování po jednom.
Pokud je cílová služba nedostupná, může odesílající mikroslužba zprávy pořád umístit do fronty. Když se cíl restartuje, bude pokračovat ve vyzvednutí zpráv z fronty ze stejného bodu. Neztratí se žádné zprávy, i když odesílatel musí čekat déle.
Vzhledem k tomu, že více než jeden cíl se může přihlásit k odběru fronty, může jedna zpráva přijímat více než jedna mikroslužba. Kromě toho, když několik kontejnerů hostuje instance jedné mikroslužby, první instance, která bude k dispozici, převezme zprávu. Zprostředkovatel automaticky distribuuje zprávy do instancí, aby se zatížení rozložilo.
Co je RabbitMQ?
RabbitMQ je jedním z nejoblíbenějších zprostředkovatelů zpráv a má mnoho funkcí, díky kterým je ideálním kandidátem na zpracování komunikace v aplikaci nativní pro cloud. Patří mezi ně:
- Server RabbitMQ, který hostuje fronty. Server podporuje clustering a převzetí služeb při selhání pro zajištění vysoké dostupnosti a může běžet v kontejnerech.
- Implementace protokolu AMQP (Advanced Message Queuing Protocol), protokolu STOMP (Simple Text Oriented Message Protocol) a přenosu telemetrie front zpráv (MQTT).
- Klientské knihovny AMQP, které můžete použít v .NET, Javě a Erlangu.
Koncepty RabbitMQ
Ve výrazech RabbitMQ jsou vaše mikroslužby, které odesílají a přijímají zprávy, klienty. Klienti, kteří odesílají zprávy, se označují jako producenti zpráv. Klienti, kteří přijímají zprávy, jsou příjemci zpráv. Služba RabbitMQ je zprostředkovatel zpráv.
Jak odesílat zprávy
RabbitMQ je všestranný a schopný implementovat mnoho různých modelů řazení do fronty. Pojďme se podívat na některé oblíbené vzory.
Pokud máte jednoho producenta a jednoho příjemce, použijete jednu frontu a všechny zprávy se dostanou do stejného cíle. I v této jednoduché konfiguraci vytvoříte robustní systém zasílání zpráv, který hladce zpracovává výpadky:
Odesílání zpráv konkurenčním příjemcům
V modelu konkurenčních příjemců odesílá producent zprávy do jedné pracovní fronty. Dva nebo více příjemců načítají zprávy z fronty. Příjemci soupeří o načtení zpráv, protože každou zprávu může načíst pouze jeden příjemce.
Tento model je užitečný v aplikacích nativních pro cloud, pokud máte spotřebovává mikroslužby hostované na více kontejnerech, abyste zvýšili kapacitu. Každá zpráva bude mít přístup pouze k jedné instanci příjemce, takže bude zpracována pouze jednou. Práce nebude duplikována.
Publikování a přihlášení k odběru
Pokud chcete odeslat jednu zprávu od producenta více příjemcům, použijte model publikování/přihlášení k odběru. Producent odesílá zprávy na výměnu. Každý příjemce se přihlásí k odběru zpráv z této výměny. Když se přihlásí k odběru, RabbitMQ pro toto předplatné vytvoří novou pracovní frontu. Každá zpráva se zkopíruje do každé fronty pro danou výměnu a obdrží ji každý příjemce, který se přihlásil k odběru. Uživatelé nekonkurují pro každou zprávu. Místo toho všichni dostanou kopii každé zprávy.
Model publikování/odběru používá fanout exchange, který kopíruje každou zprávu do každé pracovní fronty.
Tento vzor je užitečný, když chcete, aby každá zpráva byla zpracována více mikroslužbami. Když si například zákazník koupí košík, můžete chtít poslat zprávu o počtu zakoupených produktů. Tato zpráva by se měla spojit s expediční mikroslužbou, dát skladu pokyn k zabalení balíku a skladové mikroslužby, k dekrementování skladových zásob a k aktivaci objednávek dodavatelům.
Směrování zpráv a témat
Někdy chcete distribuovat jednotlivé zprávy více příjemcům, ale pro každého příjemce použijte filtr. Tento vzor se nazývá směrovač zpráv. Stejně jako v modelu publikování nebo odběru se uživatelé přihlásí k odběru výměny, aby vytvořili více pracovních front. Místo fanout výměny však model používá přímou výměnu. S touto výměnou má každé předplatné klíč vazby. Do tohoto předplatného se odesílají jenom zprávy, jejichž směrovací klíč odpovídá klíči vazby. Ostatní jsou odfiltrované.
Tento model je užitečný, když někteří uživatelé by měli zpracovat pouze podmnožinu datového proudu zpráv. Předpokládejme například, že máte mikroslužbu, která odesílá zprávy, když dojde k chybám. Všechny chyby by se měly odesílat do mikroslužby protokolování. Do mikroslužby pro správu by se měly odeslat kritické chyby, které budou inženýři upozorňovat na opravu problému.
Přímá výměna směruje zprávy na základě jednoho kritéria. Pokud chcete, aby byly věci ještě flexibilnější, můžete použít výměnu témat . Pro každou zprávu můžete použít směrovací klíč s více termíny oddělenými tečkami. V klíči vazby můžete použít zástupné znaky *, nahradit přesně jedno slovo, nebo # nahradit nula nebo více slov.
Poznámka:
Alternativy k RabbitMQ zahrnují Apache Kafka a Azure Service Bus. Obě tyto zprostředkovatelé zpráv jsou podporovány vyhrazenými integracemi v .NET Aspire. O službě Azure Service Bus se dozvíte v pozdějším modulu tohoto studijního programu.