Miért Rabbit? Mi az MQ? Hogyan javíthatja alkalmazásainkat? Miért érdemes többet megtudni róla? – Ezeket a kérdéseket tettem fel magamnak, amikor először találkoztam a RabbitMQ-val. Gábor vagyok, és most RabbitMQ mérnök és tanácsadó. A RabbitMQ-val való munkám során megtanultam, hogy még a tapasztalt ügyfelek is felteszik ezeket a kérdéseket.

TL;DR > Tekintse meg a RabbitMQ termékoldalunkat a felhasználási esetekkel, funkciókkal kapcsolatban, és vegye fel a kapcsolatot szakértő tanácsadóinkkal.

Milyen problémát old meg a RabbitMQ?

Mielőtt elmélyednénk abban, hogy mi is a RabbitMQ és hogyan kell használni, érdemes többet megtudni magáról a problématerületről. A különböző szolgáltatások (más néven számítógépek) közötti kommunikáció ősrégi probléma.

Egyrészt ott vannak a különböző protokollok, amelyek meghatározzák a szállítás módját és a kommunikáció tulajdonságait. Ilyen protokollok például az SMTP, az FTP, a HTTP vagy a WebSockets (hogy csak néhányat említsünk), amelyek mind a TCP/UDP-n alapulnak. Ezek a formázással, a megbízhatósággal és az üzenet megfelelő címzettjének megtalálásával foglalkoznak.

Másrészt az üzenet szempontjából is vizsgálhatjuk a kommunikációt. Létezik egy rendszerben, majd továbbítják egy másikba, átalakítják, vagyis van egy életciklusa. Miközben az egyik rendszerből a másikba utazik, tisztában kell lennünk azzal, hogy az üzenet hol van, és ki a tulajdonosa egy adott időpontban.

A fent említett kommunikációs protokollok gondoskodhatnak arról, hogy az üzenet tulajdonjoga (és “fizikai” helye) átkerüljön egyik rendszerből a másikba (bár ennek a tranzakciónak a végrehajtása eltarthat egy ideig). Az átadást tekinthetjük a két fél közötti tranzakciónak, amíg mindketten jelen vannak. Legtöbbször ez az aktív csere kívánatos, pl. ha a szolgáltatás állapotáról kérdezünk, és időszerű és pontos választ várunk. Egy példa a fizikai világból: felhívunk valakit telefonon:
1) elindítjuk a hívást,
2) megvárjuk, hogy a másik fél válaszoljon,
3) kellemes beszélgetést folytatunk,
4) letesszük a telefont.

De vannak más esetek is, amikor nincs szükségünk a válaszra, csak arra, hogy a vevő átvegye az üzenetet és elvégezze a feladatát. Ebben az esetben szükségünk van egy közvetítő ügynökre, egy másik rendszerre, amely (ideiglenesen) átveszi az üzenet tulajdonjogát, és gondoskodik arról, hogy az üzenet eljusson a célállomásra. Hogy a telefonos példát tovább feszegessük, a másik fél éppen nem elérhető, ezért hangüzenetet hagyunk. A hangposta szolgáltatás értesíti a címzettet.

Ezt az aszinkron (késleltetett) üzenetkézbesítést biztosítja a RabbitMQ. Nyilvánvalóan többre képes, mint egy egyszerű üzenetrögzítő, ezért az alábbiakban vizsgáljunk meg néhányat az általa nyújtott lehetőségek közül

(Ha többet szeretne megtudni a RabbitMQ történetéről, akkor Alvaro Videla és Jason Williams “RabbitMQ in Action” című könyvének első fejezetét ajánlom. Ebből kiderül a válasz arra, hogy miért a nyulakról kapta a nevét).

