Maailm ei seisa paigal. Edusammud loovad uusi tehnoloogilisi väljakutseid. Muutunud nõudmistega peab arenema ka infotehnoloogia arhitektuur. Täna räägime sündmustele orienteeritud arhitektuurist, konkurentsist, paralleelsusest, asünkroonsusest ja sellest, kuidas Erlangiga kõiki neid aspekte rahumeelselt käsitleda.
Sissejuhatus
Sõltuvalt projekteeritava süsteemi suurusest ja nõudmistest valime meie, arendajad, teabevahetuse viisi süsteemis. Enamasti on teenuste vahelise suhtluse korraldamiseks sobiv lahendus näiteks brokeripõhine skeem, nagu RabbitMQ või Kafka. Kuid mõnikord on sündmuste voog, SLA ja kontrollitase süsteemis selline, et valmis sõnumitoomine ei sobi. Loomulikult on võimalik süsteemi veidi keerulisemaks muuta, võttes vastutuse transporditasandi ja klastrite loomise eest, näiteks kasutades ZeroMQ või nanomsg. Kuid kui süsteemi standardse Erlangi klastrite läbilaskevõime ja võimalused on piisavad, siis täiendava üksuse lisamise küsimus nõuab põhjalikku uurimist ja majanduslikku põhjendust.
Reaktiivsete jaotatud rakenduste teema on üsna ulatuslik. Käesoleva artikli raamides käsitleme ainult homogeenseid keskkondi, mis põhinevad Erlang/Elixir. Erlang/OTP ökosüsteem võimaldab reaktiivset arhitektuuri rakendada minimaalsete töökuludega. Siiski on meil vaja suhtlemise kihti.
Teoreetiline alus
Projektimine algab eesmärkide ja piirangute määratlemisest. Peamine eesmärk ei seisne arendamises iseenesest. Me peame looma turvalise ja skaleeritava tööriista, mille alusel on võimalik luua ja mis kõige tähtsam – arendada kaasaegseid rakendusi erinevatel tasanditel: alates üheserverilistest, mis teenindavad väikest publikume, mis võivad hiljem areneda klastriteks kuni 50-60 sõlme, kuni klastrite föderatsioonideni. Seega on peamine eesmärk kasumi maksimeerimine arendus- ja omamiskulude vähendamise kaudu.
Toome välja 4 peamist nõuet lõpp-süsteemile:
- Csündmuspõhisus.
Sisene on alati valmis edastama sündmuste voogu ja teostama vajalikke toiminguid; - Mõõtlemine.
Eraldi plokke saab skaleerida nii vertikaalselt kui ka horisontaalselt. Kogu süsteem peab olema võimeline lõpmatuks horisontaalseks kasvuks; - Umbesrikketaluvus.
Kõik tasemed ja teenused peavad olema võimelised automaatselt taastuma tõrgete korral; - Garantiseeritud reageerimisaeg.
Aeg on väärtuslik ja kasutajad ei tohiks liiga kaua oodata.
Kas tead vana muinasjuttu „The little engine that could”, ka tuntud kui „Paarovozik, kes suutis”? Et projekteeritav süsteem suudaks edukalt prototüübist välja tulla ja olla edumeelne, peab selle alus vastama minimaalsetele nõudmistele SUUTIS.
Sõnumite edastamine kui infrastruktuuri tööriist ja teenuste põhialus lisab veel ühe punkti: kasutusmugavus arendajatele.
Sündmustele orienteeritus
Et rakendus saaks kasvada ühest serverid Klastri jaoks peab selle arhitektuur tagama nõrga seotuse. Sellele nõudele vastab asünkrooniline mudel. Selles mudelis muretsevad saatja ja saaja teate infokoormuse pärast, kuid nad ei pea muretsema sõnumi edastamise ja marsruutimise üle süsteemis.
Skaleeritavus
Süsteemi skaleeritavus ja efektiivsus käivad käsikäes. Rakenduse komponendid peavad suutma kasutada kõiki saadaval olevaid ressursse. Mida tõhusamalt suudame neid ressursse kasutada ja mida optimaalsemad on meie töötlemismeetodid, seda vähem raha kulutame varustusele.
Ühe masina raames loob Erlang kõrge konkurentsikeskkonna. Konkurentsi ja paralleelsuse vaheline tasakaal saab määrata operatsioonisüsteemi saadaval olevate lõimede arvu ja nende lõimede kasutavate ajakava määratlemise kaudu.
Erlang'i protsessidel ei ole ühist olekut ja need töötavad mittesahnivas režiimis. See tagab võrreldes traditsiooniliste blokeerivate sünkroonimise alusel loodud rakendustega suhteliselt madala latentsuse ja kõrgema läbilaskevõime. Erlang'i ajakava hoolitseb õiglasest CPU ja IO jaotamisest ning lukustuste puudumine võimaldab rakendusel vastata isegi tipukoormuse või rike ajal.
Klastri tasandil eksisteerib probleem ka ressursikasutuses. On oluline, et kõik masinad klastris oleksid ühtlaselt koormatud ja võrk ei oleks ülekoormatud. Kujutame ette olukorda: kasutaja liiklus jõuab sissetulevatesse tasakaalustajatesse (haproxy, nginx jne), mis jaotavad päringud töötlemiseks võimalikult ühtlaselt saadaval olevate tagapooltade vahel. Rakenduse infrastruktuuris teenus, mis rakendab vajalikku liidest, on vaid viimane miil ning tal tuleb esmase päringu vastamiseks küsida mitmeid teisi teenuseid. Siseriiklikud päringud vajavad samuti marsruutimist ja tasakaalustamist.
Andmete voo tõhusaks juhtimiseks peab sõnumite edastamine pakkuma arendajatele liidese koormuse ja marsruutimise haldamiseks. Sel viisil saavad arendajad, kasutades mikroteenuste mustreid (aggregator, proxy, chain, branch jne), lahendada nii tavalisi ülesandeid kui ka harva esinevaid.
Äriperspektiivist on skaleeritavus üks riskijuhtimise tööriistu. Peamine on rahuldada klientide nõudmisi, optimaalselt kasutades varustust:
- Seoses seadmete võimsuse suurenemisega läbi edusammude ei jää see seisma tarkvara ebatäiuslikkuse tõttu. Erlang suudab suurepäraselt vertikaalselt skaleeruda ja suudab alati kasutada kõiki CPU tuumasid ja saadaval olevaid mälusid;
- Pilvandmetöötlus keskkondades saame juhtida varustuse hulka sõltuvalt praegusest või prognoositavast koormusest ning tagada SLA.
Veadeta töö
Vaatleme kahte aksioomi: "Rikked on lubamatud" ja "Rikked juhtuvad alati". Äri jaoks tähendab tarkvara riknemine rahakaotust ja veelgi hullem, maine kaotust. Otsides tasakaalu võimalike kaotuste ja tõrketaluvate tarkvara arendamise kulude vahel, võib sageli leida kompromissi.
Lühiajaliselt säästab arhitektuur, mis sisaldab usaldusväärsuse tagamist, raha valmis klasterdamise lahenduste ostmisel. Need on kallid ja neidki iseloomustavad vead.
Pikaajaliselt tasub usaldusväärne arhitektuur end korduvalt ära oma rakenduskuludega kogu arenduse vältel.
Sõnumite edastamine koodibaasis juba arenduse faasis võimaldab põhjalikult läbi mõelda komponentide koostöö süsteemis. See lihtsustab reageerimise ja rikkehaldamise ülesannet, kuna kõik vastutavad komponendid töötlevad rikkeid ning lõpp-süsteem teab, kuidas automaatselt pärast riket tagasi normaalsesse olekusse naasta by design.
Reageerimisvõime
Olenemata rikete olemasolust peab rakendus vastama päringutele ja rahuldama SLA-d. Tõde on see, et inimesed ei soovi oodata, seetõttu peab äri sellele kohanema. Üha rohkemalt rakendustelt oodatakse kõrget reageerimisvõimet.
Reageerivad rakendused töötavad peaaegu reaalajas. Erlang VM töötab pehme reaalaja režiimis. Mõnes valdkonnas, nagu börsikaubandus, meditsiin ja tööstusseadmete haldamine, on ranget reaalajarežiimi oluline.
Reageerivad süsteemid parandavad kasutajakogemust ja on ettevõtetele kasulikud.
Esialgne kokkuvõte
Selle artikli kirjutamisel tahtsin jagada oma kogemusi sõnumivahetussüsteemi loomisel ja keerukate süsteemide arendamisel selle põhjal. Kuid teoreetiline ja motiveeriv osa tuli üsna mahukas.
Artikli teises osas räägin vahetuspunktide elluviimise nüanssidest, sõnumivahetuse mallidest ja nende rakendamisest.
Kolmandas osas käsitleme teenuste, marsruutimise ja tasakaalustamise üldküsimusi. Räägime praktilisest küljest skaleeritavuse ja tõrketaluvuse süsteemides.
Esimese osa lõpp.
Foto .
Allikas: habr.com
