Verden står ikke stille. Fremgang skaper nye teknologiske utfordringer. I samsvar med endrede krav må arkitekturen til informasjonssystemene utvikles. I dag skal vi snakke om hendelsesdrevet arkitektur, samtidighet, samtidighet, asynkroni, og hvordan du kan leve fredelig med alt dette i Erlang.
Innledning
Avhengig av størrelsen på det utformede systemet og kravene til det, velger vi, utviklerne, metoden for å utveksle informasjon i systemet. I de fleste tilfeller, for å organisere samspillet mellom tjenester, kan et arbeidsalternativ være en ordning med en megler, for eksempel basert på RabbitMQ eller kafka. Men noen ganger er flyten av hendelser, SLA og kontrollnivå over systemet slik at ferdige meldinger ikke passer for oss. Du kan selvfølgelig komplisere systemet litt ved å ta ansvar for transportlaget og klyngedannelse, for eksempel ved å bruke ZeroMQ eller nanomsg. Men hvis systemet har nok gjennomstrømning og evner til en standard Erlang-klynge, krever spørsmålet om å introdusere en ekstra enhet detaljert studie og økonomisk begrunnelse.
Temaet for reaktive distribuerte applikasjoner er ganske bredt. For å holde seg innenfor artikkelens format, vil temaet for dagens diskusjon kun være homogene miljøer bygget på Erlang/Elixir. Erlang/OTP-økosystemet lar deg implementere en reaktiv arkitektur med minst mulig innsats. Men i alle fall trenger vi et meldingslag.
Teoretisk grunnlag
Design begynner med å definere mål og begrensninger. Hovedmålet er ikke i utviklingsområdet for utviklingens skyld. Vi må skaffe et sikkert og skalerbart verktøy som vi kan lage og, viktigst av alt, utvikle moderne applikasjoner på ulike nivåer av: fra enkeltserverapplikasjoner som betjener et lite publikum, som senere kan utvikle seg til klynger på opptil 50 -60 noder, slutter med klyngeføderasjoner. Dermed er hovedmålet å maksimere fortjenesten ved å redusere kostnadene ved utvikling og eierskap til det endelige systemet.
La oss fremheve 4 hovedkrav for det endelige systemet:
- Сhendelsesorientert.
Systemet er alltid klart til å passere gjennom strømmen av hendelser og utføre de nødvendige handlingene; - Мskalerbarhet.
Individuelle blokker kan skaleres både vertikalt og horisontalt. Hele systemet må være i stand til uendelig horisontal vekst; - Оfeiltoleranse.
Alle nivåer og alle tjenester skal kunne gjenopprette automatisk etter feil; - Гgarantert responstid.
Tid er verdifull og brukere bør ikke vente for lenge.
Husker du det gamle eventyret om "Den lille motoren som kunne"? For at det utformede systemet skal kunne gå ut av prototypestadiet og være progressivt, må fundamentet oppfylle minimumskravene SMOG.
Et punkt til legges til meldingstjenester som et infrastrukturverktøy og grunnlaget for alle tjenester: brukervennlighet for programmerere.
Event-orientert
For at en applikasjon skal vokse fra en enkelt server til en klynge, må arkitekturen støtte løs kobling. Den asynkrone modellen oppfyller dette kravet. I den bryr avsender og mottaker seg om informasjonsbelastningen til meldingen og bekymrer seg ikke for overføring og ruting i systemet.
Skalerbarhet
Skalerbarhet og systemeffektivitet ligger ved siden av hverandre. Applikasjonskomponenter må kunne utnytte alle tilgjengelige ressurser. Jo mer effektivt vi kan utnytte kapasiteten og jo mer optimale prosesseringsmetodene våre er, jo mindre penger bruker vi på utstyr.
Innenfor en enkelt maskin skaper Erlang et svært konkurransedyktig miljø. Balansen mellom samtidighet og parallellitet kan settes ved å velge antall operativsystemtråder som er tilgjengelige for Erlang VM og antall planleggere som bruker disse trådene.
Erlang-prosesser deler ikke tilstand og fungerer i ikke-blokkerende modus. Dette gir relativt lav ventetid og høyere gjennomstrømming enn tradisjonelle blokkeringsbaserte applikasjoner. Erlangs planlegger sikrer rettferdig fordeling av CPU og IO, og fraværet av blokkering lar applikasjonen reagere selv under toppbelastninger eller feil.
På klyngenivå eksisterer også problemet med deponering. Det er viktig at alle maskiner i klyngen er jevnt belastet og at nettverket ikke blir overbelastet. La oss forestille oss en situasjon: brukertrafikk lander på innkommende balansere (haproxy, nginx, etc), de fordeler behandlingsforespørsler så jevnt som mulig mellom settet med tilgjengelige backends. Innenfor applikasjonsinfrastrukturen er tjenesten som implementerer det nødvendige grensesnittet bare den siste milen og vil måtte be om en rekke andre tjenester for å svare på den første forespørselen. Interne forespørsler krever også ruting og balansering.
For å effektivt administrere dataflyter, må meldingstjenester gi utviklere et grensesnitt for å administrere ruting og lastbalansering. Takket være dette vil utviklere, ved å bruke mikrotjenestemønstre (aggregator, proxy, kjede, filial, etc), kunne løse både standardproblemer og de som sjelden oppstår.
Fra et forretningsmessig synspunkt er skalerbarhet et av risikostyringsverktøyene. Det viktigste er å tilfredsstille kundeforespørsler ved å bruke utstyret optimalt:
- Når utstyrets kraft øker som følge av fremgang. Den vil ikke være inaktiv på grunn av ufullkommen programvare. Erlang skalerer vertikalt godt og vil alltid kunne utnytte alle CPU-kjerner og tilgjengelig minne;
- I skymiljøer kan vi administrere mengden utstyr avhengig av gjeldende eller antatt belastning og garanti SLA.
feiltoleranse
La oss vurdere to aksiomer: "Svikt er uakseptabelt" og "Det vil alltid være feil." For en bedrift betyr programvarefeil tap av penger, og hva verre er, tap av omdømme. Balansering mellom mulige tap og kostnadene ved å utvikle feiltolerant programvare, kan man ofte finne et kompromiss.
På kort sikt sparer en arkitektur som inkorporerer feiltoleranse penger på innkjøp av hylleløsninger. De er dyre og de har også feil.
På lang sikt betaler en feiltolerant arkitektur seg mange ganger tilbake i alle utviklingsstadier.
Meldinger i kodebasen lar deg utarbeide i detalj samspillet mellom komponenter i systemet på utviklingsstadiet. Dette forenkler oppgaven med å svare og håndtere feil, siden alle kritiske komponenter håndterer feil, og det resulterende systemet vet hvordan det automatisk går tilbake til det normale etter en feil ved design.
Respons
Uavhengig av feil, må applikasjonen svare på forespørsler og oppfylle SLA. Realiteten er at folk ikke vil vente, så bedrifter må tilpasse seg deretter. Flere og flere søknader forventes å være svært responsive.
Responsive applikasjoner fungerer i nesten sanntid. Erlang VM opererer i myk sanntidsmodus. For noen områder, som aksjehandel, medisin og industrielt utstyrskontroll, er hard sanntidsmodus viktig.
Responsive systemer forbedrer brukeropplevelsen og gagner virksomheten.
Foreløpig oppsummering
Når jeg planla denne artikkelen, ønsket jeg å dele min erfaring med å lage en meldingsmegler og bygge komplekse systemer basert på den. Men den teoretiske og motiverende delen viste seg å være ganske omfattende.
I den andre delen av artikkelen vil jeg snakke om nyansene ved å implementere utvekslingspunkter, meldingsmønstre og deres anvendelse.
I den tredje delen vil vi vurdere generelle spørsmål om organisering av tjenester, ruting og balansering. La oss snakke om den praktiske siden av skalerbarhet og feiltoleranse til systemer.
Slutt på første del.
Bilde .
Kilde: www.habr.com