Svijet ne miruje. Napredak stvara nove tehnološke izazove. U skladu s promjenjivim zahtjevima, arhitektura informacijskih sustava mora se razvijati. Danas ćemo govoriti o arhitekturi vođenoj događajima, konkurentnosti, konkurentnosti, asinkroniji i kako možete mirno živjeti sa svim tim u Erlangu.
Uvod
Ovisno o veličini projektiranog sustava i zahtjevima za njim, mi programeri biramo način razmjene informacija u sustavu. U većini slučajeva, za organiziranje interakcije usluga, radna opcija može biti shema s brokerom, na primjer, na temelju RabbitMQ ili kafka. Ali ponekad su tijek događaja, SLA i razina kontrole nad sustavom takvi da nam gotove poruke nisu prikladne. Naravno, možete malo zakomplicirati sustav preuzimanjem odgovornosti za transportni sloj i formiranje klastera, na primjer koristeći ZeroMQ ili nanomsg. Ali ako sustav ima dovoljno propusnosti i mogućnosti standardnog Erlang klastera, tada pitanje uvođenja dodatnog entiteta zahtijeva detaljnu studiju i ekonomsku opravdanost.
Tema reaktivnih distribuiranih aplikacija prilično je široka. Kako bismo ostali unutar formata članka, predmet današnje rasprave bit će samo homogena okruženja izgrađena na Erlangu/Elixiru. Erlang/OTP ekosustav omogućuje implementaciju reaktivne arhitekture uz najmanje napora. Ali u svakom slučaju, trebat će nam sloj poruka.
Teorijska osnova
Dizajn počinje definiranjem ciljeva i ograničenja. Glavni cilj nije u području razvoja radi razvoja. Moramo nabaviti siguran i skalabilan alat na temelju kojeg možemo kreirati i, što je najvažnije, razvijati suvremene aplikacije različitih razina: počevši od jednoposlužiteljskih aplikacija za malu publiku, koje se kasnije mogu razviti u klastere do 50 -60 čvorova, završavajući s federacijama klastera. Stoga je glavni cilj maksimiziranje profita smanjenjem troškova razvoja i vlasništva nad konačnim sustavom.
Istaknimo 4 glavna zahtjeva za konačni sustav:
- Сorijentiran na događaje.
Sustav je uvijek spreman proći kroz tok događaja i izvršiti potrebne akcije; - Мskalabilnost.
Pojedinačni blokovi mogu se skalirati okomito i vodoravno. Cijeli sustav mora biti sposoban za beskonačni horizontalni rast; - Оtolerancija kvarova.
Sve razine i sve usluge trebale bi se moći automatski oporaviti od kvarova; - Гzajamčeno vrijeme odziva.
Vrijeme je dragocjeno i korisnici ne bi trebali predugo čekati.
Sjećate li se stare bajke o “Malom motoru koji je mogao”? Kako bi dizajnirani sustav uspješno izašao iz faze prototipa i bio progresivan, njegova osnova mora zadovoljiti minimalne zahtjeve SMOG.
Još jedna točka dodana je porukama kao infrastrukturnom alatu i osnovi za sve usluge: jednostavnost korištenja za programere.
Orijentiran na događaje
Da bi aplikacija prerasla iz jednog poslužitelja u klaster, njena arhitektura mora podržavati labavo povezivanje. Asinkroni model ispunjava ovaj zahtjev. U njemu se pošiljatelj i primatelj brinu o informacijskom opterećenju poruke i ne brinu o prijenosu i usmjeravanju unutar sustava.
Skalabilnost
Skalabilnost i učinkovitost sustava su jedna pored druge. Komponente aplikacije moraju moći koristiti sve raspoložive resurse. Što učinkovitije možemo iskoristiti kapacitet i što su naše metode obrade optimalnije, to manje novca trošimo na opremu.
Unutar jednog stroja Erlang stvara visoko konkurentno okruženje. Ravnoteža između istovremenosti i paralelizma može se postaviti odabirom broja niti operativnog sustava dostupnih Erlang VM-u i broja planera koji koriste te niti.
Erlang procesi ne dijele stanje i rade u neblokirajućem načinu rada. To omogućuje relativno nisku latenciju i veću propusnost od tradicionalnih aplikacija koje se temelje na blokiranju. Erlangov planer osigurava poštenu raspodjelu CPU-a i IO-a, a odsutnost blokiranja omogućuje aplikaciji da odgovori čak i tijekom vršnih opterećenja ili kvarova.
Na razini klastera također postoji problem zbrinjavanja. Važno je da su svi strojevi u klasteru ravnomjerno opterećeni i da mreža nije preopterećena. Zamislimo situaciju: korisnički promet slijeće na dolazne balansere (haproxy, nginx itd.), oni distribuiraju zahtjeve za obradu što je ravnomjernije moguće između skupa dostupnih pozadina. Unutar aplikacijske infrastrukture, usluga koja implementira potrebno sučelje samo je posljednja milja i trebat će zatražiti niz drugih usluga kako bi odgovorila na početni zahtjev. Interni zahtjevi također zahtijevaju usmjeravanje i balansiranje.
Za učinkovito upravljanje protokom podataka, razmjena poruka mora programerima pružiti sučelje za upravljanje usmjeravanjem i balansiranjem opterećenja. Zahvaljujući tome, programeri će moći, koristeći uzorke mikroservisa (agregator, proxy, lanac, ogranak, itd.), riješiti standardne probleme i one koji se rijetko pojavljuju.
S poslovne točke gledišta, skalabilnost je jedan od alata za upravljanje rizikom. Glavna stvar je zadovoljiti zahtjeve kupaca optimalnim korištenjem opreme:
- Kada se snaga opreme povećava kao rezultat napretka. Neće mirovati zbog nesavršenog softvera. Erlang se vertikalno dobro skalira i uvijek će moći iskoristiti sve CPU jezgre i dostupnu memoriju;
- U cloud okruženjima možemo upravljati količinom opreme ovisno o trenutnom ili predviđenom opterećenju i jamčiti SLA.
tolerancija kvarova
Razmotrimo dva aksioma: "Neuspjesi su neprihvatljivi" i "Uvijek će biti neuspjeha." Za tvrtku softverski kvar znači gubitak novca, i što je još gore, gubitak ugleda. Balansirajući između mogućih gubitaka i troškova razvoja softvera otpornog na pogreške, često se može pronaći kompromis.
Kratkoročno gledano, arhitektura koja uključuje toleranciju na greške štedi novac na kupnji gotovih rješenja za klasteriranje. Skupe su i imaju i bubice.
Dugoročno gledano, arhitektura otporna na pogreške višestruko se isplati u svim fazama razvoja.
Razmjena poruka unutar baze kodova omogućuje vam da detaljno razradite interakciju komponenti unutar sustava u fazi razvoja. Ovo pojednostavljuje zadatak reagiranja i upravljanja kvarovima, budući da sve kritične komponente rješavaju kvarove, a rezultirajući sustav zna kako se automatski vratiti u normalu nakon kvara prema dizajnu.
Responzivnost
Bez obzira na kvarove, aplikacija mora odgovoriti na zahtjeve i zadovoljiti SLA. Stvarnost je takva da ljudi ne žele čekati, pa se tvrtke moraju prilagoditi tome. Očekuje se da će sve više i više aplikacija biti visoko osjetljive.
Responzivne aplikacije rade u gotovo stvarnom vremenu. Erlang VM radi u mekom načinu stvarnog vremena. Za neka područja, poput trgovine dionicama, medicine i kontrole industrijske opreme, važan je način rada u stvarnom vremenu.
Responzivni sustavi poboljšavaju korisnički doživljaj i koriste poslovanju.
Preliminarni sažetak
Kada sam planirao ovaj članak, želio sam podijeliti svoje iskustvo stvaranja brokera za razmjenu poruka i izgradnje složenih sustava na temelju njega. No, teorijski i motivacijski dio ispao je prilično opsežan.
U drugom dijelu članka govorit ću o nijansama implementacije točaka razmjene, obrascima slanja poruka i njihovoj primjeni.
U trećem dijelu razmotrit ćemo opća pitanja organizacije usluga, usmjeravanja i balansiranja. Razgovarajmo o praktičnoj strani skalabilnosti i tolerancije na pogreške sustava.
Kraj prvog dijela.
Fotografija .
Izvor: www.habr.com