A RabbitMQ egy ingyenes, nyílt forráskódú és bővíthető üzenetvárakozási megoldás. Ez egy üzenetközvetítő, amely érti az AMQP-t (Advanced Message Queuing Protocol), de más népszerű üzenetküldő megoldásokkal, például az MQTT-vel is használható. Nagymértékben elérhető, hibatűrő és skálázható. Erlang OTP-ben van implementálva, egy olyan technológiában, amelyet olyan stabil, megbízható, hibatűrő és nagymértékben skálázható rendszerek építésére szabtak, amelyek natívan képesek nagyon nagy számú egyidejű művelet kezelésére, mint például a RabbitMQ és más rendszerek, mint a WhatsApp, MongooseIM, hogy csak néhányat említsünk.

Nagyon magas szinten ez egy middleware réteg, amely lehetővé teszi, hogy az alkalmazás különböző szolgáltatásai kommunikáljanak egymással anélkül, hogy az üzenetvesztés miatt aggódnának, miközben különböző szolgáltatásminőségi (QoS) követelményeket biztosít. Lehetővé teszi továbbá az alkalmazások széles körű szétválasztását lehetővé tevő finom szemcsés és hatékony üzenetirányítást.

Használati esetek

A RabbitMQ sokoldalúságának bemutatásához három esettanulmányt fogunk használni, amelyek bemutatják, hogy a RabbitMQ jól használható black-box menedzselt szolgáltatási megközelítésként, az alkalmazással szorosan integrálódó, jól működő mikroszolgáltatás-architektúrát lehetővé tevő alkalmazásként vagy más örökölt projektek átjárójaként.

RabbitMQ mint általános üzenetbusz

Amikor egy monolit rendszert különálló alrendszerekre bontunk, az egyik legnagyobb megoldandó probléma az, hogy milyen kommunikációs technológiát használjunk. Egy olyan megoldás, mint a Mulesoft, vagy a MassTransit a HTTP listenerek és senderek deklarálásával tudja “bekábelezni” a szolgáltatásokat. Ez a fajta megoldás a RabbitMQ-t fekete dobozként kezeli, mégis képes kihasználni a RabbitMQ képességeit. A közvetlen kommunikáció példájaként használjuk a HTTP-t az egyes szolgáltatások “összekapcsolására”. Bár ez egy jól támogatott és megbízható választás, van néhány hátránya:
1) A szolgáltatások felderítése nem megoldott. Egy lehetséges megoldás a DNS használata. Ahogy a rendszer skálázódik és növekszik, úgy válik egyre bonyolultabbá ennek a terhelésnek a megtalálása és kiegyensúlyozása. A RabbitMQ enyhítheti a megoldás megnövekedett bonyolultságát.
2) A kommunikáció efemer. Az üzenetek hajlamosak arra, hogy a hálózati rétegen megszakadnak vagy duplikálódnak. Ha egy szolgáltatás átmenetileg nem érhető el, a kézbesítés meghiúsul.

A RabbitMQ mindkét esetben segíthet az üzenetvárólisták mint szállítási eszköz felhasználásával. A szolgáltatások közzétehetnek és fogyaszthatnak üzeneteket, ami függetleníti a végponttól végpontig tartó üzenetkézbesítést a célszolgáltatás elérhetőségétől. Ha egy fogyasztó szolgáltatás átmenetileg nem érhető el, a HTTP-vel ellentétben az üzenetet a RabbitMQ biztonságosan puffereli és megőrzi, majd végül kézbesíti, amikor a szolgáltatás ismét online lesz.

A felfedezhetőség is egyszerűsödik. Csak annyit kell tudnunk, hogy hol van a RabbitMQ és mi a várólista neve. Bár úgy tűnik, hogy ez csak újra feltalálja a problémát, ez skálázható. A várólista neve a szolgáltatás címeként funkcionál. Az egyes szolgáltatások által a várólistákból származó üzenetek fogyasztása a skálázhatóság eszközét kínálja, azaz minden várólista több fogyasztót is kiszolgálhat, és kiegyenlítheti a terhelést. Nincs szükség a szolgáltatásokba már beépített várólista-konfiguráció megváltoztatására.

