Svet nestojí na mieste. Pokrok vytvára nové technologické výzvy. V súlade s meniacimi sa požiadavkami sa musí vyvíjať aj architektúra informačných systémov. Dnes budeme hovoriť o architektúre riadenej udalosťami, súbežnosti, súbežnosti, asynchrónnosti a o tom, ako s tým všetkým môžete pokojne žiť v Erlangu.
Úvod
Podľa veľkosti navrhovaného systému a požiadaviek naň volíme spôsob výmeny informácií v systéme my, vývojári. Vo väčšine prípadov na organizovanie interakcie služieb môže byť pracovnou možnosťou schéma s maklérom, napríklad založená na RabbitMQ alebo kafka. Ale tok udalostí, SLA a úroveň kontroly nad systémom sú niekedy také, že hotové správy nie sú pre nás vhodné. Samozrejme, systém môžete trochu skomplikovať prebratím zodpovednosti za transportnú vrstvu a tvorbu klastrov, napríklad pomocou ZeroMQ alebo nanomsg. Ale ak má systém dostatočnú priepustnosť a možnosti štandardného klastra Erlang, potom si otázka zavedenia ďalšej entity vyžaduje podrobné štúdium a ekonomické zdôvodnenie.
Téma reaktívnych distribuovaných aplikácií je pomerne široká. Aby sme dodržali formát článku, predmetom dnešnej diskusie budú iba homogénne prostredia postavené na Erlang/Elixir. Ekosystém Erlang/OTP vám umožňuje implementovať reaktívnu architektúru s minimálnym úsilím. V každom prípade však budeme potrebovať vrstvu správ.
Teoretický základ
Dizajn začína definovaním cieľov a obmedzení. Hlavný cieľ nie je v oblasti rozvoja kvôli rozvoju. Potrebujeme získať bezpečný a škálovateľný nástroj, na základe ktorého môžeme vytvárať a hlavne vyvíjať moderné aplikácie rôznych úrovní: počnúc jednoserverovými aplikáciami slúžiacimi malému publiku, ktoré sa neskôr môžu rozvinúť do klastrov až 50 -60 uzlov, končiac klastrovými federáciami. Hlavným cieľom je teda maximalizácia zisku znížením nákladov na vývoj a vlastníctvo finálneho systému.
Zdôraznime 4 hlavné požiadavky na konečný systém:
- Сzameraná na udalosti.
Systém je vždy pripravený prejsť tokom udalostí a vykonať potrebné akcie; - Мškálovateľnosť.
Jednotlivé bloky je možné zmenšiť vertikálne aj horizontálne. Celý systém musí byť schopný nekonečného horizontálneho rastu; - Оodolnosť proti chybám.
Všetky úrovne a všetky služby by mali byť schopné automaticky sa zotaviť z porúch; - Гgarantovaný čas odozvy.
Čas je cenný a používatelia by nemali čakať príliš dlho.
Pamätáte si na starú rozprávku o „Malom motore, ktorý by mohol“? Aby navrhnutý systém úspešne vyšiel z fázy prototypu a bol progresívny, jeho základ musí spĺňať minimálne požiadavky SMOG.
K zasielaniu správ ako nástroju infraštruktúry a základu všetkých služieb sa pridáva ešte jeden bod: jednoduchosť použitia pre programátorov.
Orientovaný na udalosti
Aby aplikácia mohla rásť z jedného servera na klaster, jej architektúra musí podporovať voľné prepojenie. Asynchrónny model túto požiadavku spĺňa. V ňom sa odosielateľ a príjemca starajú o informačnú záťaž správy a nestarajú sa o prenos a smerovanie v rámci systému.
Škálovateľnosť
Škálovateľnosť a efektívnosť systému sú vedľa seba. Komponenty aplikácie musia byť schopné využívať všetky dostupné zdroje. Čím efektívnejšie dokážeme využiť kapacitu a čím optimálnejšie sú naše metódy spracovania, tým menej peňazí minieme na vybavenie.
V rámci jedného stroja Erlang vytvára vysoko konkurenčné prostredie. Rovnováhu medzi súbežnosťou a paralelizmom je možné nastaviť výberom počtu vlákien operačného systému dostupných pre Erlang VM a počtu plánovačov, ktoré tieto vlákna využívajú.
Procesy Erlang nezdieľajú stav a fungujú v neblokujúcom režime. To poskytuje relatívne nízku latenciu a vyššiu priepustnosť ako tradičné aplikácie založené na blokovaní. Erlangov plánovač zaisťuje spravodlivú alokáciu CPU a IO a absencia blokovania umožňuje aplikácii reagovať aj pri špičkovom zaťažení alebo poruchách.
Na úrovni klastrov tiež existuje problém s likvidáciou. Je dôležité, aby boli všetky stroje v klastri rovnomerne zaťažené a aby sieť nebola preťažená. Predstavme si situáciu: návštevnosť používateľov pristáva na prichádzajúce balancery (haproxy, nginx atď.), ktoré rozdeľujú požiadavky na spracovanie čo najrovnomernejšie medzi sadu dostupných koncových zariadení. V rámci aplikačnej infraštruktúry je služba implementujúca požadované rozhranie len poslednou míľou a bude musieť požiadať o množstvo ďalších služieb, aby reagovala na počiatočnú požiadavku. Interné požiadavky tiež vyžadujú smerovanie a vyváženie.
Aby bolo možné efektívne riadiť dátové toky, správy musia poskytnúť vývojárom rozhranie na riadenie smerovania a vyrovnávania záťaže. Vďaka tomu budú môcť vývojári pomocou vzorov mikroslužieb (agregátor, proxy, reťazec, pobočka atď.) riešiť štandardné problémy aj tie, ktoré sa vyskytujú len zriedka.
Z obchodného hľadiska je škálovateľnosť jedným z nástrojov riadenia rizík. Hlavnou vecou je uspokojiť požiadavky zákazníkov optimálnym využitím zariadenia:
- Keď sa výkon zariadenia zvyšuje v dôsledku pokroku. Nebude nečinný kvôli nedokonalému softvéru. Erlang sa vertikálne dobre škáluje a vždy bude môcť využiť všetky jadrá CPU a dostupnú pamäť;
- V cloudových prostrediach vieme spravovať množstvo zariadení v závislosti od aktuálneho alebo predpokladaného zaťaženia a garantovať SLA.
odolnosť proti chybám
Uvažujme o dvoch axiómach: „Zlyhania sú neprijateľné“ a „Vždy budú zlyhania“. Pre firmu znamená zlyhanie softvéru stratu peňazí a čo je horšie, stratu reputácie. Pri balansovaní medzi možnými stratami a nákladmi na vývoj softvéru odolného voči chybám možno často nájsť kompromis.
Z krátkodobého hľadiska architektúra, ktorá zahŕňa odolnosť voči chybám, šetrí peniaze na nákup štandardných riešení klastrovania. Sú drahé a majú aj chyby.
Z dlhodobého hľadiska sa architektúra odolná voči chybám mnohonásobne vyplatí vo všetkých fázach vývoja.
Posielanie správ v rámci kódovej základne vám umožňuje podrobne vypracovať interakciu komponentov v rámci systému vo fáze vývoja. To zjednodušuje úlohu reakcie a riadenia zlyhaní, pretože všetky kritické komponenty zvládajú zlyhania a výsledný systém sa vie, ako sa po zlyhaní automaticky vrátiť do normálu.
neha
Bez ohľadu na zlyhania musí aplikácia reagovať na požiadavky a spĺňať SLA. Realita je taká, že ľudia nechcú čakať, a tak sa firmy musia tomu prispôsobiť. Očakáva sa, že čoraz viac aplikácií bude mať vysokú odozvu.
Responzívne aplikácie fungujú takmer v reálnom čase. Erlang VM pracuje v mäkkom režime v reálnom čase. Pre niektoré oblasti, ako je obchodovanie s akciami, medicína a kontrola priemyselných zariadení, je dôležitý tvrdý režim v reálnom čase.
Responzívne systémy zlepšujú UX a prinášajú výhody pre podnikanie.
Predbežné zhrnutie
Pri plánovaní tohto článku som sa chcel podeliť o svoje skúsenosti s vytváraním sprostredkovateľa správ a budovaním komplexných systémov na jeho základe. Ale teoretická a motivačná časť sa ukázala ako dosť rozsiahla.
V druhej časti článku budem hovoriť o nuansách implementácie výmenných bodov, vzoroch správ a ich aplikácii.
V tretej časti sa budeme zaoberať všeobecnými otázkami organizácie služieb, smerovania a vyváženia. Povedzme si niečo o praktickej stránke škálovateľnosti a odolnosti systémov proti chybám.
Koniec prvej časti.
fotografie .
Zdroj: hab.com