Svět se neposunuje dál. Pokrok vytváří nové technologické výzvy. V souladu se změněnými požadavky musí evolvovat i architektura informačních systémů. Dnes budeme mluvit o událostně orientované architektuře, konkurenčnosti, paralelnosti, asynchronnosti a o tom, jak s tím vším lze v Erlangu bez problémů žít.
Úvod
V závislosti na velikosti navrhovaného systému a jeho požadavcích si, jako vývojáři, vybíráme způsob výměny informací v systému. Většinou, pro zajištění interakce služeb, může být pracovní variantou schéma s brokerem, například na bázi RabbitMQ nebo Kafka. Ale někdy jsou tok událostí, SLA a úroveň kontroly nad systémem takové, že připravené messaging nám nevyhovuje. Samozřejmě, můžeme systém trochu zkomplikovat tím, že převezmeme odpovědnost za transportní úroveň a formování clustera, například pomocí ZeroMQ nebo nanomsg. Ale pokud systému stačí propustnost a možnosti standardního Erlang clusteru, pak otázka zavádění další entity vyžaduje podrobné prozkoumání a ekonomické odůvodnění.
Téma reaktivních distribuovaných aplikací je poměrně rozsáhlé. Abychom se vešli do formátu článku, předmětem dnešního diskuse budou pouze homogenní prostředí založená na Erlangu/Elixiru. Ekosystém Erlang/OTP umožňuje implementaci reaktivní architektury s minimálním pracovním úsilím. Ale v každém případě budeme potřebovat vrstvu pro výměnu zpráv.
Teoretický základ
Návrh začíná určováním cílů a omezení. Hlavním cílem není být ve vývoji kvůli vývoji. Potřebujeme získat bezpečný a škálovatelný nástroj, na jehož základě lze vytvářet, a co je nejdůležitější – rozvíjet moderní aplikace různého stupně: začínající od jedno-serverových, které obsluhují malou cílovou skupinu, jež se může později vyvinout v clustery až 50-60 uzlů, konče federacemi clusterů. Tím pádem hlavní cíl – maximalizace zisku prostřednictvím snížení nákladů na vývoj a vlastnictví konečného systému.
Vyčleňme 4 hlavní požadavky na konečný systém:
- Sorientovanost na události.
Systém je vždy připraven propustit proud událostí a vykonat potřebné akce; - Měřitelnost.
Jednotlivé bloky mohou být škálovány vertikálně i horizontálně. Celý systém by měl mít možnost nekonečného horizontálního růstu; - Odolnost.
Všechny úrovně a všechny služby musí mít možnost automatického obnovení v případě selhání; - Garantovaná doba odezvy.
Čas je cenný a uživatelé by neměli čekat příliš dlouho.
Pamatujte na starou pohádku o "Malém parníčku, který mohl"? Aby navrhovaný systém úspěšně přešel z prototypu do pokročilé fáze, musí jeho základ splňovat minimální požadavky. MOHL.
K messagingu jako infrastrukturnímu nástroji a základu pro všechny služby se přidává další bod: uživatelská přívětivost pro programátory.
Orientace na události
Aby aplikace mohla přejít z jednoho serveru do clusteru, její architektura musí zajišťovat slabou provázanost. Tato požadavek splňuje asynchronní model. V něm se o informační zátěž zprávy starají odesílatel a příjemce, aniž by se starali o přenos a směrování v systému.
Škálovatelnost
Škálovatelnost a efektivita systému jdou ruku v ruce. Komponenty aplikace musí být schopny využít všechny dostupné zdroje. Čím efektivněji můžeme využívat kapacity a čím optimálněji jsou naše metody zpracování, tím méně utrácíme za vybavení.
V rámci jednoho stroje vytváří Erlang vysoce konkurenceschopné prostředí. Rovnováha mezi konkurencí a paralelností může být nastavena výběrem počtu vláken operačního systému dostupných pro Erlang VM a počtem plánovačů, kteří tyto vlákna využívají.
Erlang procesy nemají společný stav a pracují v neblokujícím režimu. To zajišťuje relativně nízkou latenci a vyšší průtok než tradiční aplikace postavené na blokující synchronizaci. Plánovač Erlang se stará o spravedlivé rozdělení CPU a IO a absence zámků umožňuje aplikaci reagovat i v režimu vrcholových zátěží nebo poruch.
Na úrovni clusteru je také problém s využitím. Je důležité, aby byly všechny stroje v clusteru rovnoměrně zatíženy a síť nebyla přetížená. Představme si situaci: uživatelský provoz přistává na příchozích vyrovnávačích zatížení (haproxy, nginx, atd.), které co nejrovnoměrněji rozdělují požadavky mezi sadu dostupných backendů. V rámci infrastruktury aplikace je služba, která realizuje požadovaný rozhraní, pouze poslední míle a bude muset požádat o řadu dalších služeb, aby odpověděla na původní požadavek. Vnitřní požadavky také vyžadují směrování a vyrovnávání zátěže.
Aby se efektivně spravovaly toky dat, musí messaging poskytovat vývojářům rozhraní pro správu směrování a rozdělení zatížení. Díky tomu budou moci vývojáři pomocí mikroservisních vzorů (aggregátor, proxy, chain, branch, atd.) řešit jak standardní úkoly, tak i ty, které se vyskytují zřídka.
Z obchodního hlediska je škálovatelnost jedním z nástrojů řízení rizik. Hlavní je uspokojit požadavky klientů s optimálním využitím vybavení:
- Zvýšení výkonu vybavení díky pokroku. Nebude stagnovat kvůli nedokonalosti softwaru. Erlang se skvěle škáluje vertikálně a vždy dokáže využít všechny CPU jádra a dostupnou paměť;
- V podmínkách cloudových prostředí můžeme řídit počet zařízení podle aktuálního nebo předpokládaného zatížení a zaručit SLA.
Odolnost proti výpadkům
Uvažujme o dvou axiomech: "Výpadky jsou nepřijatelné" a "Výpadky se vždy stanou". Pro podnikání je výpadek softwaru ztrátou peněz, a co je horší – ztrátou reputace. Balancováním mezi možnými ztrátami a náklady na vývoj softwaru odolného proti výpadkům lze často najít kompromis.
V krátkodobém horizontu architektura, která zahrnuje odolnost proti výpadkům, šetří peníze na nákupu hotových řešení clusteringu. Ta jsou drahá a také obsahují chyby.
V dlouhodobém horizontu se odolná architektura mnohokrát vrátí na náklady, které byly vynaloženy na její aplikaci ve všech fázích vývoje.
Messaging v rámci kódové základny je stále ve fázi vývoje, což umožňuje podrobněji zpracovat interakci komponentů v systému. To usnadňuje úkol reagovat a spravovat selhání, protože všechny odpovědné komponenty zpracovávají selhání a samotný systém ví, jak se automaticky vrátit do normálního stavu po selhání, navrženého tímto způsobem.
Reaktivita
Bez ohledu na selhání by aplikace měla odpovídat na požadavky a splňovat SLA. Realita je taková, že lidé nechtějí čekat, a proto se podniky musí přizpůsobit. Od stále více aplikací se očekává vysoká reaktivita.
Reaktivní aplikace fungují v režimu, který se blíží reálnému času. Erlang VM funguje v režimu měkkého reálného času. Pro některé oblasti, jako je burzovní obchod, medicína, řízení průmyslového vybavení, je důležitý režim tvrdého reálného času.
Reaktivní systémy zlepšují UX a jsou užitečné pro podnikání.
Předběžný výsledek
Při plánování tohoto článku jsem chtěl sdílet zkušenosti se vytvářením zprostředkovatele zpráv a stavbou složitých systémů na jeho základě. Ale teoretická a motivační část se ukázala jako poměrně rozsáhlá.
Ve druhé části článku budu hovořit o nuancích implementace výměnných bodů, vzorcích výměny zpráv a jejich použití.
Ve třetí části se zaměříme na obecné otázky organizace služeb, směrování a vyvažování. Probereme praktickou stránku škálovatelnosti a odolnosti systémů.
Konec první části.
Foto .
Zdroj: habr.com
