Top 6 frontových systémů pro backendové vývojáře

Hledáte systém řazení do front? Nebo možná hledáte lepší? Zde jsou všechny potřebné informace!

Systémy front jsou nejlépe střeženým tajemstvím vývoje backendu.

Aniž bych se pokoušel básnit chválu frontových systémů, řekl bych, že junior backendový vývojář se stane backendovým vývojářem střední úrovně poté, co se naučí integrovat fronty do systému. Fronty zlepšují zákaznickou zkušenost (uvidíme jak), snižují složitost a zlepšují spolehlivost systému.

Jistě, pro velmi jednoduché webové aplikace s téměř nulovým provozem a brožurové weby mohou být fronty celkově (nebo dokonce nemožné je nainstalovat, pokud jste v typickém prostředí sdíleného hostování), ale netriviální aplikace budou mít z fronty prospěch. systémy a velké aplikace nejsou možné bez zapojení do fronty.

Než začneme, zřeknutí se odpovědnosti: pokud jste již spokojeni se systémy řazení do fronty a chcete porovnat různé možnosti, několik následujících úvodních částí vám navodí velký spánek. 🙂 Takže klidně skočte dopředu. Úvodní sekce jsou určeny pro ty, kteří mají o systémech řazení jen mlhavou představu nebo jen zběžně zaslechli název.

Co je to systém řazení do front?

Začněme tím, že pochopíme, co je to fronta.

Fronta je datová struktura v informatice, která napodobuje fronty v reálném světě, které vidíme kolem sebe. Pokud jdete například k pokladní přepážce, všimnete si, že budete muset stát na konci fronty, zatímco osoba na začátku fronty dostane lístek jako první. Tomu také říkáme fenomén „kdo dřív přijde, ten dřív mele“. V informatice je možné psát programy, které ukládají své úkoly takto do fronty a zpracovávají je jeden po druhém na stejném principu „kdo dřív přijde, je dřív na řadě“.

Všimněte si, že fronta sama žádné skutečné zpracování neprovádí. Je to jen takové dočasné úložiště, kde úkoly čekají, dokud je něco nechytne. Pokud to všechno zní příliš abstraktně, nebojte se. Je to abstraktní pojem, ale v další části uvidíme jasné příklady. 🙂

Proč potřebujete systémy řazení?

Aniž bych se pouštěl do velmi zdlouhavého popisu, řekl bych, že hlavní potřeba systémů řazení do front je kvůli zpracování na pozadí, paralelnímu spouštění a obnově po selhání. Podívejme se na ně pomocí příkladů:

Zpracování pozadí

Předpokládejme, že provozujete marketingovou kampaň elektronického obchodu, kde čas hraje hlavní roli, a že vaše aplikace je postavena tak, že odešle potvrzovací e-mail těsně předtím, než zákazník dokončí platbu, a zobrazí se stránka s poděkováním. Pokud je e-mailový server, ke kterému se připojujete, mimo provoz, webová stránka prostě zmizí a naruší uživatelský dojem.

Představte si ten vysoký počet žádostí o podporu, které byste dostávali! V tomto případě je lepší přesunout tento úkol odeslání e-mailu do fronty úloh a ukázat zákazníkovi stránku úspěchu.

Paralelní provedení

Mnoho vývojářů, zejména těch, kteří většinou kódují jednodušší aplikace s nízkým provozem, má ve zvyku používat úlohy cron pro zpracování na pozadí. To je v pořádku, dokud velikost vstupu nezvětší natolik, že jej nelze vymazat. Předpokládejme například, že máte úlohu cron, která kompiluje analytické zprávy a posílá je uživatelům e-mailem, a že váš systém dokáže zpracovat 100 zpráv za minutu.

Jakmile vaše aplikace poroste a začne dostávat v průměru více než 100 požadavků za minutu, začne stále více zaostávat a nikdy nebude schopna dokončit všechny úlohy.

V systému řazení do front lze této situaci předejít nastavením více pracovníků, z nichž každý může vybrat úlohu (každý obsahuje 100 zpráv, které mají být provedeny) a pracovat paralelně, aby úlohu dokončili mnohem, mnohem dříve.

Zotavení ze selhání

Jako weboví vývojáři obecně nemyslíme na neúspěch. Považujeme za samozřejmé, že naše servery a API, která používáme, budou vždy online. Skutečnost je však jiná – výpadky sítě jsou příliš časté a vynikající API, na která se spoléháte, mohou být mimo provoz kvůli problémům s infrastrukturou (než řeknete „ne já!“, nezapomeňte na masivní výpadek Amazonu S3). Když se tedy vrátíme k příkladu přehledů, pokud část generování přehledu vyžaduje, abyste se připojili k rozhraní API pro platby a toto připojení je na 2 minuty mimo provoz, co se stane s 200 přehledy, které selhaly?

