Svet ne miruje. Napredek ustvarja nove tehnološke izzive. V skladu s spreminjajočimi se zahtevami se mora razvijati tudi arhitektura informacijskih sistemov. Danes bomo govorili o arhitekturi, ki temelji na dogodkih, sočasnosti, sočasnosti, asinhronosti in o tem, kako lahko z vsem tem mirno živite v Erlangu.
Predstavitev
Glede na velikost zasnovanega sistema in zahteve zanj razvijalci izberemo način izmenjave informacij v sistemu. V večini primerov je za organizacijo interakcije storitev lahko delujoča možnost shema s posrednikom, na primer na podlagi RabbitMQ ali kafka. Toda včasih so tok dogodkov, SLA in nivo nadzora nad sistemom takšni, da že pripravljena sporočila za nas niso primerna. Seveda lahko sistem nekoliko zakomplicirate tako, da prevzamete odgovornost za transportno plast in oblikovanje gruče, na primer z uporabo ZeroMQ ali nanomsg. Če pa ima sistem dovolj prepustnosti in zmogljivosti standardne gruče Erlang, potem vprašanje uvedbe dodatnega subjekta zahteva podrobno študijo in ekonomsko utemeljitev.
Tema reaktivnih porazdeljenih aplikacij je precej široka. Da ostanemo znotraj formata članka, bodo predmet današnje razprave le homogena okolja, zgrajena na Erlang/Elixir. Ekosistem Erlang/OTP vam omogoča implementacijo reaktivne arhitekture z najmanj truda. Toda v vsakem primeru bomo potrebovali sporočilni sloj.
Teoretične osnove
Oblikovanje se začne z opredelitvijo ciljev in omejitev. Glavni cilj ni na področju razvoja zaradi razvoja. Pridobiti moramo varno in razširljivo orodje, na podlagi katerega bomo lahko ustvarjali in, kar je najpomembnejše, razvijali sodobne aplikacije različnih ravni: od enostrežniških aplikacij, namenjenih majhnemu občinstvu, ki se lahko kasneje razvijejo v grozde do 50. -60 vozlišč, ki se končajo z zvezami gruč. Tako je glavni cilj maksimiranje dobička z znižanjem stroškov razvoja in lastništva končnega sistema.
Izpostavimo 4 glavne zahteve za končni sistem:
- Сprireditveno naravnan.
Sistem je vedno pripravljen, da preide skozi tok dogodkov in izvede potrebna dejanja; - Мrazširljivost.
Posamezne bloke je mogoče skalirati navpično in vodoravno. Celoten sistem mora biti sposoben neskončne horizontalne rasti; - Оtoleranca napak.
Vse ravni in vse storitve bi morale imeti možnost samodejnega okrevanja po okvarah; - Гzagotovljen odzivni čas.
Čas je dragocen in uporabniki naj ne čakajo predolgo.
Se spomnite stare pravljice o "Majhnem motorju, ki bi lahko"? Da bi zasnovan sistem uspešno izstopil iz faze prototipa in bil napreden, mora njegova osnova izpolnjevati minimalne zahteve SMOG.
Sporočilom kot infrastrukturnemu orodju in osnovi za vse storitve je dodana še ena točka: enostavnost uporabe za programerje.
Dogodkovno usmerjen
Da aplikacija zraste iz enega strežnika v gručo, mora njena arhitektura podpirati ohlapno povezovanje. Asinhroni model izpolnjuje to zahtevo. V njem pošiljatelj in prejemnik skrbita za informacijsko obremenitev sporočila in jima ni treba skrbeti za prenos in usmerjanje znotraj sistema.
Razširljivost
Razširljivost in učinkovitost sistema sta ena poleg druge. Komponente aplikacije morajo imeti možnost uporabe vseh razpoložljivih virov. Čim učinkoviteje lahko izkoristimo kapacitete in čim bolj optimalne so naše metode obdelave, tem manj denarja porabimo za opremo.
Znotraj enega stroja Erlang ustvari visoko konkurenčno okolje. Ravnovesje med sočasnostjo in vzporednostjo je mogoče nastaviti z izbiro števila niti operacijskega sistema, ki so na voljo Erlang VM, in števila načrtovalcev, ki uporabljajo te niti.
Procesi Erlang ne delijo stanja in delujejo v načinu brez blokiranja. To zagotavlja razmeroma nizko zakasnitev in večjo prepustnost kot tradicionalne aplikacije, ki temeljijo na blokiranju. Erlangov razporejevalnik zagotavlja pošteno razporeditev CPE in IO, odsotnost blokiranja pa omogoča, da se aplikacija odzove tudi med največjimi obremenitvami ali okvarami.
Na ravni grozda obstaja tudi problem odlaganja. Pomembno je, da so vsi stroji v gruči enakomerno obremenjeni in da omrežje ni preobremenjeno. Predstavljajmo si situacijo: uporabniški promet pristane na prihajajočih izravnavah (haproxy, nginx itd.), ti pa čim bolj enakomerno porazdelijo zahteve za obdelavo med nabor razpoložljivih ozadij. Znotraj aplikacijske infrastrukture je storitev, ki izvaja zahtevani vmesnik, le zadnji kilometer in bo morala za odgovor na prvotno zahtevo zahtevati številne druge storitve. Notranje zahteve zahtevajo tudi usmerjanje in uravnoteženje.
Za učinkovito upravljanje podatkovnih tokov mora sporočanje razvijalcem zagotoviti vmesnik za upravljanje usmerjanja in uravnoteženje obremenitve. Zahvaljujoč temu bodo lahko razvijalci z uporabo vzorcev mikrostoritev (agregator, proxy, veriga, veja itd.) rešili tako standardne težave kot tiste, ki se redko pojavljajo.
S poslovnega vidika je razširljivost eno od orodij za obvladovanje tveganj. Glavna stvar je zadovoljiti zahteve kupcev z optimalno uporabo opreme:
- Ko se zaradi napredka poveča moč opreme. Ne bo miroval zaradi nepopolne programske opreme. Erlang se navpično dobro prilagaja in bo vedno lahko izkoristil vsa jedra procesorja in razpoložljivi pomnilnik;
- V oblačnih okoljih lahko upravljamo količino opreme glede na trenutno ali predvideno obremenitev in zagotavljamo SLA.
toleranca napak
Razmislimo o dveh aksiomih: "Neuspehi so nesprejemljivi" in "Vedno bodo neuspehi." Za podjetje okvara programske opreme pomeni izgubo denarja in, kar je še huje, izgubo ugleda. Pri tehtanju med možnimi izgubami in stroški razvoja programske opreme, odporne na napake, je pogosto mogoče najti kompromis.
Kratkoročno arhitektura, ki vključuje toleranco napak, prihrani denar pri nakupu že pripravljenih rešitev za gručenje. So drage in imajo tudi hrošče.
Dolgoročno gledano se arhitektura, odporna na napake, večkrat povrne na vseh stopnjah razvoja.
Sporočila znotraj kodne baze vam omogočajo, da podrobno razdelate interakcijo komponent znotraj sistema v fazi razvoja. To poenostavi nalogo odzivanja in obvladovanja okvar, saj vse kritične komponente obravnavajo napake, nastali sistem pa se po zasnovi samodejno vrne v normalno stanje po okvari.
Odzivnost
Ne glede na napake se mora aplikacija odzivati na zahteve in izpolnjevati SLA. Dejstvo je, da ljudje ne želijo čakati, zato se morajo podjetja temu ustrezno prilagoditi. Pričakuje se, da bo vedno več aplikacij visoko odzivnih.
Odzivne aplikacije delujejo skoraj v realnem času. Erlang VM deluje v mehkem načinu realnega časa. Za nekatera področja, kot so trgovanje z delnicami, medicina in nadzor industrijske opreme, je pomemben način trdega realnega časa.
Odzivni sistemi izboljšujejo UX in koristijo podjetju.
Predhodni povzetek
Pri načrtovanju tega članka sem želel deliti svoje izkušnje z ustvarjanjem posrednika za sporočanje in gradnjo kompleksnih sistemov na njegovi podlagi. Toda teoretični in motivacijski del sta se izkazala za precej obsežna.
V drugem delu članka bom govoril o niansah izvajanja izmenjevalnih točk, vzorcih sporočanja in njihovi uporabi.
V tretjem delu bomo obravnavali splošna vprašanja organizacije storitev, usmerjanja in uravnoteženja. Pogovorimo se o praktični plati razširljivosti in odpornosti sistemov na napake.
Konec prvega dela.
Photo Shoot .
Vir: www.habr.com