Svět nestojí na místě. Pokrok vytváří nové technologické výzvy. V souladu s měnícími se požadavky se musí vyvíjet architektura informačních systémů. Dnes budeme hovořit o architektuře řízené událostmi, souběžnosti, souběžnosti, asynchronii a o tom, jak s tím vším můžete v Erlangu pokojně žít.
úvod
Podle velikosti navrženého systému a požadavků na něj volíme způsob výměny informací v systému my, vývojáři. Ve většině případů pro organizaci interakce služeb může být pracovní možností schéma s makléřem, například založené na RabbitMQ nebo kafka. Ale tok událostí, SLA a úroveň kontroly nad systémem jsou někdy takové, že pro nás hotové zprávy nejsou vhodné. Samozřejmě můžete systém trochu zkomplikovat tím, že převezmete zodpovědnost za transportní vrstvu a tvorbu clusteru, například pomocí ZeroMQ nebo nanomsg. Ale pokud má systém dostatečnou propustnost a možnosti standardního clusteru Erlang, pak otázka zavedení další entity vyžaduje podrobné prostudování a ekonomické zdůvodnění.
Téma reaktivních distribuovaných aplikací je poměrně široké. Abychom dodrželi formát článku, předmětem dnešní diskuse budou pouze homogenní prostředí postavená na Erlang/Elixir. Ekosystém Erlang/OTP umožňuje implementovat reaktivní architekturu s minimálním úsilím. Ale v každém případě budeme potřebovat vrstvu zpráv.
Teoretický základ
Design začíná definováním cílů a omezení. Hlavní cíl není v oblasti rozvoje pro rozvoj. Potřebujeme získat bezpečný a škálovatelný nástroj, na jehož základě můžeme vytvářet a hlavně vyvíjet moderní aplikace různých úrovní: od jednoserverových aplikací sloužících malému publiku, které se později mohou rozvinout do clusterů až 50 -60 uzlů, končící federacemi clusterů. Hlavním cílem je tedy maximalizace zisku snížením nákladů na vývoj a vlastnictví finálního systému.
Zdůrazněme 4 hlavní požadavky na konečný systém:
- Сzaměřené na události.
Systém je vždy připraven projít tokem událostí a provést potřebné akce; - Мškálovatelnost.
Jednotlivé bloky lze škálovat vertikálně i horizontálně. Celý systém musí být schopen nekonečného horizontálního růstu; - Оodolnost proti chybám.
Všechny úrovně a všechny služby by měly být schopny automaticky se zotavit po selhání; - Гgarantovaná doba odezvy.
Čas je cenný a uživatelé by neměli čekat příliš dlouho.
Pamatujete na starou pohádku o „Malém motoru, který by mohl“? Aby navržený systém úspěšně opustil fázi prototypu a byl progresivní, musí jeho základ splňovat minimální požadavky SMOG.
Ke zprávám jako nástroji infrastruktury a základu všech služeb je přidán ještě jeden bod: snadné použití pro programátory.
Zaměřené na události
Aby aplikace vyrostla z jednoho serveru do clusteru, musí její architektura podporovat volné propojení. Asynchronní model tento požadavek splňuje. V něm se odesílatel a příjemce starají o informační zátěž zprávy a nestarají se o přenos a směrování v rámci systému.
Škálovatelnost
Škálovatelnost a efektivita systému jsou vedle sebe. Komponenty aplikace musí být schopny využívat všechny dostupné zdroje. Čím efektivněji dokážeme využít kapacitu a čím optimálnější jsou naše metody zpracování, tím méně peněz utratíme za zařízení.
V rámci jednoho stroje Erlang vytváří vysoce konkurenční prostředí. Rovnováhu mezi souběžností a paralelismem lze nastavit výběrem počtu vláken operačního systému dostupných pro virtuální počítač Erlang a počtu plánovačů, které tato vlákna využívají.
Procesy Erlang nesdílejí stav a fungují v neblokujícím režimu. To poskytuje relativně nízkou latenci a vyšší propustnost než tradiční aplikace založené na blokování. Plánovač Erlang zajišťuje spravedlivou alokaci CPU a IO a absence blokování umožňuje aplikaci reagovat i během špičkového zatížení nebo selhání.
Na úrovni clusteru také existuje problém s likvidací. Je důležité, aby všechny stroje v clusteru byly rovnoměrně zatíženy a aby síť nebyla přetížena. Představme si situaci: uživatelský provoz přistává na příchozích balancérech (haproxy, nginx atd.), které rozdělují požadavky na zpracování co nejrovnoměrněji mezi sadu dostupných backendů. V rámci aplikační infrastruktury je služba implementující požadované rozhraní pouze poslední mílí a bude muset požádat o řadu dalších služeb, aby reagovala na počáteční požadavek. Interní požadavky také vyžadují směrování a vyvažování.
Aby bylo možné efektivně spravovat datové toky, musí zasílání zpráv poskytovat vývojářům rozhraní pro správu směrování a vyvažování zátěže. Díky tomu budou vývojáři schopni pomocí vzorů mikroslužeb (agregátor, proxy, řetězec, větev atd.) řešit jak standardní problémy, tak ty, které se objevují jen zřídka.
Z obchodního hlediska je škálovatelnost jedním z nástrojů řízení rizik. Hlavní věcí je uspokojit požadavky zákazníků optimálním využitím zařízení:
- Když se výkon zařízení v důsledku pokroku zvyšuje. Nebude nečinný kvůli nedokonalému softwaru. Erlang se vertikálně dobře škáluje a bude vždy schopen využít všechna jádra CPU a dostupnou paměť;
- V cloudových prostředích můžeme spravovat množství zařízení v závislosti na aktuálním nebo předpokládaném zatížení a garantovat SLA.
odolnost proti chybám
Podívejme se na dva axiomy: "Neúspěchy jsou nepřijatelné" a "Vždy budou existovat selhání." Pro firmu znamená selhání softwaru ztrátu peněz, a co je horší, ztrátu reputace. Při balancování mezi možnými ztrátami a náklady na vývoj softwaru odolného vůči chybám lze často nalézt kompromis.
Z krátkodobého hlediska šetří architektura, která zahrnuje odolnost proti chybám, peníze na nákup standardních clusterových řešení. Jsou drahé a mají také chyby.
Z dlouhodobého hlediska se architektura odolná proti chybám mnohonásobně vyplatí ve všech fázích vývoje.
Zasílání zpráv v rámci kódové základny vám umožňuje podrobně vypracovat interakci komponent v rámci systému ve fázi vývoje. To zjednodušuje úkol reagovat a řídit selhání, protože všechny kritické komponenty zvládají selhání a výsledný systém ví, jak se automaticky vrátit do normálu po selhání podle návrhu.
Schopnost reagovat
Bez ohledu na selhání musí aplikace reagovat na požadavky a splňovat SLA. Realita je taková, že lidé nechtějí čekat, a tak se podniky musí odpovídajícím způsobem přizpůsobit. Očekává se, že stále více aplikací bude vysoce reagovat.
Responzivní aplikace fungují téměř v reálném čase. Erlang VM pracuje v měkkém režimu v reálném čase. Pro některé oblasti, jako je obchodování s akciemi, lékařství a řízení průmyslových zařízení, je důležitý tvrdý režim v reálném čase.
Responzivní systémy zlepšují uživatelské prostředí a jsou přínosem pro podnikání.
Předběžné shrnutí
Při plánování tohoto článku jsem se chtěl podělit o své zkušenosti s vytvářením zprostředkovatele zpráv a budováním komplexních systémů na jeho základě. Teoretická a motivační část se ale 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ů zasílání zpráv a jejich použití.
Ve třetí části se budeme zabývat obecnými otázkami organizace služeb, směrování a vyvažování. Pojďme se bavit o praktické stránce škálovatelnosti a odolnosti systémů proti chybám.
Konec prvního dílu.
Fotografie .
Zdroj: www.habr.com