Systémy řazení do front však vyžadují značnou režii. Křivka učení je poměrně strmá, protože vstupujete do zcela nové domény, zvyšuje se složitost vaší aplikace a nasazení a úlohy ve frontě nelze vždy ovládat se 100% přesností. To znamená, že existují situace, kdy vytvoření aplikace bez front prostě není možné.

S tím mimo, pojďme se podívat na některé běžné možnosti mezi dnešními backendy/systémy ve frontě.

Redis

Redis je známý jako úložiště párů klíč–hodnota, které pouze ukládá, aktualizuje a získává řetězce dat bez znalosti struktury dat. I když to možná dříve platilo, dnes má Redis efektivní a velmi užitečné datové struktury, jako jsou seznamy, tříděné sady a dokonce i systém Pub-Sub, díky čemuž je vysoce žádoucí pro implementace front.

Výhody Redis jsou:

• Zcela v paměti databáze, což vede k rychlejšímu čtení/zápisu.
• Vysoce efektivní: Snadno podporuje více než 100 000 operací čtení/zápisu za sekundu.
• Vysoce flexibilní schéma perzistence. Můžete buď dosáhnout maximálního výkonu za cenu možné ztráty dat v případě selhání, nebo nastavit v plně konzervativním režimu a obětovat výkon kvůli konzistenci.
• Clustery jsou podporovány ihned po vybalení

Vezměte prosím na vědomí, že Redis nemá žádné abstrakce zasílání zpráv/řazení do fronty/obnovy, takže buď musíte použít balíček, nebo si sami vytvořit odlehčený systém. Příkladem je, že Redis je výchozím backendem fronty pro framework Laravel PHP, kde byl autory frameworku implementován plánovač.

Učení Redis je lehké.

RabbitMQ

Existuje několik jemných rozdílů mezi Redis a RabbitMQtak je nejprve odhodíme z cesty.

Za prvé, RabbitMQ má více specializovanou, dobře definovanou roli, a proto byl postaven tak, aby to odrážel – zasílání zpráv. Jinými slovy, jeho sladkou tečkou je fungovat jako prostředník mezi dvěma systémy, což není případ Redis, který funguje jako databáze. Výsledkem je, že RabbitMQ poskytuje několik dalších funkcí, které v Redis chybí: směrování zpráv, opakování, distribuce zátěže atd.

Pokud se nad tím zamyslíte, fronty úloh lze také považovat za systém zasílání zpráv, kde plánovač, pracovníci a „zadavatelé“ úloh mohou být považováni za entity účastnící se předávání zpráv.

RabbitMQ má následující výhody:

• Lepší abstrakce pro předávání zpráv, snížení práce na úrovni aplikace, pokud je předávání zpráv to, co potřebujete.
• Odolnější vůči výpadkům a výpadkům napájení (než Redis, alespoň ve výchozím nastavení).
• Podpora klastrů a federací pro distribuovaná nasazení.
• Užitečné nástroje pro správu a monitorování vašich nasazení.
• Podpora prakticky všech netriviálních programovacích jazyků.
• Nasazení s vámi zvoleným nástrojem (Docker, Chef, Puppet atd.).

Kdy použít RabbitMQ? Řekl bych, že je to skvělá volba, když víte, že potřebujete použít asynchronní předávání zpráv, ale nejste připraveni řešit obrovskou složitost některých dalších možností řazení do fronty v tomto seznamu (viz níže).

ActiveMQ

Pokud jste v podnikovém prostoru (nebo vytváříte vysoce distribuovanou a rozsáhlou aplikaci) a nechcete neustále znovu vymýšlet kolo (a dělat přitom chyby), ActiveMQ stojí za shlédnutí.

Zde ActiveMQ exceluje:

• Je implementován v Javě, a tak má opravdu úhlednou integraci Java (dodržuje standard JMS).
• Podporováno více protokolů: AMQP, MQTT, STOMP, OpenWire atd.
• Zabývá se zabezpečením, směrováním, vypršením platnosti zpráv, analýzou atd. ihned po vybalení.
• Zapečená podpora oblíbených vzorů distribuovaných zpráv, která vám šetří čas a nákladné chyby.

To neznamená, že ActiveMQ je k dispozici pouze pro Javu. Má klienty pro Python, C/C++, Node, .Net a další ekosystémy, takže by neměly být obavy z možného kolapsu v budoucnu. Kromě toho je ActiveMQ postaven na zcela otevřených standardech a vytváření vlastních odlehčených klientů by mělo být snadné.

