Die wêreld staan nie stil nie. Vooruitgang skep nuwe tegnologiese uitdagings. In ooreenstemming met veranderende vereistes, moet die argitektuur van inligtingstelsels ontwikkel. Vandag sal ons praat oor gebeurtenisgedrewe argitektuur, sameloop, sameloop, asinchronie, en hoe jy vreedsaam met dit alles in Erlang kan leef.
Inleiding
Afhangende van die grootte van die ontwerpte stelsel en die vereistes daarvoor, kies ons, die ontwikkelaars, die metode om inligting in die stelsel uit te ruil. In die meeste gevalle, om die interaksie van dienste te organiseer, kan 'n werkopsie 'n skema met 'n makelaar wees, byvoorbeeld, gebaseer op RabbitMQ of kafka. Maar soms is die vloei van gebeure, SLA en vlak van beheer oor die stelsel sodanig dat klaargemaakte boodskappe nie vir ons geskik is nie. Natuurlik kan jy die stelsel 'n bietjie kompliseer deur verantwoordelikheid te neem vir die vervoerlaag en groepvorming, byvoorbeeld deur ZeroMQ of nanomsg te gebruik. Maar as die stelsel genoeg deurset en vermoëns van 'n standaard Erlang-kluster het, vereis die kwessie van die bekendstelling van 'n bykomende entiteit gedetailleerde studie en ekonomiese regverdiging.
Die onderwerp van reaktiewe verspreide toepassings is redelik wyd. Om binne die formaat van die artikel te hou, sal die onderwerp van vandag se bespreking slegs homogene omgewings wees wat op Erlang/Elixir gebou is. Die Erlang/OTP-ekosisteem laat jou toe om 'n reaktiewe argitektuur met die minste moeite te implementeer. Maar in elk geval sal ons 'n boodskaplaag nodig hê.
Teoretiese basis
Ontwerp begin met die definisie van doelwitte en beperkings. Die hoofdoel is nie op die gebied van ontwikkeling ter wille van ontwikkeling nie. Ons moet 'n veilige en skaalbare hulpmiddel verkry op grond waarvan ons moderne toepassings van verskillende vlakke kan skep en, bowenal, ontwikkel: vanaf enkelbedienertoepassings wat 'n klein gehoor bedien, wat later in groepe van tot 50 kan ontwikkel. -60 nodusse, eindig met cluster federasies. Die hoofdoel is dus om wins te maksimeer deur die koste van ontwikkeling en eienaarskap van die finale stelsel te verminder.
Kom ons beklemtoon 4 hoofvereistes vir die finale stelsel:
- Сgebeurtenis-georiënteerd.
Die stelsel is altyd gereed om deur die vloei van gebeure te gaan en die nodige aksies uit te voer; - Мskaalbaarheid.
Individuele blokke kan beide vertikaal en horisontaal geskaal word. Die hele stelsel moet tot oneindige horisontale groei in staat wees; - Оfout verdraagsaamheid.
Alle vlakke en alle dienste moet outomaties van mislukkings kan herstel; - Гgewaarborgde reaksietyd.
Tyd is waardevol en gebruikers moet nie te lank wag nie.
Onthou jy die ou sprokie oor “Die klein enjin wat kon”? Om die ontwerpte stelsel suksesvol uit die prototipe stadium te verlaat en progressief te wees, moet die fondasie daarvan aan die minimum vereistes voldoen SMOG.
Nog 'n punt word bygevoeg tot boodskappe as 'n infrastruktuurinstrument en die basis vir alle dienste: gebruiksgemak vir programmeerders.
Gebeurtenis-georiënteerd
Vir 'n toepassing om van 'n enkele bediener na 'n groepering te groei, moet sy argitektuur los koppeling ondersteun. Die asynchrone model voldoen aan hierdie vereiste. Daarin gee die sender en ontvanger om oor die inligtinglading van die boodskap en moenie bekommerd wees oor transmissie en roetering binne die stelsel nie.
Skaalbaarheid
Skaalbaarheid en stelseldoeltreffendheid is naas mekaar. Toepassingskomponente moet alle beskikbare hulpbronne kan benut. Hoe meer doeltreffend ons kapasiteit kan benut en hoe meer optimaal ons verwerkingsmetodes is, hoe minder geld bestee ons aan toerusting.
Binne 'n enkele masjien skep Erlang 'n hoogs mededingende omgewing. Die balans tussen gelyktydigheid en parallelisme kan gestel word deur die aantal bedryfstelseldrade wat beskikbaar is vir die Erlang VM en die aantal skeduleerders wat hierdie drade gebruik, te kies.
Erlang-prosesse deel nie toestand nie en werk in nie-blokkerende modus. Dit bied relatief lae latensie en hoër deurset as tradisionele blokkeer-gebaseerde toepassings. Erlang se skeduleerder verseker regverdige toewysing van SVE en IO, en die afwesigheid van blokkering laat die toepassing toe om selfs tydens piekladings of mislukkings te reageer.
Op trosvlak bestaan die probleem met wegdoening ook. Dit is belangrik dat alle masjiene in die groep eweredig gelaai word en dat die netwerk nie oorlaai word nie. Kom ons stel ons 'n situasie voor: gebruikersverkeer beland op inkomende balanseerders (haproxy, nginx, ens.), hulle versprei verwerkingsversoeke so eweredig moontlik tussen die stel beskikbare backends. Binne die toepassingsinfrastruktuur is die diens wat die vereiste koppelvlak implementeer slegs die laaste myl en sal 'n aantal ander dienste moet aanvra om op die aanvanklike versoek te reageer. Interne versoeke vereis ook roetering en balansering.
Om datavloei effektief te bestuur, moet boodskappe ontwikkelaars voorsien van 'n koppelvlak om roetering en vragbalansering te bestuur. Danksy dit sal ontwikkelaars in staat wees om mikrodienspatrone (aggregator, proxy, ketting, tak, ens.) te gebruik om beide standaardprobleme en dié wat selde voorkom, op te los.
Uit 'n besigheidsoogpunt is skaalbaarheid een van die risikobestuursinstrumente. Die belangrikste ding is om kliënte se versoeke te bevredig deur die toerusting optimaal te gebruik:
- Wanneer die krag van toerusting toeneem as gevolg van vooruitgang. Dit sal nie ledig wees nie as gevolg van onvolmaakte sagteware. Erlang skaal vertikaal goed en sal altyd alle SVE-kerne en beskikbare geheue kan benut;
- In wolkomgewings kan ons die hoeveelheid toerusting bestuur afhangende van die huidige of voorspelde vrag en waarborg SLA.
fout verdraagsaamheid
Kom ons kyk na twee aksiomas: "Mislukkings is onaanvaarbaar" en "Daar sal altyd mislukkings wees." Vir 'n besigheid beteken sagteware-mislukking verlies aan geld, en wat nog erger is, verlies aan reputasie. Balansering tussen moontlike verliese en die koste van die ontwikkeling van foutverdraagsame sagteware, kan dikwels 'n kompromie gevind word.
Op kort termyn spaar 'n argitektuur wat foutverdraagsaamheid insluit geld op die aankoop van van die rak groeperingsoplossings. Hulle is duur en hulle het ook goggas.
Op lang termyn betaal 'n foutverdraagsame argitektuur hom baie keer terug in alle stadiums van ontwikkeling.
Boodskappe binne die kodebasis laat jou toe om die interaksie van komponente binne die stelsel in die ontwikkelingstadium in detail uit te werk. Dit vergemaklik die taak om te reageer en mislukkings te bestuur, aangesien alle kritieke komponente foute hanteer, en die gevolglike stelsel weet hoe om outomaties terug te keer na normaal na 'n mislukking deur ontwerp.
Responsiwiteit
Ongeag die mislukkings, moet die aansoek op versoeke reageer en aan die SLA voldoen. Die realiteit is dat mense nie wil wag nie, so ondernemings moet daarvolgens aanpas. Daar word verwag dat meer en meer toepassings hoogs reageer.
Responsiewe toepassings werk in byna intydse. Erlang VM werk in sagte intydse modus. Vir sommige gebiede, soos aandeleverhandeling, medisyne en industriële toerustingbeheer, is harde intydse modus belangrik.
Responsiewe stelsels verbeter UX en bevoordeel die besigheid.
Voorlopige opsomming
Toe ek hierdie artikel beplan, wou ek my ervaring deel van die skep van 'n boodskapmakelaar en die bou van komplekse stelsels wat daarop gebaseer is. Maar die teoretiese en motiverende deel was redelik uitgebreid.
In die tweede deel van die artikel sal ek praat oor die nuanses van die implementering van uitruilpunte, boodskappatrone en hul toepassing.
In die derde deel sal ons algemene kwessies oor die organisering van dienste, roetering en balansering oorweeg. Kom ons praat oor die praktiese sy van skaalbaarheid en fouttoleransie van stelsels.
Einde van die eerste deel.
Фото .
Bron: will.com