Svijet ne miruje. Napredak stvara nove tehnološke izazove. U skladu sa promjenjivim zahtjevima, arhitektura informacionih sistema mora se razvijati. Danas ćemo pričati o arhitekturi vođenoj događajima, konkurentnosti, konkurentnosti, asinhroniji i kako možete mirno živjeti sa svime ovim u Erlangu.
Uvod
U zavisnosti od veličine projektovanog sistema i zahteva za njim, mi, programeri, biramo način razmene informacija u sistemu. U većini slučajeva, za organiziranje interakcije usluga, radna opcija može biti shema s brokerom, na primjer, zasnovana na RabbitMQ ili kafki. Ali ponekad su tok događaja, SLA i nivo kontrole nad sistemom takvi da nam gotove poruke ne odgovaraju. Naravno, možete malo zakomplikovati sistem preuzimanjem odgovornosti za transportni sloj i formiranje klastera, na primjer korištenjem ZeroMQ ili nanomsg. Ali ako sistem ima dovoljnu propusnost i mogućnosti standardnog Erlang klastera, onda pitanje uvođenja dodatnog entiteta zahtijeva detaljnu studiju i ekonomsko opravdanje.
Tema reaktivnih distribuiranih aplikacija je prilično široka. Kako bismo zadržali format članka, predmet današnje rasprave će biti samo homogena okruženja izgrađena na Erlang/Elixir-u. Erlang/OTP ekosistem vam omogućava da implementirate reaktivnu arhitekturu uz najmanje napora. Ali u svakom slučaju, trebat će nam sloj za razmjenu poruka.
Teorijska osnova
Dizajn počinje definiranjem ciljeva i ograničenja. Osnovni cilj nije u oblasti razvoja radi razvoja. Moramo nabaviti siguran i skalabilan alat na osnovu kojeg možemo kreirati i, što je najvažnije, razvijati moderne aplikacije različitih nivoa: počevši od jednoserverskih aplikacija koje služe maloj publici, a koje se kasnije mogu razviti u klastere do 50 -60 čvorova, završavajući klaster federacijama. Dakle, glavni cilj je maksimiziranje profita smanjenjem troškova razvoja i posjedovanja konačnog sistema.
Istaknimo 4 glavna zahtjeva za konačni sistem:
- Сorijentisan na događaje.
Sistem je uvek spreman da prođe kroz tok događaja i izvrši potrebne radnje; - Мskalabilnost.
Pojedinačni blokovi mogu se skalirati i vertikalno i horizontalno. Čitav sistem mora biti sposoban za beskonačan horizontalni rast; - Оtolerancije grešaka.
Svi nivoi i sve usluge treba da budu u stanju da se automatski oporave od kvarova; - Гgarantovano vreme odgovora.
Vrijeme je dragocjeno i korisnici ne bi trebali čekati predugo.
Sjećate li se stare bajke o "Malom motoru koji je mogao"? Da bi projektovani sistem uspešno izašao iz faze prototipa i bio progresivan, njegova osnova mora ispunjavati minimalne zahteve SMOG.
Još jedna stvar je dodana razmjeni poruka kao infrastrukturnom alatu i osnovi za sve usluge: jednostavnost korištenja za programere.
Orijentisan na događaje
Da bi aplikacija prerasla iz jednog servera u klaster, njena arhitektura mora podržavati labavo povezivanje. Asinhroni model ispunjava ovaj zahtjev. U njemu, pošiljalac i primalac brinu o informacionom opterećenju poruke i ne brinu o prenosu i rutiranju unutar sistema.
Skalabilnost
Skalabilnost i efikasnost sistema su jedna pored druge. Komponente aplikacije moraju biti u mogućnosti da iskoriste sve raspoložive resurse. Što efikasnije možemo iskoristiti kapacitet i što su naše metode obrade optimalnije, manje novca trošimo na opremu.
Unutar jedne mašine, Erlang stvara visoko konkurentno okruženje. Ravnoteža između konkurentnosti i paralelizma može se postaviti odabirom broja niti operativnog sistema dostupnih Erlang VM-u i broja planera koji koriste ove niti.
Erlang procesi ne dijele stanje i rade u neblokirajućem načinu. Ovo pruža relativno nisko kašnjenje i veću propusnost od tradicionalnih aplikacija zasnovanih na blokiranju. Erlangov planer osigurava poštenu alokaciju CPU-a i IO-a, a odsustvo blokiranja omogućava aplikaciji da odgovori čak i tokom vršnog opterećenja ili kvarova.
Na nivou klastera takođe postoji problem sa odlaganjem. Važno je da sve mašine u klasteru budu ravnomerno opterećene i da mreža nije preopterećena. Zamislimo situaciju: korisnički promet pada na dolazne balansere (haproxy, nginx, itd.), oni distribuiraju zahtjeve za obradu što je ravnomjernije moguće između skupa dostupnih backenda. Unutar infrastrukture aplikacije, usluga koja implementira traženo sučelje je samo zadnja milja i morat će zatražiti niz drugih usluga da odgovori na početni zahtjev. Interni zahtjevi također zahtijevaju usmjeravanje i balansiranje.
Da bi se efikasno upravljalo tokovima podataka, razmjena poruka mora omogućiti programerima interfejs za upravljanje usmjeravanjem i balansiranjem opterećenja. Zahvaljujući tome, programeri će moći, koristeći mikroservisne obrasce (agregator, proxy, lanac, grana, itd.), rješavati i standardne probleme i one koji se rijetko pojavljuju.
Sa poslovne tačke gledišta, skalabilnost je jedan od alata za upravljanje rizicima. Glavna stvar je zadovoljiti zahtjeve kupaca optimalnim korištenjem opreme:
- Kada se snaga opreme povećava kao rezultat napretka. Neće biti u stanju mirovanja zbog nesavršenog softvera. Erlang se dobro vertikalno 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 garantirati SLA.
tolerancije grešaka
Razmotrimo dva aksioma: “Neuspjesi su neprihvatljivi” i “Uvijek će biti neuspjeha”. Za posao, neuspjeh softvera znači gubitak novca, i što je još gore, gubitak reputacije. Balansirajući između mogućih gubitaka i troškova razvoja softvera otpornog na greške, često se može naći kompromis.
Kratkoročno gledano, arhitektura koja uključuje toleranciju grešaka štedi novac na kupovini gotovih rješenja za klasterisanje. Oni su skupi i takođe imaju greške.
Dugoročno gledano, arhitektura otporna na greške se višestruko isplati u svim fazama razvoja.
Razmjena poruka unutar baze koda omogućava vam da detaljno razradite interakciju komponenti unutar sistema u fazi razvoja. Ovo pojednostavljuje zadatak reagovanja i upravljanja kvarovima, budući da sve kritične komponente rukuju kvarovima, a rezultujući sistem zna kako da se automatski vrati u normalu nakon kvara po dizajnu.
Responsiveness
Bez obzira na kvarove, aplikacija mora odgovoriti na zahtjeve i ispuniti SLA. Realnost je da ljudi ne žele da čekaju, pa se preduzeća moraju prilagoditi tome. Očekuje se da će sve više aplikacija imati visoku reakciju.
Responzivne aplikacije rade u skoro realnom vremenu. Erlang VM radi u mekom režimu u realnom vremenu. Za neka područja, kao što su trgovina dionicama, medicina i kontrola industrijske opreme, važan je način rada u stvarnom vremenu.
Responzivni sistemi poboljšavaju UX i doprinose poslovanju.
Preliminarni sažetak
Kada sam planirao ovaj članak, želio sam podijeliti svoje iskustvo stvaranja brokera za razmjenu poruka i izgradnje složenih sistema zasnovanih na njemu. Ali teorijski i motivacijski dio se pokazao prilično opsežnim.
U drugom dijelu članka govorit ću o nijansama implementacije točaka razmjene, obrascima razmjene poruka i njihovoj primjeni.
U trećem dijelu ćemo razmotriti opća pitanja organizacije usluga, rutiranja i balansiranja. Hajde da razgovaramo o praktičnoj strani skalabilnosti i tolerancije grešaka sistema.
Kraj prvog dijela.
fotografija .
izvor: www.habr.com