Pasaulis nestovi vietoje. Pažanga sukuria naujų technologinių iššūkių. Atsižvelgiant į kintančius reikalavimus, informacinių sistemų architektūra turi tobulėti. Šiandien kalbėsime apie įvykių skatinamą architektūrą, lygiagretumą, lygiagretumą, asinchroniškumą ir tai, kaip galite taikiai gyventi su visa tai Erlange.
įvedimas
Atsižvelgdami į projektuojamos sistemos dydį ir jai keliamus reikalavimus, mes, kūrėjai, pasirenkame apsikeitimo informacija sistemoje būdą. Daugeliu atvejų, norint organizuoti paslaugų sąveiką, darbo variantas gali būti schema su brokeriu, pavyzdžiui, remiantis RabbitMQ arba kafka. Tačiau kartais įvykių srautas, SLA ir sistemos valdymo lygis yra tokie, kad paruošti pranešimai mums netinka. Žinoma, galite šiek tiek apsunkinti sistemą prisiimdami atsakomybę už transportavimo sluoksnį ir klasterių formavimą, pavyzdžiui, naudodami ZeroMQ arba nanomsg. Bet jei sistema turi pakankamai pralaidumo ir standartinio Erlang klasterio galimybių, tada papildomo objekto įvedimo klausimas reikalauja išsamaus tyrimo ir ekonominio pagrindimo.
Reaktyviųjų paskirstytų programų tema yra gana plati. Siekiant išlaikyti straipsnio formatą, šiandienos diskusijos tema bus tik vienalytė aplinka, sukurta Erlang/Elixir pagrindu. Erlang/OTP ekosistema leidžia įgyvendinti reaktyviąją architektūrą įdedant mažiausiai pastangų. Bet bet kuriuo atveju mums reikės pranešimų sluoksnio.
Teorinis pagrindas
Dizainas prasideda nuo tikslų ir apribojimų apibrėžimo. Pagrindinis tikslas nėra plėtros vardan plėtros. Turime gauti saugų ir keičiamą įrankį, kurio pagrindu galėtume kurti ir, svarbiausia, kurti modernias įvairaus lygio programas: pradedant nuo vieno serverio taikomųjų programų, aptarnaujančių nedidelę auditoriją, kurios vėliau gali išsivystyti į grupes iki 50 -60 mazgų, baigiant klasterių federacijomis. Taigi pagrindinis tikslas yra maksimaliai padidinti pelną sumažinant galutinės sistemos kūrimo ir nuosavybės išlaidas.
Išskirkime 4 pagrindinius galutinės sistemos reikalavimus:
- Сorientuotas į įvykį.
Sistema visada pasiruošusi pereiti įvykių srautą ir atlikti reikiamus veiksmus; - Мmastelio keitimas.
Atskirų blokų mastelį galima keisti tiek vertikaliai, tiek horizontaliai. Visa sistema turi turėti galimybę be galo horizontaliai augti; - Оatsparumas gedimams.
Visi lygiai ir visos paslaugos turi turėti galimybę automatiškai atsigauti po gedimų; - Гgarantuotas atsako laikas.
Laikas yra vertingas ir vartotojai neturėtų laukti per ilgai.
Prisimeni seną pasaką apie „Mažasis variklis, kuris galėtų“? Kad sukurta sistema sėkmingai išeitų iš prototipo stadijos ir būtų progresyvi, jos pagrindas turi atitikti minimalius reikalavimus SMOG.
Prie pranešimų, kaip infrastruktūros įrankio ir visų paslaugų pagrindo, pridedamas dar vienas taškas: programuotojų naudojimo paprastumas.
Orientuotas į įvykius
Kad programa iš vieno serverio išaugtų į klasterį, jos architektūra turi palaikyti laisvą ryšį. Asinchroninis modelis atitinka šį reikalavimą. Jame siuntėjui ir gavėjui rūpi pranešimo informacijos apkrova ir nesijaudina dėl perdavimo ir maršruto nustatymo sistemos viduje.
Mastelis
Mastelio keitimas ir sistemos efektyvumas yra šalia vienas kito. Programos komponentai turi turėti galimybę panaudoti visus turimus išteklius. Kuo efektyviau išnaudosime pajėgumus ir kuo optimalesni apdorojimo metodai, tuo mažiau pinigų išleidžiame įrangai.
Vienoje mašinoje Erlang sukuria labai konkurencingą aplinką. Lygiagretumo ir lygiagretumo pusiausvyrą galima nustatyti pasirinkus operacinės sistemos gijų, prieinamų Erlang VM, skaičių ir planavimo priemonių, naudojančių šias gijas, skaičių.
Erlang procesai nesidalija būsena ir veikia neblokuojančiu režimu. Tai užtikrina santykinai mažą delsą ir didesnį pralaidumą nei tradicinės blokavimo programos. „Erlang“ planuoklis užtikrina teisingą procesoriaus ir IO paskirstymą, o blokavimo nebuvimas leidžia programai reaguoti net esant didžiausioms apkrovoms ar gedimams.
Klasterio lygiu taip pat yra šalinimo problema. Svarbu, kad visos klasterio mašinos būtų apkrautos tolygiai, o tinklas nebūtų perkrautas. Įsivaizduokime situaciją: vartotojų srautas patenka į gaunamus balansavimo įrenginius (haproxy, nginx ir tt), jie paskirsto apdorojimo užklausas kaip įmanoma tolygiau tarp galimų užpakalinių sistemų. Programos infrastruktūroje paslauga, įgyvendinanti reikiamą sąsają, yra tik paskutinė mylia ir turės paprašyti daugelio kitų paslaugų, kad būtų atsakyta į pradinį užklausą. Vidiniams užklausoms taip pat reikalingas maršrutas ir balansavimas.
Norint efektyviai valdyti duomenų srautus, pranešimų siuntimas kūrėjams turi suteikti sąsają, skirtą valdyti maršrutą ir apkrovos balansavimą. Dėl šios priežasties kūrėjai, naudodamiesi mikro paslaugų modeliais (agregatoriumi, tarpiniu serveriu, grandine, šaka ir kt.), galės išspręsti tiek standartines, tiek retai pasitaikančias problemas.
Verslo požiūriu mastelio keitimas yra viena iš rizikos valdymo priemonių. Svarbiausia yra patenkinti klientų pageidavimus optimaliai naudojant įrangą:
- Kai dėl pažangos padidėja įrangos galia. Jis neveiks dėl netobulos programinės įrangos. „Erlang“ vertikaliai keičiasi gerai ir visada galės išnaudoti visus procesoriaus branduolius ir turimą atmintį;
- Debesų aplinkoje galime valdyti įrangos kiekį priklausomai nuo esamos ar numatomos apkrovos ir garantuoti SLA.
atsparumas gedimams
Panagrinėkime dvi aksiomas: „Nesėkmės nepriimtinos“ ir „Nesėkmės visada bus“. Verslui programinės įrangos gedimas reiškia pinigų praradimą, o dar blogiau – reputacijos praradimą. Balansuojant tarp galimų nuostolių ir gedimams atsparios programinės įrangos kūrimo išlaidų, dažnai galima rasti kompromisą.
Per trumpą laiką architektūra, apimanti atsparumą gedimams, leidžia sutaupyti pinigų perkant jau paruoštus klasterizacijos sprendimus. Jie yra brangūs ir turi klaidų.
Ilgainiui gedimams atspari architektūra atsiperka daug kartų visuose kūrimo etapuose.
Pranešimų siuntimas kodo bazėje leidžia išsamiai išsiaiškinti komponentų sąveiką sistemoje kūrimo etape. Tai supaprastina užduotį reaguoti ir valdyti gedimus, nes visi svarbūs komponentai tvarko gedimus, o gauta sistema žino, kaip automatiškai grįžti į normalią būseną po gedimo pagal projektą.
Reagavimas
Nepaisant gedimų, programa turi atsakyti į užklausas ir atitikti SLA. Realybė tokia, kad žmonės nenori laukti, todėl įmonės turi atitinkamai prisitaikyti. Tikimasi, kad vis daugiau programų bus labai jautrios.
Reaguojančios programos veikia beveik realiuoju laiku. Erlang VM veikia minkštu realiojo laiko režimu. Kai kurioms sritims, pvz., prekybai akcijomis, medicinai ir pramoninės įrangos valdymui, svarbus realaus laiko režimas.
Reaguojančios sistemos pagerina UX ir naudingos verslui.
Preliminari santrauka
Planuodamas šį straipsnį norėjau pasidalinti savo patirtimi kuriant žinučių siuntimo brokerį ir kuriant jo pagrindu sudėtingas sistemas. Tačiau teorinė ir motyvacinė dalis pasirodė gana plati.
Antroje straipsnio dalyje kalbėsiu apie apsikeitimo taškų diegimo niuansus, pranešimų šablonus ir jų pritaikymą.
Trečioje dalyje aptarsime bendruosius paslaugų organizavimo, maršruto parinkimo ir balansavimo klausimus. Pakalbėkime apie praktinę sistemų mastelio ir atsparumo gedimams pusę.
Pirmos dalies pabaiga.
nuotrauka .
Šaltinis: www.habr.com