Maailm ei seisa paigal. Edusammud loovad uusi tehnoloogilisi väljakutseid. Muutunud nõudmistega peab arenema ka info süsteemide arhitektuur. Täna räägime sündmustele suunatud arhitektuurist, konkurentsist, paralleelsusest, asünkroonsusest ja sellest, kuidas elada kõigi nendega harmooniliselt Erlangis.
Sissejuhatus
Sõltuvalt kavandatava süsteemi suurusest ja nõuetest valime me, arendajad, info vahetamise viisi süsteemis. Enamasti on teenuste omavaheline suhtlemine tööversioon, mis põhineb näiteks RabbitMQ või Kafka vahenditel. Kuid mõnikord on sündmustevool, SLA ja süsteemi kontrolli tase sellised, et valmis sõnumiedastus ei sobi meile. Muidugi, süsteemi on võimalik veidi keerulisemaks muuta, võttes vastutuse transportimisleveli ja klastrite loomise eest, kasutades näiteks ZeroMQ või nanomsg. Kuid kui süsteemi piisab tavalise Erlangi klastri läbilaskevõimest ja suutlikkusest, siis täiendava üksuse lisamise küsimus nõuab põhjalikku uurimist ja majanduslikku põhjendamist.
Reaktiivsete jaotatud rakenduste teema on üsna ulatuslik. Et jääda artikli formaati, on tänase arutelu objektiks ainult homogeenid keskkonnad, mis on loodud Erlang/Elixiri baasil. Erlang/OTP ökosüsteem võimaldab rakendada reaktiivset arhitektuuri minimaalsete tööjõukuludega. Kuid igal juhul vajame me sõnumite vahetamise taset.
Teoreetiline aluspõhi
Projekteerimine algab eesmärkide ja piirangute määratlemisest. Peamine eesmärk ei seisne arendamises enese pärast. Me peame saama turvalise ja skaleeritava tööriista, mille põhjal on võimalik luua ja mis kõige tähtsam – arendada kaasaegseid rakendusi erinevatel tasemetel: alates ühe serveriga lahendustest, mis teenindavad väikest publikut, kuni klastriteni, mis võivad kasvada kuni 50-60 sõlme, lõpetades klastri föderatsioonidega. Seega, peamine eesmärk on maksimaalse kasumi saavutamine, vähendades lõpp-süsteemi arendamise ja omamise kulusid.
Toome välja 4 peamist nõuet lõpp-süsteemile:
- Asündmusele suunatus.
Süsteem on alati valmis töötlema sündmustevoolu ja teostama vajalikke toiminguid; - Mskaalautuvus.
Erilised plokid saavad skaleeruda nii vertikaalselt kui ka horisontaalselt. Kogu süsteem peab toetama lõpmat horisontaalset kasvu; - Ottkestvuspõhimõte.
Kõik tasemed ja teenused peavad saama automaatselt taastuda tõrgete korral; - Garantiseeritud reageerimisaeg.
Aeg on väärtuslik ja kasutajad ei tohiks liiga kaua oodata.
Mäletate vana muinasjuttu "The little engine that could", tuntud ka kui "Paarovozik, который смог"? Et kavandatud süsteem saaks edukalt prototüübist edasi liikuda ja olla progresseeruv, peab selle alus vastama minimaalsetele nõuetele. SUUTIS.
Messaging’ule kui infrastruktuuri tööriistale ja kõigi teenuste alusele lisandub veel üks aspekt: programmeerijate kasutusmugavus.
Sündmustele orienteeritus
Et rakendus saaks kasvada ühest serverilt klastrist, peab selle arhitektuur tagama nõrga sidususe. Sellele nõudele vastab asünkroonne mudel. Sel puhul hoolitsevad saatja ja vastuvõtja sõnumi informatiivsete koormuste eest, muretsemata edastamise ja suunamise pärast süsteemis.
Skaleeritavus
Skaalautuvus ja süsteemi efektiivsus kõrvuti. Rakenduse komponendid peavad olema võimelised ära kasutama kõiki saadaval olevaid ressursse. Mida efektiivsemalt suudame ressursse kasutada ja mida optimaalsemad on meie töötlemismeetodid, seda vähem raha kulutame seadmetele.
Ühel masinal loob Erlang kõrge konkurentsivõime. Tasakaalu konkurentsi ja paralleelsuse vahel saab määrata, valides operatsioonisüsteemi jaoks Erlang VM-ile saadaval olevate lõime arvu ja nende lõimede seas jaotavate ajakava arv.
Erlang'i protsessid ei oma ühisteavet ja töötavad mitteblokeerivas režiimis. See tagab võrreldes traditsiooniliste rakendustega, mis põhinevad blokeerival sünkroniseerimisel, suhteliselt madala latentsuse ja kõrgema läbilaskevõime. Erlang'i ajakava hoolitseb CPU ja IO õiglase jaotamise eest, ning blokeerimise puudumine võimaldab rakendusel vastata isegi tipukoormuse või tõrgete ajal.
Klastri tasandil on probleemid ressursside kasutamisega samuti olemas. Oluline on, et kõik masinad klastris oleksid ühtlaselt koormatud ning võrk ei oleks üle koormatud. Kujutame ette olukorda: kasutajate liiklus jõuab sisse minevatesse koormuse jaotajatesse (haproxy, nginx jne), need jaotavad taotlused võimalikult ühtlaselt töötlemiseks kätte saadavale taustteenuste hulgale. Rakenduse infrastruktuuris on teenus, mis rakendab vajalikku liidest, ainult viimane etapp, ja tal on vaja esialgse taotluse vastamiseks paluda mitmeid teisi teenuseid. Sisemised taotlused vajavad samuti suunamist ja koormuse jaotamist.
Andmevoogude tõhusaks haldamiseks peab sõnumside pakkuma arendajatele liidese koormuse ja marsruudi haldamiseks. Sel moel saavad arendajad kasutada mikroteenuste mustreid (aggregator, proxy, chain, branch jne) nii tavaliste kui ka haruldaste ülesannete lahendamiseks.
Äripoolest vaadates on skaleeritavus üks riskide juhtimise tööriistadest. Peamine on rahuldada klientide nõudmised, kasutades varustust optimaalselt:
- Varustuse võimsuse suurenemise tõttu tehnoloogia edenemisel. See ei seisa tühjalt tarkvara puudulikkuse tõttu. Erlang skaleerub suurepäraselt vertikaalselt ja suudab alati kasutada ära kõik CPU tuumad ja saadaval mälu;
- Pilvekeskkondades saame juhtida varustuse hulka vastavalt hetke või prognoositud koormusele ja tagada SLA.
Talitluskatkestustunne
Käsitleme kahte aksioomi: “Tõrked on vastuvõetamatud” ja “Tõrked on alati olemas”. Äriühingu jaoks tähendab tarkvara tõrge rahakaotust, veelgi halvem – reputatsiooni. Tõrketaluvate tarkvarade arendamise võimalike kaotuste ja kulude vahel tasakaalu otsides saab sageli leida kompromissi.
Lühiajaliselt hoiab tõrketaluv arhitektuur kokku raha valmis klasterlahenduste ostmiselt. Need on kallid ja need sisaldavad samuti vigu.
Pikemas perspektiivis katab tõrketaluv arhitektuur nõudmistele vastamise kulud kõikides arenguetappides mitu korda.
Sõnumiedastus koodibaasis, mis on endiselt arendusetapis, võimaldab süvitsi minna komponentide vahelisse suhtlemisse süsteemi sees. See lihtsustab tasku tõrgete reageerimist ja haldamist, kuna kõik vastutavad komponendid käsitlevad tõrkeid, ja lõppkokkuvõttes teab süsteem, kuidas disaini järgi automaatselt taastuda tavapärasesse seisundisse tõrke järel.
Reageerimisvõime
Sõltumata tõketest peab rakendus vastama päringutele ja rahuldama SLA-d. Fakt on see, et inimesed ei soovi oodata, seega peab äri kohanduma. Üha enam oodatakse rakendustelt kõrget reageerimisvõimet.
Reageerivad rakendused töötavad peaaegu reaalajas. Erlang VM töötab pehme reaalaja režiimis. Mõnedes valdkondades, nagu börsikaubandus, meditsiin ja tööstusseadmete haldamine, on oluline range reaalaja režiim.
Reageerivad süsteemid parandavad UX-i ja on ettevõttele kasulikud.
Eelkokkuvõte
Selle artikli kirjutamisel tahtsin jagada kogemusi sõnumite vahetuse maaklerite loomisel ja keerukate süsteemide ülesehitamisel selle baasil. Kuid teoreetiline ja motiveeriv osa osutus üsna ulatuslikuks.
Artikli teises osas räägin vahetuspunktide rakendamise nüanssidest, sõnumivahetuse mustritest ja nende rakendamisest.
Kolmandas osas vaatleme teenuste korraldamise, marsruutimise ja koormuse tasakaalu üldküsimusi. Räägime praktilisest küljest süsteemide skaleeritavuse ja tõrkekindluse osas.
Esimese osa lõpp.
Foto .
Allikas: habr.com
