Bota nuk qëndron në vend. Përparimi sjell sfida të reja teknologjike. Në përputhje me kërkesat që kanë ndryshuar, duhet të evoluojë edhe arkitektura e sistemeve të informacionit. Sot do të flasim për arkitekturën e orientuar nga ngjarjet, konkurrencën, paralelizmin, asinkroninë dhe për mënyrën se si mund të jetohet në paqe me të gjitha këto në Erlang.
Hyrje
Në varësi të përmasave të sistemit që projektohet dhe kërkesave ndaj tij, ne si zhvillues zgjedhim mënyrën e shkëmbimit të informacionit brenda sistemit. Në shumicën e rasteve, për organizimin e ndërveprimit mes shërbimeve, një zgjidhje praktike mund të jetë një skemë me broker, për shembull mbi bazën e RabbitMQ ose Kafka. Por ndonjëherë fluksi i ngjarjeve, SLA dhe niveli i kontrollit mbi sistemin janë të tilla, saqë një zgjidhje e gatshme messaging nuk na përshtatet. Sigurisht, sistemi mund të ndërlikohet pak duke marrë përsipër përgjegjësinë për nivelin e transportit dhe formimin e klasterit, për shembull duke përdorur ZeroMQ ose nanomsg. Por nëse sistemit i mjafton kapaciteti dhe funksionaliteti i klasterit standard të Erlang, atëherë çështja e shtimit të një entiteti shtesë kërkon analizë të detajuar dhe arsyetim ekonomik.
Tema e aplikacioneve reaktive tĂ« shpĂ«rndara Ă«shtĂ« mjaft e gjerĂ«. PĂ«r tâiu pĂ«rmbajtur formatit tĂ« artikullit, objekt i diskutimit tĂ« sotĂ«m do tĂ« jenĂ« vetĂ«m mjediset homogjene, tĂ« ndĂ«rtuara mbi bazĂ«n e Erlang/Elixir. Ekosistemi Erlang/OTP bĂ«n tĂ« mundur zbatimin e njĂ« arkitekture reaktive me pĂ«rpjekjen mĂ« tĂ« vogĂ«l. MegjithatĂ«, nĂ« çdo rast do tĂ« na duhet njĂ« shtresĂ« pĂ«r shkĂ«mbimin e mesazheve.
Baza teorike
Projektimi fillon me përcaktimin e objektivave dhe kufizimeve. Qëllimi kryesor nuk është zhvillimi thjesht për hir të zhvillimit. Na duhet të marrim një mjet të sigurt dhe të shkallëzueshëm, mbi bazën e të cilit mund të krijohen dhe, më e rëndësishmja, të zhvillohen aplikacione moderne të niveleve të ndryshme: duke nisur nga ato me një server të vetëm, që u shërbejnë audiencave të vogla dhe që më vonë mund të zhvillohen në klastera me 50-60 nyje, e deri te federatat e klasterave. Kështu, qëllimi kryesor është maksimizimi i fitimit përmes uljes së kostos së zhvillimit dhe të pronësisë së sistemit përfundimtar.
Le të veçojmë 4 kërkesat kryesore për sistemin përfundimtar:
- DOrientimi nga ngjarjet.
Sistemi është gjithmonë gati të përpunojë një rrjedhë ngjarjesh dhe të kryejë veprimet e nevojshme; - MShkallëzueshmëri.
Blloqet e veçanta mund të shkallëzohen si vertikalisht, ashtu edhe horizontalisht. I gjithë sistemi duhet të ketë mundësi për rritje horizontale të pakufizuar; - Qëndrueshmëri ndaj dështimeve.
Të gjitha nivelet dhe të gjitha shërbimet duhet të kenë mundësi rikuperimi automatik në rast dështimesh; - Kohë e garantuar reagimi.
Koha ka vlerë dhe përdoruesit nuk duhet të presin shumë gjatë.
Mbani mend pĂ«rrallĂ«n e vjetĂ«r pĂ«r âThe little engine that couldâ, e njohur edhe si âLokomotiva e vogĂ«l qĂ« ia doliâ? QĂ« sistemi i projektuar tĂ« kalojĂ« me sukses fazĂ«n e prototipit dhe tĂ« jetĂ« progresiv, themeli i tij duhet tĂ« pĂ«rmbushĂ« kĂ«rkesat minimale MUND.
Për messaging si mjet infrastrukturor dhe bazë për të gjitha shërbimet shtohet edhe një pikë tjetër: lehtësia e përdorimit për programuesit.
Orientimi ndaj ngjarjeve
Që aplikacioni të mund të rritet nga një serverë në një klaster, arkitektura e tij duhet të sigurojë lidhje të dobët ndërmjet komponentëve. Kësaj kërkese i përgjigjet modeli asinkron. Në të, dërguesi dhe marrësi kujdesen për ngarkesën informative të mesazhit dhe nuk shqetësohen për transmetimin dhe rrugëzimin brenda sistemit.
Shkallëzueshmëria
ShkallĂ«zueshmĂ«ria dhe efikasiteti i sistemit ecin krah pĂ«r krah. KomponentĂ«t e aplikacionit duhet tĂ« dinĂ« tĂ« shfrytĂ«zojnĂ« tĂ« gjitha burimet e disponueshme. Sa mĂ« mirĂ« tĂ« mund tâi shfrytĂ«zojmĂ« kapacitetet dhe sa mĂ« optimale tĂ« jenĂ« metodat tona tĂ« pĂ«rpunimit, aq mĂ« pak para shpenzojmĂ« pĂ«r pajisje.
Brenda një makine të vetme, Erlang krijon një mjedis me konkurrencë të lartë. Balanca midis konkurrencës dhe paralelizmit mund të përcaktohet duke zgjedhur numrin e fijeve të sistemit operativ të disponueshme për Erlang VM dhe numrin e planifikuesve që i shfrytëzojnë këto fije.
Proceset Erlang nuk kanë gjendje të përbashkët dhe funksionojnë në mënyrë jo-bllokuese. Kjo siguron latencë relativisht të ulët dhe throughput më të lartë sesa aplikacionet tradicionale të ndërtuara mbi sinkronizim bllokues. Planifikuesi i Erlang kujdeset për shpërndarjen e drejtë të CPU dhe IO, ndërsa mungesa e bllokimeve i lejon aplikacionit të përgjigjet edhe në kushte ngarkese kulmore ose gjatë dështimeve.
Edhe nĂ« nivel klasteri ekziston problemi i shfrytĂ«zimit tĂ« burimeve. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« tĂ« gjitha makinat nĂ« klaster tĂ« jenĂ« tĂ« ngarkuara nĂ« mĂ«nyrĂ« tĂ« barabartĂ« dhe rrjeti tĂ« mos mbingarkohet. Le tĂ« imagjinojmĂ« njĂ« situatĂ«: trafiku i pĂ«rdoruesve mbĂ«rrin te balancuesit hyrĂ«s (haproxy, nginx, etc), dhe ata i shpĂ«rndajnĂ« sa mĂ« nĂ« mĂ«nyrĂ« tĂ« njĂ«trajtshme kĂ«rkesat pĂ«r pĂ«rpunim midis grupit tĂ« backend-eve tĂ« disponueshme. Brenda infrastrukturĂ«s sĂ« aplikacionit, shĂ«rbimi qĂ« zbaton ndĂ«rfaqen e kĂ«rkuar Ă«shtĂ« vetĂ«m hallka e fundit dhe atij do tâi duhet tĂ« kĂ«rkojĂ« njĂ« sĂ«rĂ« shĂ«rbimesh tĂ« tjera pĂ«r tâiu pĂ«rgjigjur kĂ«rkesĂ«s fillestare. Edhe kĂ«rkesat e brendshme kanĂ« nevojĂ« pĂ«r rutim dhe balancim.
PĂ«r tĂ« menaxhuar nĂ« mĂ«nyrĂ« efikase flukset e tĂ« dhĂ«nave, messaging duhet tâu ofrojĂ« zhvilluesve njĂ« ndĂ«rfaqe pĂ«r menaxhimin e rutimit dhe shpĂ«rndarjes sĂ« ngarkesĂ«s. FalĂ« kĂ«saj, zhvilluesit do tĂ« mund tĂ« zgjidhin si detyrat standarde, ashtu edhe ato qĂ« shfaqen rrallĂ«, duke pĂ«rdorur pattern-et e mikrosherbimeve (aggregator, proxy, chain, branch, etc).
Nga këndvështrimi i biznesit, shkallëzueshmëria është një nga mjetet për menaxhimin e rreziqeve. Qëllimi kryesor është të përmbushen kërkesat e klientëve duke përdorur pajisjet në mënyrë optimale:
- Kur rritet kapaciteti i pajisjeve si rezultat i progresit, ato nuk do të qëndrojnë të papërdorura për shkak të mangësive të softuerit. Erlang shkallëzohet në mënyrë të shkëlqyer vertikalisht dhe gjithmonë do të mund të shfrytëzojë të gjitha bërthamat e CPU dhe memorien e disponueshme;
- Në mjediset cloud, ne mund të menaxhojmë sasinë e pajisjeve në varësi të ngarkesës aktuale ose të parashikuar dhe të garantojmë SLA.
Qëndrueshmëri
Le tĂ« shqyrtojmĂ« dy aksioma: âDĂ«shtimet janĂ« tĂ« papranueshmeâ dhe âDĂ«shtime do tĂ« ketĂ« gjithmonĂ«â. PĂ«r biznesin, njĂ« dĂ«shtim i softuerit do tĂ« thotĂ« humbje parash dhe, çâĂ«shtĂ« edhe mĂ« keq, humbje reputacioni. Duke balancuar midis humbjeve tĂ« mundshme dhe kostos sĂ« zhvillimit tĂ« softuerit fault-tolerant, shpesh mund tĂ« gjendet njĂ« kompromis.
Në afat të shkurtër, një arkitekturë me fault tolerance të integruar kursen para për blerjen e zgjidhjeve të gatshme të klasterizimit. Ato kushtojnë shtrenjtë dhe edhe ato kanë gabime.
Në afat të gjatë, një arkitekturë fault-tolerant i justifikon shumëfish kostot e zbatimit të saj në të gjitha fazat e zhvillimit.
Messaging brenda bazës së kodit që në fazën e zhvillimit lejon të përpunohet në detaje ndërveprimi i komponentëve brenda sistemit. Kjo e thjeshton reagimin ndaj dështimeve dhe menaxhimin e tyre, sepse të gjithë komponentët përgjegjës i trajtojnë dështimet, ndërsa sistemi përfundimtar di si të rikthehet automatikisht në gjendje normale pas një dështimi, by design.
Reagueshmëria
Pavarësisht dështimeve, aplikacioni duhet t'u përgjigjet kërkesave dhe të përmbushë SLA. Realiteti është se njerëzit nuk duan të presin, ndaj edhe biznesi duhet të përshtatet. Gjithnjë e më shumë aplikacioneve u kërkohet reagueshmëri e lartë.
Aplikacionet reaguese funksionojnë në një regjim të afërt me kohën reale. Erlang VM punon në regjim soft real-time. Për disa fusha, si tregtimi në bursë, mjekësia dhe kontrolli i pajisjeve industriale, është i rëndësishëm regjimi hard real-time.
Sistemet reaguese përmirësojnë UX dhe janë të dobishme për biznesin.
PĂ«rfundim paraprak
Kur planifikoja këtë artikull, doja të ndaja përvojën e krijimit të një message broker dhe ndërtimin e sistemeve komplekse mbi bazën e tij. Por pjesa teorike dhe motivuese doli mjaft e gjerë.
Në pjesën e dytë të artikullit do të tregoj për nuancat e implementimit të pikave të shkëmbimit, modelet e shkëmbimit të mesazheve dhe përdorimin e tyre.
Në pjesën e tretë do të shqyrtojmë çështjet e përgjithshme të organizimit të shërbimeve, rutimit dhe balancimit. Do të flasim për anën praktike të shkallëzueshmërisë dhe tolerancës ndaj gabimeve të sistemeve.
Krahu i parë është përfunduar.
Foto .
Burimi: habr.com
