Bota nuk qëndron ende. Progresi krijon sfida të reja teknologjike. Në përputhje me kërkesat në ndryshim, arkitektura e sistemeve të informacionit duhet të evoluojë. Sot do të flasim për arkitekturën e drejtuar nga ngjarjet, konkurencën, konkurencën, asinkroninë dhe si mund të jetoni në paqe me të gjitha këto në Erlang.
Paraqitje
Në varësi të madhësisë së sistemit të projektuar dhe kërkesave për të, ne, zhvilluesit, zgjedhim metodën e shkëmbimit të informacionit në sistem. Në shumicën e rasteve, për të organizuar ndërveprimin e shërbimeve, një opsion pune mund të jetë një skemë me një ndërmjetës, për shembull, bazuar në RabbitMQ ose kafka. Por ndonjëherë rrjedha e ngjarjeve, SLA dhe niveli i kontrollit mbi sistemin janë të tilla që mesazhet e gatshme nuk janë të përshtatshme për ne. Sigurisht, ju mund ta komplikoni pak sistemin duke marrë përgjegjësinë për shtresën e transportit dhe formimin e grupimeve, për shembull duke përdorur ZeroMQ ose nanomsg. Por nëse sistemi ka xhiro të mjaftueshme dhe aftësi të një grupi standard Erlang, atëherë çështja e prezantimit të një entiteti shtesë kërkon studim të detajuar dhe justifikim ekonomik.
Tema e aplikacioneve të shpërndara reaktive është mjaft e gjerë. Për të mbajtur brenda formatit të artikullit, temë e diskutimit të sotëm do të jenë vetëm mjediset homogjene të ndërtuara mbi Erlang/Elixir. Ekosistemi Erlang/OTP ju lejon të zbatoni një arkitekturë reaktive me sa më pak përpjekje. Por në çdo rast, do të na duhet një shtresë mesazhesh.
Baza teorike
Dizajni fillon me përcaktimin e qëllimeve dhe kufizimeve. Qëllimi kryesor nuk është në fushën e zhvillimit për hir të zhvillimit. Ne duhet të marrim një mjet të sigurt dhe të shkallëzuar mbi bazën e të cilit mund të krijojmë dhe, më e rëndësishmja, të zhvillojmë aplikacione moderne të niveleve të ndryshme: duke filluar nga aplikacionet me një server që i shërbejnë një audiencë të vogël, e cila më vonë mund të zhvillohet në grupime deri në 50. -60 nyje, që mbarojnë me federatat e grupimeve. Kështu, qëllimi kryesor është maksimizimi i fitimeve duke ulur koston e zhvillimit dhe pronësinë e sistemit përfundimtar.
Le të theksojmë 4 kërkesat kryesore për sistemin përfundimtar:
- Сi orientuar nga ngjarjet.
Sistemi është gjithmonë i gatshëm të kalojë nëpër rrjedhën e ngjarjeve dhe të kryejë veprimet e nevojshme; - Мshkallëzueshmëria.
Blloqet individuale mund të shkallëzohen si vertikalisht ashtu edhe horizontalisht. I gjithë sistemi duhet të jetë i aftë për rritje të pafundme horizontale; - Оtoleranca ndaj gabimeve.
Të gjitha nivelet dhe të gjitha shërbimet duhet të jenë në gjendje të rikuperohen automatikisht nga dështimet; - Гkoha e garantuar e përgjigjes.
Koha është e vlefshme dhe përdoruesit nuk duhet të presin shumë gjatë.
E mbani mend përrallën e vjetër për "Motorin e vogël që mundi"? Në mënyrë që sistemi i projektuar të dalë me sukses nga faza e prototipit dhe të jetë progresiv, themeli i tij duhet të plotësojë kërkesat minimale SMOG.
Një pikë tjetër i shtohet mesazheve si një mjet infrastrukturor dhe bazë për të gjitha shërbimet: lehtësia e përdorimit për programuesit.
I orientuar nga ngjarjet
Që një aplikacion të rritet nga një server i vetëm në një grup, arkitektura e tij duhet të mbështesë lidhjen e lirë. Modeli asinkron plotëson këtë kërkesë. Në të, dërguesi dhe marrësi kujdesen për ngarkesën e informacionit të mesazhit dhe nuk shqetësohen për transmetimin dhe drejtimin brenda sistemit.
Shkallëzueshmëria
Shkallueshmëria dhe efikasiteti i sistemit janë pranë njëra-tjetrës. Komponentët e aplikacionit duhet të jenë në gjendje të përdorin të gjitha burimet e disponueshme. Sa më efikase të përdorim kapacitetin dhe sa më optimale të përdorim metodat tona të përpunimit, aq më pak para shpenzojmë për pajisje.
Brenda një makinerie të vetme, Erlang krijon një mjedis shumë konkurrues. Balanca midis konkurencës dhe paralelizmit mund të vendoset duke zgjedhur numrin e thread-ve të sistemit operativ të disponueshëm për Erlang VM dhe numrin e planifikuesve që përdorin këto thread.
Proceset Erlang nuk ndajnë gjendjen dhe funksionojnë në modalitetin jo-bllokues. Kjo siguron vonesë relativisht të ulët dhe xhiro më të lartë se aplikacionet tradicionale të bazuara në bllokim. Planifikuesi i Erlang siguron shpërndarje të drejtë të CPU dhe IO, dhe mungesa e bllokimit lejon që aplikacioni të përgjigjet edhe gjatë ngarkesave maksimale ose dështimeve.
Në nivel grupi, problemi me asgjësimin ekziston gjithashtu. Është e rëndësishme që të gjitha makinat në grup të jenë të ngarkuara në mënyrë të barabartë dhe që rrjeti të mos mbingarkohet. Le të imagjinojmë një situatë: trafiku i përdoruesve ulet në balancuesit në hyrje (haproxy, nginx, etj), ata shpërndajnë kërkesat e përpunimit sa më të barabartë të jetë e mundur midis grupit të backend-eve të disponueshme. Brenda infrastrukturës së aplikacionit, shërbimi që zbaton ndërfaqen e kërkuar është vetëm milja e fundit dhe do të duhet të kërkojë një numër shërbimesh të tjera për t'iu përgjigjur kërkesës fillestare. Kërkesat e brendshme gjithashtu kërkojnë drejtim dhe balancim.
Për të menaxhuar në mënyrë efektive rrjedhat e të dhënave, mesazhet duhet t'u ofrojnë zhvilluesve një ndërfaqe për të menaxhuar rrugëzimin dhe balancimin e ngarkesës. Falë kësaj, zhvilluesit do të jenë në gjendje, duke përdorur modele mikroshërbimesh (agregator, përfaqësues, zinxhir, degë, etj), të zgjidhin si problemet standarde ashtu edhe ato që dalin rrallë.
Nga pikëpamja e biznesit, shkallëzueshmëria është një nga mjetet e menaxhimit të rrezikut. Gjëja kryesore është të kënaqni kërkesat e klientëve duke përdorur në mënyrë optimale pajisjet:
- Kur fuqia e pajisjeve rritet si rezultat i progresit. Nuk do të jetë boshe për shkak të softuerit të papërsosur. Erlang shkallëzohet mirë vertikalisht dhe gjithmonë do të jetë në gjendje të përdorë të gjitha bërthamat e CPU-së 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.
toleranca ndaj gabimeve
Le të shqyrtojmë dy aksioma: "Dështimet janë të papranueshme" dhe "Gjithmonë do të ketë dështime". Për një biznes, dështimi i softuerit do të thotë humbje parash, dhe më e keqja, humbje e reputacionit. Duke balancuar midis humbjeve të mundshme dhe kostos së zhvillimit të softuerit tolerant ndaj gabimeve, shpesh mund të gjendet një kompromis.
Në afat të shkurtër, një arkitekturë që përfshin tolerancën ndaj gabimeve kursen para për blerjen e zgjidhjeve të grumbullimit jashtë raftit. Janë të shtrenjta dhe kanë edhe defekte.
Në terma afatgjatë, një arkitekturë toleruese ndaj gabimeve paguan shumë herë në të gjitha fazat e zhvillimit.
Mesazhimi brenda bazës së kodit ju lejon të përpunoni në detaje ndërveprimin e komponentëve brenda sistemit në fazën e zhvillimit. Kjo thjeshton detyrën e përgjigjes dhe menaxhimit të dështimeve, pasi të gjithë komponentët kritikë trajtojnë dështimet, dhe sistemi që rezulton e di se si të kthehet automatikisht në normalitet pas një dështimi sipas projektimit.
Përgjegjshmëri
Pavarësisht nga dështimet, aplikacioni duhet t'u përgjigjet kërkesave dhe të përmbushë SLA. Realiteti është se njerëzit nuk duan të presin, kështu që bizneset duhet të përshtaten në përputhje me rrethanat. Gjithnjë e më shumë aplikacione pritet të jenë shumë të përgjegjshme.
Aplikacionet e përgjegjshme funksionojnë pothuajse në kohë reale. Erlang VM funksionon në modalitetin e butë në kohë reale. Për disa fusha, të tilla si tregtimi i aksioneve, mjekësia dhe kontrolli i pajisjeve industriale, mënyra e vështirë në kohë reale është e rëndësishme.
Sistemet e përgjegjshme përmirësojnë UX dhe përfitojnë biznesin.
Përmbledhje paraprake
Kur planifikoja këtë artikull, doja të ndaja përvojën time për krijimin e një ndërmjetësi mesazhesh dhe ndërtimin e sistemeve komplekse të bazuara në të. Por pjesa teorike dhe motivuese doli të jetë mjaft e gjerë.
Në pjesën e dytë të artikullit, unë do të flas për nuancat e zbatimit të pikave të shkëmbimit, modelet e mesazheve dhe aplikimin e tyre.
Në pjesën e tretë do të shqyrtojmë çështjet e përgjithshme të organizimit të shërbimeve, rrugëzimit dhe balancimit. Le të flasim për anën praktike të shkallëzueshmërisë dhe tolerancës së gabimeve të sistemeve.
Fundi i pjesës së parë.
Photo Shoot .
Burimi: www.habr.com