Svet se neprestano menja. Napredak stvara nove tehnološke izazove. U skladu sa promenjenim zahtevima, arhitektura informacionih sistema takođe mora evoluirati. Danas ćemo govoriti o događajno orijentisanoj arhitekturi, konkurentnosti, paralelnosti, asinhronosti i o tome kako se u Erlangu može mirno živeti sa svim tim.
Uvod
U zavisnosti od veličine projektovanog sistema i zahteva, mi, programeri, biramo način razmene informacija u sistemu. U većini slučajeva, za organizaciju međusobnog delovanja servisa, radna verzija može biti šema sa brokerom, na primer zasnovana na RabbitMQ ili Kafka. Međutim, ponekad su tokovi događaja, SLA i nivo kontrole nad sistemom takvi da nam gotovi messaging nije dovoljan. Naravno, moguće je malo zakomplikovati sistem uzimajući odgovornost za transportni nivo i formiranje klastera, na primer korišćenjem ZeroMQ ili nanomsg. Ali ako sistemu odgovaraju propusnost i mogućnosti standardnog Erlang klastera, pitanje dodavanja dodatne entiteta zahteva detaljnu analizu i ekonomsko opravdanje.
Tema reaktivnih distribuiranih aplikacija je prilično opširna. Da bismo se uklopili u format članka, predmet današnje diskusije biće samo homogena okruženja, zasnovana na Erlangu/Elixiru. Ekosistem Erlang/OTP omogućava implementaciju reaktivne arhitekture uz minimalne troškove. Ali u svakom slučaju, biće nam potreban sloj za razmenu poruka.
Teorijska osnova
Projektovanje počinje definisanjem ciljeva i ograničenja. Glavni cilj nije da se razvija radi razvoja. Neophodno je dobiti bezbedan i skalabilan alat na osnovu kojeg se mogu stvarati, a što je najvažnije – razvijati savremene aplikacije različitih nivoa: počevši od jednoservernih aplikacija koje opslužuju mali broj korisnika, a koje se kasnije mogu razviti u klastere do 50-60 čvorova, završavajući sa federacijama klastera. Tako je osnovni cilj – maksimizacija profita smanjenjem troškova razvoja i vlasništva nad završnim sistemom.
Istaknut ćemo 4 glavna zahteva za konačni sistem:
- Zdogađajno orijentisanost.
Sistem je uvek spreman da propušta tok događaja i izvršava potrebne radnje; - Mširljivost.
Posamezni bloki se lahko širijo tako vertikalno kot horizontalno. Celoten sistem mora omogočati neomejeno horizontalno rast; - Odpornost na napake.
Vse ravni in vse storitve morajo imeti sposobnost samodejnega okrevanja ob napakah; - Zagotovljen čas odziva.
Čas je dragocen in uporabniki ne smejo predolgo čakati.
Spomnite se stare pravljice o "The little engine that could", ki se glasi – "Ponavadi, ki je zmogel"? Da bo načrtovani sistem uspešno prestopil iz prototipa v napreden izdelek, mora njegova osnova izpolnjevati minimalne zahteve. ZMOGEL.
K sporočanju kot infrastrukturnemu orodju in temelju za vse storitve je dodan še en element: uporabnost za programerje.
Usmerjenost k dogodkom
Da bi aplikacija lahko zrasla iz enega strežnika v grozd, mora arhitektura zagotavljati slabo povezanost. Ta zahteva ustreza asinhronemu modelu. V njem se pošiljatelj in prejemnik ukvarjata z informacijskim bremenom sporočila in se ne obremenjujeta s prenosom in usmerjanjem znotraj sistema.
Širljivost
Širljivost in učinkovitost sistema sta povezana. Komponente aplikacije morajo znati izkoristiti vse razpoložljive vire. Bolj učinkovito kot lahko izkoristimo moč in bolj optimizirane kot so naše metode obdelave, manj denarja porabimo za opremo.
Znotraj ene naprave Erlang ustvarja visoko konkurenčno okolje. Ravnotežje med konkurenco in paralelnostjo lahko nastavite z izbiro števila sistemskih nalog, ki so na voljo za Erlang VM, ter številom načrtovalnikov, ki izkoriščajo te naloge.
Erlang procesi nimajo skupnega stanja in delujejo v neblokirnem načinu. To zagotavlja razmeroma nizko latenco in višjo prepustnost kot pri tradicionalnih aplikacijah, zgrajenih na blokirni sinhronizaciji. Načrtovalnik Erlang skrbi za pošteno razporejanje CPU in IO, brez blokad pa omogoča aplikaciji, da odgovarja tudi med vrhunskimi obremenitvami ali napakami.
Na ravni klasterja obstajajo tudi težave z izkoriščanjem. Pomembno je, da so vse naprave v klasterju enakomerno obremenjene in da omrežje ni preobremenjeno. Predstavljajte si situacijo: uporabniški promet se prerazporedi na vhodne uravnoteževalnike (haproxy, nginx, itd.), ki enakomerno porazdelijo zahteve za obdelavo med razpoložljivimi backendi. V okviru infrastrukture aplikacije je storitev, ki izvaja zahtevani vmesnik, le zadnja mila in potrebovala bo še vrsto drugih storitev, da odgovori na prvotno zahtevo. Notranji zahtevki prav tako zahtevajo usmerjanje in uravnoteženje.
Za učinkovito upravljanje tokov podatkov mora messaging ponuditi razvijalcem vmesnik za upravljanje usmerjanja in porazdelitve obremenitve. Tako bodo lahko razvijalci, s pomočjo mikrostoritev (aggregator, proxy, chain, branch, itd.), reševali tako standardne naloge kot tudi redke.
Z vidika poslovanja je razširljivost eno od orodij za upravljanje tveganj. Ključnega pomena je zadovoljiti zahteve strank, medtem ko optimalno izkoriščamo opremo:
- Pri povečanju zmogljivosti opreme kot posledica napredka. Ne bo mirovala zaradi pomanjkljivosti programske opreme. Erlang se odlično razširja navpično in vedno lahko izkoristi vsa jedra CPU in razpoložljivo pomnilnik;
- V oblačnih okoljih lahko upravljamo s količino opreme glede na trenutno ali napovedano obremenitev in zagotavljamo SLA.
Odporna zasnova
Razmislimo o dveh aksiomih: "Napake so nesprejemljive" in "Napake se bodo vedno zgodile". Za podjetje je napaka programske opreme izguba denarja, kar je še huje – reputacije. Pri balansiranju med možnimi izgubami in stroški razvoja odpornosti programske opreme je pogosto mogoče najti kompromis.
Na kratki rok arhitektura, ki vključuje odpornost, prihrani denar pri nakupu že pripravljenih rešitev za klasterizacijo. Te so drage in tudi v njih so napake.
Na dolgi rok se odpornosti arhitektura večkrat povrne naložbe v njeno izvajanje v vseh fazah razvoja.
Sporazumevanje znotraj kodne baze je še v fazi razvoja, kar omogoča podrobno obravnavo interakcij komponent v sistemu. To poenostavi nalogo reagiranja in upravljanja z napakami, saj vse odgovorne komponente obravnavajo napake, končni sistem pa ve, kako se po napaki vrniti v normalno stanje po načrtu.
Odgovornost
Ne glede na napake mora aplikacija odgovarjati na zahteve in izpolnjevati SLA. Resničnost je takšna, da ljudje nočejo čakati, zato se mora podjetje prilagoditi. Od vse večjega števila aplikacij se pričakuje visoka odgovornost.
Odgovorne aplikacije delujejo v načinu, ki je blizu realnemu času. Erlang VM deluje v načinu mehke realnosti. Za nekatere področja, kot so borzno trgovanje, medicina, upravljanje industrijske opreme, je pomemben način ostre realnosti.
Odgovorni sistemi izboljšujejo uporabniško izkušnjo in so koristni za podjetja.
Predhodni povzetek
Ko sem načrtoval ta članek, sem želel deliti izkušnje pri ustvarjanju posrednika za sporočanje in gradnji zapletenih sistemov na njegovi osnovi. Vendar je teoretični in motivacijski del postal precej obsežen.
V drugem delu članka bom govoril o niansah implementacije izmenjevalnih točk, vzorcih izmenjave sporočil in njihovih aplikacijah.
V tretjem delu bomo obravnavali splošna vprašanja organizacije storitev, usmerjanja in uravnoteženja. Pogovarjali se bomo o praktičnih vidikih skalabilnosti in odpornosti sistemov.
Konec prvega dela.
Fotografija .
Izvor: habr.com
