Mundua ez dago geldirik. Aurrerapenak erronka teknologiko berriak sortzen ditu. Eskakizun aldakorren arabera, informazio sistemen arkitekturak eboluzionatu behar du. Gaur ekitaldiak gidatutako arkitekturaz, aldiberekotasunaz, aldiberekotasunaz, asinkroniaz eta Erlangen guzti honekin lasai bizi zaitezkeen inguruan hitz egingo dugu.
Sarrera
Diseinatutako sistemaren tamainaren eta haren eskakizunen arabera, garatzaileek sisteman informazioa trukatzeko metodoa aukeratzen dugu. Kasu gehienetan, zerbitzuen elkarrekintza antolatzeko, lan-aukera bat izan daiteke broker batekin eskema bat, adibidez, RabbitMQ edo kafka-n oinarrituta. Baina, batzuetan, gertaeren fluxua, SLA eta sistemaren kontrol-maila prest dauden mezularitza ez da egokia guretzat. Jakina, sistema apur bat zaildu dezakezu garraio-geruzaren eta klusterren eraketaren ardura hartuz, adibidez ZeroMQ edo nanomsg erabiliz. Baina sistemak Erlang kluster estandar baten errendimendu eta gaitasun nahikoa baditu, orduan entitate gehigarri bat sartzeko gaiak azterketa zehatza eta justifikazio ekonomikoa behar ditu.
Banatutako aplikazio erreaktiboen gaia nahiko zabala da. Artikuluaren formatuan mantentzeko, gaurko eztabaidaren gaia Erlang/Elixir-en gainean eraikitako ingurune homogeneoak baino ez dira izango. Erlang/OTP ekosistemak arkitektura erreaktiboa ezartzea ahalbidetzen du esfortzu txikienarekin. Baina, nolanahi ere, mezularitza-geruza bat beharko dugu.
Oinarri teorikoa
Diseinua helburuak eta mugak zehazten hasten da. Helburu nagusia ez da garapenaren arloan garapenaren mesedetan. Tresna seguru eta eskalagarri bat lortu behar dugu, zeinaren oinarrian hainbat mailatako aplikazio modernoak sortu eta, batez ere, garatu ahal izateko: zerbitzari bakarreko aplikazioetatik hasita, publiko txiki baten zerbitzura daudenak, gerora 50era arteko kluster bihur daitezkeenak. -60 nodo, kluster federazioekin amaitzen direnak. Horrela, helburu nagusia irabaziak maximizatzea da, garapenaren kostua eta azken sistemaren jabetza murriztuz.
Azpimarratu ditzagun azken sistemarako 4 baldintza nagusi:
- Π‘ekitaldietara zuzenduta.
Sistema beti prest dago gertaeren fluxua pasatzeko eta beharrezko ekintzak egiteko; - Πeskalagarritasuna.
Banakako blokeak bertikalean zein horizontalean eskala daitezke. Sistema osoak hazkunde horizontal infiniturako gai izan behar du; - Πakatsen tolerantzia.
Maila guztiek eta zerbitzu guztiek hutsegiteetatik automatikoki berreskuratu ahal izan behar dute; - Πerantzun denbora bermatua.
Denbora baliotsua da eta erabiltzaileek ez dute gehiegi itxaron behar.
Gogoratzen al duzu "The little engine that could"-ri buruzko maitagarrien ipuin zaharra? Diseinatutako sistema prototipoaren fasetik arrakastaz irten eta progresiboa izan dadin, bere oinarriak gutxieneko baldintzak bete behar ditu. SMOG.
Mezularitzari beste puntu bat gehitzen zaio azpiegitura tresna gisa eta zerbitzu guztien oinarri gisa: programatzaileentzat erabiltzeko erraztasuna.
Ekitaldietara zuzendua
Aplikazio bat zerbitzari bakar batetik kluster izatera hazteko, bere arkitekturak akoplamendu solteak onartu behar ditu. Eredu asinkronoak baldintza hori betetzen du. Bertan, igorleak eta hartzaileak mezuaren informazio-kargaz arduratzen dira eta ez dira kezkatzen sistemaren barruko transmisioaz eta bideratzeaz.
Eskalagarritasuna
Eskalagarritasuna eta sistemaren eraginkortasuna elkarren ondoan daude. Aplikazioaren osagaiek eskuragarri dauden baliabide guztiak erabiltzeko gai izan behar dute. Zenbat eta modu eraginkorragoan erabili ahalmena eta gure prozesatzeko metodo hobeagoak, orduan eta diru gutxiago gastatzen dugu ekipoetan.
Makina bakar baten barruan, Erlang-ek ingurune oso lehiakorra sortzen du. Aldiberetasuna eta paralelismoaren arteko oreka ezar daiteke Erlang VM-rako eskuragarri dauden sistema eragileen hari kopurua eta hari horiek erabiltzen dituzten programatzaileen kopurua aukeratuz.
Erlang prozesuek ez dute egoera partekatzen eta blokeorik gabeko moduan funtzionatzen dute. Horrek latentzia nahiko baxua eta blokeoetan oinarritutako aplikazio tradizionalek baino errendimendu handiagoa eskaintzen du. Erlang-en programatzaileak PUZaren eta IOaren esleipen zuzena bermatzen du, eta blokeorik ezak aplikazioari erantzuteko aukera ematen du karga gailurretan edo hutsegiteetan ere.
Kluster mailan, botatzeko arazoa ere badago. Garrantzitsua da klusterreko makina guztiak berdin kargatuta egotea eta sarea gainkargatuta ez egotea. Imajina dezagun egoera bat: erabiltzaileen trafikoa sarrerako orekatzaileetara heltzen da (haproxy, nginx, etab.), prozesatzeko eskaerak ahalik eta modu berdinean banatzen dituzte eskuragarri dauden backend multzoen artean. Aplikazio-azpiegituren barruan, beharrezko interfazea inplementatzen duen zerbitzua azken kilometroa baino ez da eta beste zerbitzu batzuk eskatu beharko ditu hasierako eskaerari erantzuteko. Barne-eskaerek bideratzea eta orekatzea ere eskatzen dute.
Datu-fluxuak modu eraginkorrean kudeatzeko, mezularitzak garatzaileei interfaze bat eskaini behar die bideraketa eta karga orekatzea kudeatzeko. Horri esker, garatzaileek gai izango dute, mikrozerbitzuen ereduak erabiliz (agregatzailea, proxy, katea, adarra, etab.), arazo estandarrak zein gutxitan sortzen direnak konpontzeko.
Negozioaren ikuspuntutik, eskalagarritasuna arriskuak kudeatzeko tresnetako bat da. Garrantzitsua da bezeroen eskaerak asetzea ekipamendu egokia erabiliz:
- Aurrerapenaren ondorioz ekipoen potentzia handitzen denean. Ez da inaktibo egongo software inperfektua dela eta. Erlang-ek ondo eskalatzen du bertikalki eta beti erabili ahal izango ditu CPU-nukleo guztiak eta eskuragarri dagoen memoria;
- Hodei-inguruneetan, egungo edo aurreikusitako kargaren arabera ekipamendu kopurua kudeatu eta SLA bermatu dezakegu.
akatsen tolerantzia
Har ditzagun bi axioma: βPorrotak onartezinak diraβ eta βBeti egongo dira porrotakβ. Negozio batentzat, softwarearen hutsegiteak dirua galtzea esan nahi du, eta okerragoa dena, ospea galtzea. Balizko galerak eta akatsak jasan ditzakeen softwarea garatzearen kostuaren arteko oreka eginez, askotan konpromezu bat aurki daiteke.
Epe laburrean, akatsen tolerantzia barne hartzen duen arkitektura batek dirua aurrezten du apalategiko clustering irtenbideak erosteko. Garestiak dira eta akatsak ere badituzte.
Epe luzera, akatsekiko tolerantzia duen arkitektura batek bere burua askotan ordaintzen du garapenaren fase guztietan.
Kode-oinarriaren barneko mezularitzak garapen-fasean sistemaren osagaien elkarrekintza zehatz-mehatz lantzeko aukera ematen du. Honek hutsegiteak erantzuteko eta kudeatzeko zeregina errazten du, osagai kritiko guztiek akatsak kudeatzen dituztelako, eta ondorioz sistemak badaki diseinuaren arabera hutsegite baten ondoren automatikoki normaltasunera itzultzen.
Erantzunkortasuna
Hutsegiteak gorabehera, aplikazioak eskaerei erantzun eta SLA bete behar du. Errealitatea da jendeak ez duela itxaron nahi, beraz, negozioak horren arabera egokitu behar dira. Gero eta aplikazio gehiago erantzun handikoak izango direla espero da.
Aplikazio sentikorrak ia denbora errealean funtzionatzen dute. Erlang VM denbora errealeko moduan funtzionatzen du. Arlo batzuetarako, esate baterako, akzioen merkataritza, medikuntza eta ekipamendu industrialen kontrola, garrantzitsua da denbora errealeko modu gogorra.
Responsive sistemek UX hobetzen dute eta negozioari mesede egiten diote.
Aurretiazko laburpena
Artikulu hau planifikatzerakoan, mezularitza-artekari bat sortzeko eta horretan oinarritutako sistema konplexuak eraikitzeko esperientzia partekatu nahi nuen. Baina atal teorikoa eta motibazioa nahiko zabala izan zen.
Artikuluaren bigarren zatian, truke-puntuak ezartzeko Γ±abardurei, mezularitza-ereduei eta haien aplikazioari buruz hitz egingo dut.
Hirugarren zatian zerbitzuak antolatzeko, bideratzeko eta orekatzeko gai orokorrak aztertuko ditugu. Hitz egin dezagun sistemen eskalagarritasunaren eta akatsen tolerantziaren alde praktikoari buruz.
Lehen zatiaren amaiera.
Photo Shoot .
Iturria: www.habr.com