Ez a mérsékelten statikus várólista-konfiguráció a RabbitMQ-t egy olyan middleware rétegbe tolja, ahol a szilárd tervezés hosszú távon garantálhatja a stabil szolgáltatásminőséget.

RabbitMQ mint a mikroszolgáltatások fejlett útválasztási rétege

A spektrum másik végén egy olyan architektúra áll, amely folyékonyabb, és alkalmazkodik a sok mikroszolgáltatás folyamatosan változó igényeihez. Ami a RabbitMQ-t ebben a környezetben ragyogóvá teszi, az az általa biztosított nagyon hatékony útválasztási képességek.

Az útválasztási logika különböző (úgynevezett) cseretípusokban van megvalósítva, amelyeket az alkalmazás szükség esetén dinamikusan létrehozhat. A célszolgáltatások létrehozzák azokat a várólistákat, amelyekből fogyasztani kívánnak, majd a cserékhez kötik őket azáltal, hogy megadnak egy mintát a kulcsokra, amelyeket a kiadók használhatnak az üzenet publikálásakor. (Gondoljunk ezekre a kulcsokra úgy, mint metaadatokra, amelyeket a csereprogramok felhasználhatnak az üzenetek egy vagy több várólistára történő továbbítására és kézbesítésére.)

A továbbítási logika különböző (úgynevezett) csereprogramtípusokban van megvalósítva, amelyeket az alkalmazás szükség esetén dinamikusan létrehozhat. A célszolgáltatások létrehozzák azokat a várólistákat, amelyekből fogyasztani kívánnak, majd a cserékhez kötik őket azáltal, hogy megadnak egy mintát a kulcsokra, amelyeket a kiadók az üzenet közzétételekor használhatnak. (Gondoljon ezekre a kulcsokra úgy, mint metaadatokra, amelyeket a csereprogramok felhasználhatnak az üzenetek egy vagy több várólistára történő továbbítására és kézbesítésére.)

A RabbitMQ négy hasznos csereprogramtípussal rendelkezik, amelyek az üzenetküldés legtöbb felhasználási esetét lefedik:
1) Közvetlen csereprogram. Ez a bejövő üzenetet bármelyik várólistára eljuttatja, amelynek kötési kulcsa pontosan megegyezik az üzenet útválasztási kulcsával. Ha a várólistákat a várólista nevével köti össze, mint útválasztási kulcsokkal, akkor úgy gondolhatunk erre, mint egy-egy üzenet kézbesítésére. Egyszerű ugyanazt az üzenetet több várólistára kézbesíteni, ha több várólista kötési kulcsait használjuk.
2) Témacsere. Ez a bejövő üzenetet bármelyik várólistának kézbesíti, amelynek joker kötési kulcsa megegyezik a közzétett üzenet útválasztási kulcsával. A kötési kulcsok tartalmazhatnak egy összetett útválasztási kulcshoz tartozó vadkártyás megfeleltetési kritériumokat. (pl. a logs.*.error kötési kulcs megfelel a logs.accounting.error és logs.ui.error útválasztási kulcsoknak). Ez lehetővé teszi, hogy olyan egyszerű szolgáltatásokat írjunk, ahol a logika jól el van zárva, és az üzenet a RabbitMQ “varázslatán” keresztül a megfelelő szolgáltatásokhoz fog eljutni.
3) Fanout csere. Néhány üzenetet minden várólistára el kell juttatni, itt a fanout exchange használható ahelyett, hogy bonyolult multicast logikát írnánk az alkalmazásba. A RabbitMQ fanout exchange segítségével minden egyes szolgáltatás a megfelelő várólistát köti a cseréhez anélkül, hogy kötési kulcsot kellene megadni, és az egész automatikusan történik. Ha meg van adva egy kötési kulcs, a fanout exchange egyszerűen figyelmen kívül hagyja azt, és továbbra is továbbítja/közvetíti az üzeneteket az összes hozzá kötött várólistához.
4) Fejlécek cseréje. Ez a csere kihasználja az AMQP-üzenetek szerkezetét, és képes összetett útválasztásra az AMQP-üzenet fejlécei (beleértve az egyéni fejléceket is) alapján. A fejlécek az AMQP-n keresztül küldött minden egyes üzenethez csatolt metaadatok.

