Maailma ei pysy paikallaan. Edistyminen luo uusia teknologisia haasteita. Tietojärjestelmien arkkitehtuurin tulee kehittyä muuttuvien vaatimusten mukaisesti. Tänään puhumme tapahtumavetoisesta arkkitehtuurista, samanaikaisuudesta, samanaikaisuudesta, asynkronisuudesta ja siitä, kuinka tämän kaiken kanssa voi elää rauhallisesti Erlangissa.
Esittely
Suunnitellun järjestelmän koosta ja sille asetetuista vaatimuksista riippuen me, kehittäjät, valitsemme menetelmän tietojen vaihtoon järjestelmässä. Useimmissa tapauksissa palvelujen vuorovaikutuksen järjestämiseksi toimiva vaihtoehto voi olla esimerkiksi RabbitMQ:hen tai kafkaan perustuva järjestelmä välittäjän kanssa. Mutta joskus tapahtumien kulku, SLA ja järjestelmän hallinnan taso ovat sellaisia, että valmiit viestit eivät sovi meille. Tietysti järjestelmää voi hieman monimutkaistaa ottamalla vastuun kuljetuskerroksesta ja klusterin muodostamisesta esimerkiksi ZeroMQ:lla tai nanomsg:llä. Mutta jos järjestelmässä on tarpeeksi suorituskykyä ja standardin Erlang-klusterin ominaisuuksia, lisäkokonaisuuden käyttöönotto vaatii yksityiskohtaista tutkimusta ja taloudellisia perusteluja.
Reaktiivisten hajautettujen sovellusten aihepiiri on melko laaja. Artikkelin muodon säilyttämiseksi tämän päivän keskustelun aiheena on vain homogeeniset ympäristöt, jotka on rakennettu Erlang/Elixirille. Erlang/OTP-ekosysteemin avulla voit toteuttaa reaktiivisen arkkitehtuurin vähimmällä vaivalla. Mutta joka tapauksessa tarvitsemme viestintäkerroksen.
Teoreettinen perusta
Suunnittelu alkaa tavoitteiden ja rajoitteiden määrittelemisellä. Päätavoite ei ole kehittämisen alalla kehityksen vuoksi. Meidän on hankittava turvallinen ja skaalautuva työkalu, jonka pohjalta voimme luoda ja mikä tärkeintä kehittää nykyaikaisia eritasoisia sovelluksia: alkaen pientä yleisöä palvelevista yhden palvelimen sovelluksista, jotka voivat myöhemmin kehittyä jopa 50 klusteriksi. -60 solmua, päättyen klusteriliittoihin. Siten päätavoitteena on maksimoida voitot vähentämällä lopullisen järjestelmän kehittämis- ja omistuskustannuksia.
Korostetaan 4 päävaatimusta lopulliselle järjestelmälle:
- Сtapahtumalähtöistä.
Järjestelmä on aina valmis kulkemaan tapahtumavirran läpi ja suorittamaan tarvittavat toimenpiteet; - Мskaalautuvuus.
Yksittäisiä lohkoja voidaan skaalata sekä pysty- että vaakasuunnassa. Koko järjestelmän on kyettävä jatkuvaan horisontaaliseen kasvuun; - Оvikasietoisuus.
Kaikkien tasojen ja kaikkien palveluiden tulee pystyä toipumaan automaattisesti vioista; - Гtaattu vasteaika.
Aika on arvokasta, eikä käyttäjien pitäisi odottaa liian kauan.
Muistatko vanhan sadun "Pieni moottori, joka voisi"? Jotta suunniteltu järjestelmä pääsisi onnistuneesti prototyyppivaiheesta ja olisi edistyksellinen, sen perustan on täytettävä vähimmäisvaatimukset SAVUSUMU.
Viestityöhön infrastruktuurityökaluna ja kaikkien palveluiden perustana lisätään vielä yksi kohta: ohjelmoijien helppokäyttöisyys.
Tapahtumalähtöinen
Jotta sovellus kasvaisi yhdestä palvelimesta klusteriksi, sen arkkitehtuurin on tuettava löysää kytkentää. Asynkroninen malli täyttää tämän vaatimuksen. Siinä lähettäjä ja vastaanottaja välittävät viestin tietokuormasta eivätkä välitä järjestelmän sisällä tapahtuvasta lähetyksestä ja reitityksestä.
Skaalautuvuus
Skaalautuvuus ja järjestelmän tehokkuus ovat vierekkäin. Sovelluskomponenttien on kyettävä hyödyntämään kaikki käytettävissä olevat resurssit. Mitä tehokkaammin pystymme hyödyntämään kapasiteetin ja mitä optimaalisemmat prosessointimenetelmämme, sitä vähemmän rahaa käytämme laitteisiin.
Yhdellä koneella Erlang luo erittäin kilpailukykyisen ympäristön. Samanaikaisuuden ja rinnakkaisuuden välinen tasapaino voidaan asettaa valitsemalla Erlang VM:n käytettävissä olevien käyttöjärjestelmäsäikeiden lukumäärä ja näitä säikeitä hyödyntävien ajoittajien määrä.
Erlang-prosessit eivät jaa tilaa ja toimivat estotilassa. Tämä tarjoaa suhteellisen pienen viiveen ja suuremman suorituskyvyn kuin perinteiset estopohjaiset sovellukset. Erlangin ajastin varmistaa suorittimen ja IO:n oikeudenmukaisen allokoinnin, ja eston puuttuminen antaa sovellukselle mahdollisuuden vastata jopa huippukuormituksen tai vikojen aikana.
Myös klusteritasolla on ongelma hävittämisessä. On tärkeää, että kaikki klusterin koneet ovat tasaisesti kuormitettuja ja ettei verkko ole ylikuormitettu. Kuvitellaanpa tilanne: käyttäjäliikenne laskeutuu saapuville balansoijille (haproxy, nginx jne.), ne jakavat käsittelypyynnöt mahdollisimman tasaisesti käytettävissä olevien taustaohjelmien kesken. Sovellusinfrastruktuurissa vaaditun rajapinnan toteuttava palvelu on vain viimeinen mailia, ja sen on pyydettävä useita muita palveluita vastatakseen alkuperäiseen pyyntöön. Sisäiset pyynnöt vaativat myös reititystä ja tasapainotusta.
Tietovirtojen tehokas hallinta edellyttää, että viestinnän kehittäjät voivat hallita reititystä ja kuormitusta. Tämän ansiosta kehittäjät voivat mikropalvelumallien (aggregaattori, välityspalvelin, ketju, haara jne.) avulla ratkaista sekä tavallisia että harvoin esiin tulevia ongelmia.
Liiketoiminnan kannalta skaalautuvuus on yksi riskienhallinnan työkaluista. Tärkeintä on tyydyttää asiakkaiden toiveet käyttämällä laitteita optimaalisesti:
- Kun laitteiden teho kasvaa edistymisen seurauksena. Se ei ole käyttämättömänä epätäydellisen ohjelmiston vuoksi. Erlang skaalautuu pystysuunnassa hyvin ja pystyy aina hyödyntämään kaikki suorittimen ytimet ja käytettävissä olevan muistin;
- Pilviympäristöissä pystymme hallitsemaan laitteiden määrää nykyisestä tai ennustetusta kuormituksesta riippuen ja takaamme SLA:n.
vikasietoisuus
Tarkastellaan kahta aksioomia: "Epäonnistumisia ei voida hyväksyä" ja "Epäonnistumisia tulee aina." Yritykselle ohjelmistovika tarkoittaa rahan menetystä ja mikä pahinta, maineen menetystä. Tasapainottamalla mahdollisten häviöiden ja vikasietoisten ohjelmistojen kehittämiskustannusten välillä voidaan usein löytää kompromissi.
Lyhyellä aikavälillä vikasietoisuutta sisältävä arkkitehtuuri säästää rahaa valmiiden klusteriratkaisujen ostamisessa. Ne ovat kalliita ja niissä on myös vikoja.
Pitkällä aikavälillä vikasietoinen arkkitehtuuri maksaa itsensä takaisin moninkertaisesti kaikissa kehitysvaiheissa.
Koodikannan sisäinen viestintä mahdollistaa järjestelmän komponenttien vuorovaikutuksen yksityiskohtaisen selvittämisen kehitysvaiheessa. Tämä yksinkertaistaa häiriöihin reagoimista ja hallintaa, koska kaikki kriittiset komponentit käsittelevät vikoja, ja tuloksena oleva järjestelmä osaa palata automaattisesti normaaliin toimintahäiriön jälkeen.
Reagointikykyä
Vioista huolimatta sovelluksen on vastattava pyyntöihin ja täytettävä SLA. Tosiasia on, että ihmiset eivät halua odottaa, joten yritysten on mukauduttava vastaavasti. Yhä useampien sovellusten odotetaan reagoivan erittäin hyvin.
Responsiiviset sovellukset toimivat lähes reaaliajassa. Erlang VM toimii pehmeässä reaaliaikatilassa. Joillakin aloilla, kuten osakekaupassa, lääketieteessä ja teollisuuslaitteiden ohjauksessa, kova reaaliaikainen tila on tärkeä.
Responsiiviset järjestelmät parantavat käyttökokemusta ja hyödyttävät liiketoimintaa.
Alustava yhteenveto
Tätä artikkelia suunnitellessani halusin jakaa kokemukseni viestinvälittäjän luomisesta ja monimutkaisten järjestelmien rakentamisesta sen pohjalta. Mutta teoreettinen ja motivoiva osa osoittautui melko laajaksi.
Artikkelin toisessa osassa puhun vaihtopisteiden toteuttamisen vivahteista, viestimalleista ja niiden soveltamisesta.
Kolmannessa osassa tarkastellaan yleisiä palvelujen järjestämisen, reitityksen ja tasapainotuksen kysymyksiä. Puhutaanpa järjestelmien skaalautuvuuden ja vikasietoisuuden käytännön puolelta.
Ensimmäisen osan loppu.
Photo Shoot .
Lähde: will.com