Svijet se ne zaustavlja. Napredak stvara nove tehnološke izazove. U skladu s promijenjenim zahtjevima, mora evoluirati i arhitektura informatičkih sustava. Danas ćemo govoriti o arhitekturi orijentiranoj na događaje, konkurentnosti, paralelnosti, asinkronosti i o tome kako se u Erlangu može mirno živjeti s tim.
Uvod
Ovisno o veličini projektiranog sustava i njegovim zahtjevima, mi, programeri, biramo način razmjene informacija unutar sustava. U većini slučajeva, za organizaciju interakcije servisa radna opcija može biti shema s posrednikom, primjerice baziranom na RabbitMQ ili Kafka. No ponekad su tokovi događaja, SLA i razina kontrole nad sustavom takvi da nam gotovi messaging ne odgovara. Naravno, možemo malo zakomplicirati sustav preuzimanjem odgovornosti za transportnu razinu i formiranje klastera, primjerice korištenjem ZeroMQ ili nanomsg. Ali ako sustavu dovoljno propusnosti i mogućnosti standardnog Erlang klastera, pitanje uvođenja dodatne entitete zahtijeva detaljnu analizu i ekonomsku opravdanost.
Tema reaktivnih distribuiranih aplikacija je prilično opsežna. Kako bismo se uklopili u format članka, predmet današnje rasprave bit će samo homogena okruženja izgrađena na osnovi Erlang/Elixir. Ekosustav Erlang/OTP omogućuje implementaciju reaktivne arhitekture s minimalnim troškovima rada. No u svakom slučaju, trebat će nam sloj za razmjenu poruka.
Teorijska osnova
Projektiranje počinje određivanjem ciljeva i ograničenja. Glavni cilj nije u razvoju radi razvoja. Moramo dobiti siguran i skalabilan alat na osnovu kojeg se mogu stvoriti, a što je najvažnije – razvijati moderne aplikacije različitih razina: počevši od jednoservernih, koji služe maloj publici, a koji se kasnije mogu razviti u klastere do 50-60 čvorova, do federacija klastera. Tako je osnovni cilj maksimizacija profita smanjenjem troškova razvoja i vlasništva konačnog sustava.
Istaknimo 4 glavna zahtjeva za konačni sustav:
- Sorijentiranost na događaje.
Sustav je uvijek spreman propuštati kroz sebe tok događaja i poduzimati potrebne radnje; - Mskalabilnost.
Odvojeni blokovi mogu se skalirati vertikalno i horizontalno. C cijeli sustav treba imati mogućnost beskonačnog horizontalnog rasta; - ootpornost na greške.
Sve razine i sve usluge trebaju imati mogućnost automatskog oporavka u slučaju grešaka; - Garanitano vrijeme odgovora.
Vrijeme je dragocjeno i korisnici ne bi trebali predugo čekati.
Sjetite se stare bajke o "Malom lokomotivu koji je mogao", onome – "Parovoziku koji je uspio"? Da bi projektirani sustav uspješno prešao iz faze prototipa u progresivan, njegov temelj mora zadovoljiti minimalne zahtjeve. USPIO.
K messaging kao infrastrukturnom alatu i temelju za sve usluge dodaje se još jedna stavka: jednostavnost korištenja za programere.
usmjerenost na događaje
Da bi aplikacija mogla rasti iz jednog poslužitelja u klaster, njezina arhitektura mora omogućiti slabu povezanost. Ovom zahtjevu odgovara asinkrona model. U njemu pošiljatelj i primatelj brinu o informacijskom opterećenju poruke i ne brinu se o prijenosu i usmjeravanju unutar sustava.
Skalabilnost
Skalabilnost i učinkovitost sustava idu ruku pod ruku. Komponenti aplikacije trebaju moći iskoristiti sve dostupne resurse. Što učinkovitije možemo iskoristiti kapacitete i što optimalniji su naši načini obrade, to manje trošimo novca na opremu.
U okviru jedne mašine Erlang stvara visoko konkurentno okruženje. Ravnotežu između konkurentnosti i paralelizma može se postaviti izborom broja niti operativnog sustava dostupnih za Erlang VM i brojem planera koji koriste te niti.
Erlang procesi nemaju zajedničko stanje i rade u neblokirajućem modu. To osigurava relativno nisku latenciju i veću propusnost nego kod tradicionalnih aplikacija temeljenih na blokirajućem sinkroniziranju. Planer Erlang se brine o pravednoj raspodjeli CPU-a i IO-a, a izostanak zaključavanja omogućava aplikaciji da odgovara čak i u režimu vršnih opterećenja ili grešaka.
Na razini klastera problem s iskorištenjem također postoji. Važno je da su svi strojevi u klasteru ravnomjerno opterećeni, a mreža nije preopterećena. Zamislite situaciju: korisnički promet dolazi na ulazne balansere (haproxy, nginx, itd.), koji maksimalno ravnomjerno raspoređuju zahtjeve za obradu između skupa dostupnih backendova. Unutar infrastrukture aplikacije, usluga koja implementira traženi sučelje – to je samo posljednja milja, i morat će zatražiti niz drugih usluga kako bi odgovorila na prvotni zahtjev. Interni zahtjevi također zahtijevaju usmjeravanje i balansiranje.
Da bi se učinkovito upravljalo protokom podataka, messaging mora omogućiti programerima sučelje za upravljanje usmjeravanjem i raspodjelom opterećenja. Zahvaljujući tome, programeri će moći, koristeći mikroservisne uzorke (aggregator, proxy, chain, branch, itd.), rješavati kako standardne zadatke, tako i rijetko javljajuće.
S poslovne strane, skalabilnost je jedan od alata za upravljanje rizicima. Ključno je zadovoljiti zahtjeve klijenata, optimalno koristeći opremu:
- Povećanjem snage opreme kao rezultat napretka. Neće stajati zbog nesavršenosti softvera. Erlang se odlično skalira vertikalno i uvijek može iskoristiti sve jezgre CPU-a i dostupnu memoriju;
- U uvjetima cloud okruženja, možemo upravljati brojem opreme ovisno o trenutnom ili predviđenom opterećenju i jamčiti SLA.
Otpornost na greške
Razmotrimo dvije aksiome: “Neuspjesi su neprihvatljivi” i “Neuspjesi će uvijek postojati”. Za poslovanje, neuspjeh softvera predstavlja gubitak novca, a što je još gore – reputacije. Balansirajući između mogućih gubitaka i troškova razvoja otpornog softvera, često se može pronaći kompromis.
U kratkoročnoj perspektivi, arhitektura koja uključuje otpornost na neuspjehe štedi novac na kupnji gotovih rješenja za klasteriranje. Ona su skupa, a i sama sadrže greške.
Dugoročno, arhitektura otpornosti na neuspjehe više puta isplati troškove svoje primjene u svim fazama razvoja.
Messaging unutar baze koda još je u fazi razvoja, što omogućuje detaljno razrađivanje interakcije komponenti unutar sustava. Time se olakšava zadatak reagiranja i upravljanja kvarovima, jer sve odgovorne komponente obrađuju kvarove, a konačni sustav zna kako se automatski vratiti u normalno stanje nakon kvara po dizajnu.
Odgovornost
Neovisno o kvarovima, aplikacija mora odgovarati na zahtjeve i zadovoljiti SLA. Stvarnost je takva da ljudi ne žele čekati, stoga se posao mora prilagoditi. Od sve većeg broja aplikacija očekuje se visoka odgovornost.
Odgovorne aplikacije rade u režimu koji je blizu stvarnom vremenu. Erlang VM funkcionira u režimu mekog stvarnog vremena. Za neka područja, poput burzovne trgovine, medicine, upravljanja industrijskom opremom, važan je režim tvrdog stvarnog vremena.
Odgovorni sustavi poboljšavaju UX i korisni su za posao.
Preliminarni zaključak
Planirajući ovaj članak, htio sam podijeliti iskustvo stvaranja posrednika za razmjenu poruka i izgradnji složenih sustava na toj osnovi. No teorijski i motivacijski dio ispao je prilično opširan.
U drugom dijelu članka govorit ću o nijansama implementacije razmjenjivačnih točaka, obrascima razmjene poruka i njihovoj primjeni.
U trećem dijelu razmotrit ćemo opća pitanja organizacije servisa, usmjeravanja i raspodjele opterećenja. Razgovarat ćemo o praktičnim aspektima skalabilnosti i otpornosti sustava.
Kraj prvog dijela.
Fotografija .
Izvor: habr.com