A cseréken kívül a RabbitMQ-ban vannak más hasznos funkciók is, amelyek nagyon összetett üzenetküldési logika megvalósítását teszik lehetővé. Néhány a legfontosabb funkciók közül:
1) Egyéni bővítmények. A RabbitMQ bővíthető azáltal, hogy lehetővé teszi a felhasználók számára, hogy bővítményeket adjanak hozzá. A RabbitMQ szinte minden aspektusa testre szabható, beleértve a kezelést, a hitelesítést és engedélyezést, a biztonsági megoldásokat és a klaszterezést.
2) Klaszterezés. Ha egyetlen RabbitMQ szerver nem elegendő, több RabbitMQ bróker csatlakoztatható, hogy együtt dolgozzanak és skálázzák a rendszert. Ez lehetővé teheti a RabbitMQ számára, hogy több üzenetet dolgozzon fel, vagy növelheti a hibákkal szembeni ellenálló képességet.
3) A szolgáltatásminőség hangolása. Az időérzékeny üzenetek kézbesítését segítheti egy TTL (Time-to-Live) érték hozzáadása akár az üzenethez, akár a várólistához. Az időzített üzenetek automatikusan kézbesíthetők egy Dead-letter várólistára. A szokásos útválasztási logika és ezen extra funkciók kombinálásával rendkívül fejlett útválasztási logikát lehet létrehozni. Egy másik hasznos funkció a prioritási várólisták használata, ahol a kiadó minden üzenethez hozzárendelhet egy prioritási szintet. Lehetőség van a vissza nem fogadott üzenetek számának korlátozására is, ami lehetővé teszi a fogyasztó szolgáltatások teljesítményének hangolását, ebben az esetben a RabbitMQ egy back-pressure mechanizmust alkalmaz.

RabbitMQ integrálva a régi rendszerekbe

Az előző használati példában említettem a RabbitMQ funkcionalitásának bővítésére szolgáló plug-inek használatának lehetőségét. Ez az erőteljes funkció lehetővé teszi, hogy a RabbitMQ közvetítő rétegként működjön a RabbitMQ natív (AMQP-képes) szolgáltatásai és más örökölt alkalmazások között. Néhány figyelemre méltó példa:
1) A RabbitMQ használata MQTT brókerként egy plug-in egyszerű engedélyezésével. Ez számos IoT-technológia előtt nyitja meg a terepet.
2) A RabbitMQ JMS (Java Message Service) plug-inje, amely lehetővé teszi, hogy a RabbitMQ bármilyen JMS-képes üzenetküldő megoldással kommunikáljon.
3) Ha az alkalmazás saját protokollt használ a kommunikációhoz, lehetőség van egy egyéni plugin kifejlesztésére, amely bármilyen ilyen szolgáltatáshoz csatlakozik.

Következtetés

Amint a fenti példák is mutatják, alig van olyan, amivel a RabbitMQ nem tud kommunikálni. De mint mindennek az életben, ennek is ára van. Bár a RabbitMQ konfigurálása többnyire egyszerű, néha a funkciók puszta száma is nyomasztó lehet. Ha bármilyen problémával szembesül a RabbitMQ-brókerek tervezésével, megvalósításával vagy támogatásával kapcsolatban, forduljon szakértői csapatunkhoz itt. Vagy ha szeretné beindítani karrierjét az egyik legkeresettebb technológiában, iratkozzon fel 3 napos RabbitMQ tanfolyamunkra.

Debugging RabbitMQ

Intuitív rendszert szeretne, amely megkönnyíti a RabbitMQ felügyeletét és karbantartását? Szerezze be a WombatOAM 45 napos ingyenes próbaverzióját most.

A RabbitMQ képességeink oldal