Vše, co bylo řečeno a uděláno, mějte prosím na paměti, že ActiveMQ je pouze broker a nezahrnuje backend. K ukládání zpráv budete stále muset použít jeden z podporovaných backendů. Zahrnul jsem to sem, protože to není vázáno na konkrétní programovací jazyk (jako jiná populární řešení jako Celery, Sidekiq atd.)

Amazon MQ

Amazon MQ si zde zaslouží rychlou, ale důležitou zmínku. Pokud si myslíte, že ActiveMQ je ideálním řešením pro vaše potřeby, ale nechcete se zabývat budováním a údržbou infrastruktury sami, Amazon MQ k tomu nabízí spravovanou službu. Podporuje všechny protokoly, které ActiveMQ dělá – ve funkcích není žádný rozdíl – protože pod povrchem používá samotný ActiveMQ.

Výhodou je, že jde o řízenou službu, takže se nemusíte starat o nic jiného než o její používání. To dává ještě větší smysl pro nasazení, která jsou na AWS, protože můžete využít další služby a nabídky přímo z vašeho nasazení (například rychlejší přenosy dat).

Amazon SQS

Nemůžeme očekávat, že Amazon bude tiše sedět, pokud jde o části kritické infrastruktury, že? 🙂

A tak to máme Amazon SQS, což je plně hostovaná, jednoduchá frontová služba (doslova) od známého giganta AWS. Ještě jednou, jemné rozdíly jsou důležité, takže mějte na paměti, že SQS nemá koncept předávání zpráv. Stejně jako Redis je to jednoduchý backend pro přijímání a distribuci úloh ve frontách.

Kdy byste tedy chtěli používat Amazon SQS? Zde je několik důvodů:

• Jste fanouškem AWS a nebudete se ničeho jiného dotýkat (upřímně řečeno, takových lidí je tam mnoho a myslím, že na tom není nic špatného).
• Potřebujete hostované řešení, abyste zajistili, že míra selhání je nulová a žádná z úloh nebude ztracena.
• Nechcete vytvářet klastr a musíte jej sami sledovat. Nebo ještě hůř, musíte vytvořit monitorovací nástroje, když byste ten čas mohli využít k produktivnímu vývoji.
• Již máte značné investice do platformy AWS a zůstat uzavřený dává obchodní smysl.
• Chcete cílený, jednoduchý systém řazení do front bez jakýchkoli zbytečností spojených s předáváním zpráv, protokoly a podobně.

Celkově vzato je Amazon SQS solidní volbou pro každého, kdo chce do svého systému začlenit fronty úloh a nemusí se starat o instalaci/monitorování věcí sám.

Beanstalkd

Beanstalkd existuje již dlouhou dobu a je to bitvami testovaný, rychlý a snadný backend pro řazení úloh. Existuje několik vlastností Beanstalkd, díky kterým se výrazně liší od Redis:

• Je to striktně systém řazení do fronty a nic jiného. Posouváte do něj pracovní místa, která později přitáhnou zaměstnanci. Pokud tedy vaše aplikace potřebuje byť jen nepatrnou potřebu předávání zpráv, měli byste se Beanstalkd vyhnout.
• Neexistují žádné pokročilé datové struktury, jako jsou sady, prioritní fronty atd.
• Beanstalkd je to, co se nazývá fronta First In, First Out (FIFO). Neexistuje způsob, jak seřadit úlohy podle priority.
• Neexistují žádné možnosti pro shlukování.

To vše znamená, že Beanstalkd vytváří úhledný a rychlý systém front pro jednoduché projekty, které žijí na jediném serveru. Pro mnohé je rychlejší a stabilnější než Redis. Takže pokud máte problémy Beanstalkd s Redisem, který prostě nemůžete vyřešit, ať se děje cokoliv, a vaše potřeby jsou jednoduché, Beanstalkd stojí za vyzkoušení.

Závěr

Pokud jste dočetli až sem (nebo se dostali sem k rychlému čtení 😉 ), je docela velká šance, že vás systémy řazení do fronty zajímají nebo je potřebujete. Pokud ano, seznam na této stránce vám dobře poslouží, pokud nehledáte systém fronty specifický pro jazyk/rámec.

Kéž bych vám mohl říct, že řazení do fronty je jednoduché a 100% spolehlivé, ale není. Je to chaotické, a protože je to všechno v pozadí a děje se to velmi rychle (chyby mohou zůstat nepovšimnuty a stát se velmi nákladnými). Přesto jsou fronty velmi potřebné, a zjistíte, že jsou mocnou zbraní (možná i nejmocnější) ve vašem arzenálu. Hodně štěstí! 🙂