Verden står ikke stille. Fremskridt skaber nye teknologiske udfordringer. I overensstemmelse med skiftende krav skal arkitekturen af informationssystemerne udvikle sig. I dag vil vi tale om begivenhedsdrevet arkitektur, samtidighed, samtidighed, asynkroni, og hvordan du kan leve fredeligt med alt dette i Erlang.
Indledning
Afhængigt af størrelsen af det designede system og kravene til det, vælger vi, udviklerne, metoden til at udveksle information i systemet. I de fleste tilfælde, for at organisere interaktionen mellem tjenester, kan en arbejdsmulighed være en ordning med en mægler, for eksempel baseret på RabbitMQ eller kafka. Men nogle gange er strømmen af begivenheder, SLA og niveauet af kontrol over systemet sådan, at færdige beskeder ikke er egnede for os. Man kan selvfølgelig komplicere systemet lidt ved at tage ansvar for transportlaget og klyngedannelsen, fx ved hjælp af ZeroMQ eller nanomsg. Men hvis systemet har nok gennemløb og muligheder for en standard Erlang-klynge, kræver spørgsmålet om at indføre en ekstra enhed en detaljeret undersøgelse og økonomisk begrundelse.
Emnet for reaktive distribuerede applikationer er ret bredt. For at holde sig inden for artiklens format vil emnet for dagens diskussion kun være homogene miljøer bygget på Erlang/Elixir. Erlang/OTP-økosystemet giver dig mulighed for at implementere en reaktiv arkitektur med den mindste indsats. Men under alle omstændigheder har vi brug for et beskedlag.
Teoretisk grundlag
Design begynder med at definere mål og begrænsninger. Hovedmålet er ikke inden for udviklingsområdet for udviklingens skyld. Vi skal have et sikkert og skalerbart værktøj, på grundlag af hvilket vi kan skabe og, vigtigst af alt, udvikle moderne applikationer på forskellige niveauer: startende fra single-server applikationer, der betjener et lille publikum, som senere kan udvikle sig til klynger på op til 50 -60 noder, der slutter med klyngeføderationer. Hovedmålet er således at maksimere profitten ved at reducere omkostningerne ved udvikling og ejerskab af det endelige system.
Lad os fremhæve 4 hovedkrav til det endelige system:
- Сbegivenhedsorienteret.
Systemet er altid klar til at passere gennem strømmen af begivenheder og udføre de nødvendige handlinger; - Мskalerbarhed.
Individuelle blokke kan skaleres både lodret og vandret. Hele systemet skal være i stand til uendelig horisontal vækst; - Оfejltolerance.
Alle niveauer og alle tjenester bør automatisk kunne komme sig efter fejl; - Гgaranteret svartid.
Tid er værdifuld, og brugere bør ikke vente for længe.
Kan du huske det gamle eventyr om "Den lille motor, der kunne"? For at det designede system med succes kan forlade prototypestadiet og være progressivt, skal dets fundament opfylde minimumskravene SMOG.
Endnu et punkt er tilføjet til meddelelser som et infrastrukturværktøj og grundlaget for alle tjenester: brugervenlighed for programmører.
Event-orienteret
For at en applikation kan vokse fra en enkelt server til en klynge, skal dens arkitektur understøtte løs kobling. Den asynkrone model opfylder dette krav. I den bekymrer afsenderen og modtageren sig om informationsbelastningen af beskeden og bekymrer sig ikke om transmission og routing i systemet.
Skalerbarhed
Skalerbarhed og systemeffektivitet er ved siden af hinanden. Applikationskomponenter skal kunne udnytte alle tilgængelige ressourcer. Jo mere effektivt vi kan udnytte kapaciteten og jo mere optimale vores forarbejdningsmetoder, jo færre penge bruger vi på udstyr.
Inden for en enkelt maskine skaber Erlang et stærkt konkurrencepræget miljø. Balancen mellem samtidighed og parallelitet kan indstilles ved at vælge antallet af operativsystemtråde, der er tilgængelige for Erlang VM, og antallet af planlæggere, der bruger disse tråde.
Erlang-processer deler ikke tilstand og fungerer i ikke-blokerende tilstand. Dette giver relativt lav latenstid og højere gennemløb end traditionelle blokeringsbaserede applikationer. Erlangs skemalægger sikrer retfærdig fordeling af CPU og IO, og fraværet af blokering gør det muligt for applikationen at reagere selv under spidsbelastninger eller fejl.
På klyngeniveau eksisterer problemet med bortskaffelse også. Det er vigtigt, at alle maskiner i klyngen er jævnt belastede, og at netværket ikke overbelastes. Lad os forestille os en situation: brugertrafik lander på indgående balancere (haproxy, nginx osv.), de fordeler behandlingsanmodninger så jævnt som muligt mellem sættet af tilgængelige backends. Inden for applikationsinfrastrukturen er tjenesten, der implementerer den påkrævede grænseflade, kun den sidste mile og skal anmode om en række andre tjenester for at svare på den indledende anmodning. Interne anmodninger kræver også routing og balancering.
For effektivt at administrere datastrømme skal meddelelser give udviklere en grænseflade til at styre routing og belastningsbalancering. Takket være dette vil udviklere være i stand til ved hjælp af mikroservicemønstre (aggregator, proxy, kæde, filial osv.) at løse både standardproblemer og dem, der sjældent opstår.
Fra et forretningsmæssigt synspunkt er skalerbarhed et af risikostyringsværktøjerne. Det vigtigste er at tilfredsstille kundernes ønsker ved at bruge udstyret optimalt:
- Når udstyrets kraft stiger som følge af fremskridt. Den vil ikke være inaktiv på grund af ufuldkommen software. Erlang skalerer lodret godt og vil altid kunne udnytte alle CPU-kerner og tilgængelig hukommelse;
- I skymiljøer kan vi styre mængden af udstyr afhængigt af den aktuelle eller forudsagte belastning og garanti SLA.
fejltolerance
Lad os overveje to aksiomer: "Svigt er uacceptable" og "Der vil altid være fejl." For en virksomhed betyder softwarefejl tab af penge, og hvad værre er, tab af omdømme. Ved at balancere mellem mulige tab og omkostningerne ved at udvikle fejltolerant software, kan der ofte findes et kompromis.
På kort sigt sparer en arkitektur, der inkorporerer fejltolerance, penge på indkøb af hyldeklare klyngeløsninger. De er dyre, og de har også fejl.
På lang sigt betaler en fejltolerant arkitektur sig mange gange tilbage på alle udviklingsstadier.
Meddelelser inden for kodebasen giver dig mulighed for at udarbejde detaljeret interaktion mellem komponenter i systemet på udviklingsstadiet. Dette forenkler opgaven med at reagere og håndtere fejl, da alle kritiske komponenter håndterer fejl, og det resulterende system ved, hvordan det automatisk vender tilbage til det normale efter en fejl ved design.
Lydhørhed
Uanset fejl skal applikationen svare på anmodninger og opfylde SLA'en. Virkeligheden er, at folk ikke ønsker at vente, så virksomheder må tilpasse sig i overensstemmelse hermed. Flere og flere ansøgninger forventes at være meget lydhøre.
Responsive applikationer fungerer i næsten realtid. Erlang VM fungerer i blød realtidstilstand. For nogle områder, såsom aktiehandel, medicin og industrielt udstyrskontrol, er hård realtidstilstand vigtig.
Responsive systemer forbedrer UX og gavner forretningen.
Indledende resumé
Da jeg planlagde denne artikel, ville jeg dele min erfaring med at skabe en messaging-mægler og bygge komplekse systemer baseret på den. Men den teoretiske og motiverende del viste sig at være ret omfattende.
I anden del af artiklen vil jeg tale om nuancerne ved at implementere udvekslingspunkter, meddelelsesmønstre og deres anvendelse.
I den tredje del vil vi overveje generelle spørgsmål om organisering af tjenester, routing og balancering. Lad os tale om den praktiske side af skalerbarhed og fejltolerance af systemer.
Slut på første del.
Foto .
Kilde: www.habr.com