Verden står ikke stille. Fremskridt skaber nye teknologiske udfordringer. I takt med de ændrede krav skal arkitekturen for informationssystemer også udvikle sig. I dag vil vi tale om begivenhedsorienteret arkitektur, konkurrence, parallelisme, asynkronitet, og hvordan man kan leve harmonisk med alt dette i Erlang.
Introduktion
Afhængigt af størrelsen af det system, der designes, og kravene til det, vælger vi som udviklere en metode til informationsudveksling i systemet. I de fleste tilfælde kan en løsning med en broker, eksempelvis baseret på RabbitMQ eller Kafka, være et praktisk valg til at organisere interaktionen mellem tjenester. Men nogle gange er strømmen af begivenheder, SLA og niveauet for kontrol over systemet sådan, at en færdig messaging-løsning ikke er tilstrækkelig. Selvfølgelig kan man gøre systemet lidt mere komplekst ved at tage ansvar for transportlaget og dannelsen af klynger, for eksempel ved at bruge ZeroMQ eller nanomsg. Men hvis systemet er tilstrækkeligt i forhold til kapacitet og mulighederne i det standard Erlang-klynge, kræver spørgsmålet om at tilføje en yderligere enhed en grundig undersøgelse og økonomisk begrundelse.
Emnet om reaktive distribuerede applikationer er ret omfattende. For at holde os inden for rammerne af denne artikel vil dagens diskussion kun omfatte homogene miljøer bygget på Erlang/Elixir. Økosystemet Erlang/OTP giver mulighed for at implementere en reaktiv arkitektur med minimale arbejdsomkostninger. Men vi vil i hvert fald have brug for et lag til meddelelser.
Teoretisk grundlag
Designet begynder med at definere mål og begrænsninger. Hovedmålet ligger ikke på udvikling for udviklingens skyld. Vi har brug for at skabe et sikkert og skalerbart værktøj, som kan bruges til at opbygge, og vigtigst af alt – udvikle moderne applikationer på forskelligt niveau: fra enserver applikationer, der betjener en lille målgruppe, som senere kan udvikles til klynger med 50-60 noder, til federationer af klynger. Dermed er hovedmålet maksimalisering af profit ved at reducere omkostningerne ved udvikling og ejerskab af det endelige system.
Lad os fremhæve 4 hovedkrav til det endelige system:
- Medbegivenhedsorientering.
Systemet er altid klar til at håndtere en strøm af begivenheder og udføre de nødvendige handlinger; - Muligheder for skalering.
Separate blokke kan skaleres både vertikalt og horisontalt. Hele systemet skal kunne vokse horisontalt uden begrænsning; - Optimering af driftsikkerhed.
Alle niveauer og alle tjenester skal kunne genoprette sig automatisk ved fejl; - Garanteret svartid.
Tid er værdifuld, og brugerne skal ikke vente for længe.
Husk det gamle eventyr om “The little engine that could”, eller “Toget, der kunne”? For at det system, vi designer, kan bevæge sig fra prototype til en progressiv løsning, skal fundamentet opfylde de minimale krav. KUNNE.
Når messaging betragtes som et infrastrukturelt værktøj og grundlag for alle tjenester, tilføjes endnu et punkt: brugervenlighed for programmører.
Hændelsesorientering
For at en applikation kan vokse fra en server til en klynge, skal dens arkitektur sikre løs kobling. Denne betingelse opfyldes af en asynkron model. Her tager afsender og modtager sig af den information, der sendes i beskeden, og bekymrer sig ikke om transmissionen og routing internt i systemet.
Skalering
Skalering og effektivitet i systemet går hånd i hånd. Applikationens komponenter skal kunne udnytte alle tilgængelige ressourcer. Jo mere effektivt vi kan udnytte kapaciteten, og jo mere optimalt vores behandlingsmetoder er, jo mindre bruger vi på udstyr.
Inden for én maskine skaber Erlang et højkonkurrencemiljø. Balance mellem konkurrence og parallelitet kan bestemmes ved at vælge antallet af operativsystemtråde tilgængelige for Erlang VM og antallet af planlæggere, der udnytter disse tråde.
Erlang-processer har ikke en delt tilstand og arbejder i en ikke-blokerende tilstand. Dette sikrer relativt lav latenstid og højere gennemstrømning end traditionelle applikationer, der er bygget på blokering og synkronisering. Erlang-planlæggeren sørger for en retfærdig fordeling af CPU og IO, og fraværet af blokeringer gør det muligt for applikationen at svare selv under spidsbelastning eller nedbrud.
På klusterniveau findes der også et problem med ressourceudnyttelse. Det er vigtigt, at alle maskiner i klusteret er jævnt belastede, og at netværket ikke er overbelastet. Forestil dig en situation: brugertraffik lander på de indkommende belastningsbalancer (haproxy, nginx osv.), som jævnt fordeler forespørgslerne til behandling mellem et sæt tilgængelige backend-tjenester. Inden for applikationsinfrastrukturen er tjenesten, der implementerer det nødvendige interface, kun den sidste mil, og den skal anmode om en række andre tjenester for at kunne besvare den oprindelige forespørgsel. Interne forespørgsler kræver også rutefordeling og belastningsbalancering.
For effektivt at administrere strømmen af data skal messaging give udviklere et interface til at styre rutefordeling og belastningsfordeling. Takket være dette kan udviklere, ved at bruge mikrotjenestemønstre (aggregator, proxy, kæde, gren osv.), tackle både standardopgaver og sjældent forekommende opgaver.
Set fra forretningsperspektiv er skalerbarhed et værktøj til risikostyring. Det vigtigste er at opfylde kundernes forespørgsler ved optimalt at udnytte udstyret:
- Ved at øge kapaciteten af udstyret som følge af fremskridt. Det vil ikke stå stille på grund af softwareimperfektioner. Erlang skalerer fremragende vertikalt og kan altid udnytte alle CPU-kerner og tilgængelig hukommelse;
- I skytjenester kan vi styre mængden af udstyr i forhold til den aktuelle eller forudsete belastning og garantere SLA.
Fejltolerance
Lad os overveje to aksiomer: "Fejl er uacceptable" og "Fejl vil altid forekomme". For virksomheder er softwarefejl et tab af penge, og hvad der er værre – af omdømme. Ved at balancere mellem mulige tab og omkostningerne ved at udvikle fejltolerant software, kan der ofte findes et kompromis.
I den korte sigt sparer arkitektur, der indbygger fejltolerance, penge på køb af færdige klusterløsninger. De er dyre, og de indeholder også fejl.
På lang sigt betaler en fejltolerant arkitektur sig mange gange tilbage på alle udviklingsfaser.
Messaging i kodebasen er stadig under udvikling og muliggør en detaljeret gennemgang af interaktionen mellem systemkomponenterne. Dette letter opgaven med at reagere på og håndtere fejl, da de ansvarlige komponenter håndterer fejl, mens det endelige system ved, hvordan det automatisk kan vende tilbage til normal drift efter en fejl som designet.
Responsivitet
Uanset nedbrud skal applikationen svare på anmodninger og overholde SLA. Reality er, at folk ikke ønsker at vente, og derfor skal virksomheder tilpasse sig. Man forventer i stigende grad høj responsivitet fra flere applikationer.
Responsivitet applikationer fungerer i en næsten realtid. Erlang VM opererer i en blød realtidstilstand. For nogle områder, såsom aktiehandel, medicin, og styring af industriel udstyr, er hård realtidstilstand vigtig.
Responsiv systemer forbedrer UX og er nyttige for virksomheden.
Foreløbigt resultat
Da jeg planlagde denne artikel, ønskede jeg at dele erfaringer med at oprette en messaging-broker og opbygge komplekse systemer baseret på det. Men den teoretiske og motiverende del viste sig at være ret omfattende.
I den anden del af artiklen vil jeg tale om nuancerne ved implementeringen af udvekslingspunkter, messaging-templates og deres anvendelse.
I den tredje del vil vi se på generelle spørgsmål om organiseringen af tjenester, routing og load balancing. Vi vil tale om den praktiske side af skalerbarhed og systems modstandsdygtighed.
Slutningen af den første del.
Foto .
Kilde: habr.com
