Byggstenar i distribuerade applikationer. Nollapproximationen

Världen står inte still. Framsteg skapar nya teknologiska utmaningar. I enlighet med de förändrade kraven måste också arkitekturen för informationssystem evolutionera. Idag kommer vi att tala om händelseorienterad arkitektur, konkurrens, parallellitet, samtidighet och hur man kan hantera allt detta på ett harmoniskt sätt med Erlang.

Introduktion

Beroende på storleken på det planerade systemet och dess krav väljer vi som utvecklare sättet att utbyta information i systemet. I de flesta fall kan en arbetslösning för att organisera interaktion mellan tjänster vara en lösning med en broker, till exempel baserat på RabbitMQ eller Kafka. Men ibland är händelseflödet, SLA och nivån av kontroll över systemet sådana att en färdig messaging-lösning inte passar. Självklart kan man komplicera systemet något genom att ta ansvar för transportnivån och bildandet av kluster, till exempel genom att använda ZeroMQ eller nanomsg. Men om systemet har tillräcklig bandbredd och kapacitet från en standard Erlang-kluster, kräver frågan om att lägga till en extra enhet noggrant övervägande och ekonomisk motivering.

Ämnet om reaktiva distribuerade applikationer är ganska omfattande. För att passa inom ramen för artikeln kommer dagens diskussion endast att omfatta homogena miljöer byggda på Erlang/Elixir. Ekosystemet Erlang/OTP möjliggör implementering av reaktiv arkitektur med minimal arbetsinsats. Men i alla fall kommer vi att behöva ett lager för meddelandeutbyte.

Teoretisk grund

Designprocessen börjar med att fastställa mål och begränsningar. Huvudsyftet ligger inte i att utveckla för utvecklandets skull. Vi behöver en säker och skalbar verktyg som gör att vi kan skapa, och framför allt – utveckla moderna applikationer på olika nivåer: från enskilda servrar som betjänar en liten publik, som kan utvecklas till kluster med 50-60 noder, till federationer av kluster. Således är huvudmålet att maximera vinsten genom att minska kostnaderna för utveckling och ägande av det slutliga systemet.

Låt oss lyfta fram 4 huvudkrav för det slutliga systemet:

• Medhändelseorientering.
  Systemet är alltid redo att hantera ett flöde av händelser och utföra nödvändiga åtgärder;
• Mskala.
  Separata block kan skalas både vertikalt och horisontellt. Hela systemet måste kunna växa horisontellt i oändlighet;
• Tillfelöverlevnad.
  Alla nivåer och tjänster måste kunna återhämta sig automatiskt vid fel;
• Garanterad svarstid.
  Tid är värdefullt och användare ska inte behöva vänta för länge.

Kommer du ihåg den gamla sagan om 'The little engine that could', även känd som 'Puff-puff-tåget'? För att det designade systemet framgångsrikt ska ta sig från prototypstadiet till att vara progressivt, måste dess grund uppfylla minimi kraven. KUNDE.

Som ett infrastrukturellt verktyg och grund för alla tjänster läggs ytterligare en punkt till: användarvänlighet för programmerare.

Händelseorientering

För att en applikation ska kunna växa från en servern till en kluster, måste dess arkitektur säkerställa låg koppling. Detta krav uppfylls av den asynkrona modellen. Här tar avsändaren och mottagaren hand om den informativa belastningen av meddelandet och behöver inte oroa sig för överföring och routing inom systemet.

Skalbarhet

Skalbarhet och effektivitet i systemet går hand i hand. Applikationens komponenter måste kunna använda alla tillgängliga resurser. Ju mer effektivt vi kan använda kraften och ju mer optimala våra bearbetningsmetoder är, desto mindre kostar vi för utrustning.

Inom en maskin skapar Erlang en högkonkurrensutsatt miljö. Balansen mellan konkurrens och parallellitet kan ställas in genom valet av antalet operativsystemstrådar som är tillgängliga för Erlang VM och antalet schemaläggare som använder dessa trådar.
Erlang-processer har inget gemensamt tillstånd och arbetar i icke-blockerande läge. Detta ger en relativt låg latens och högre genomströmning jämfört med traditionella applikationer byggda på blockerande synkronisering. Erlang-schemaläggaren ansvarar för rättvis fördelning av CPU och IO, och avsaknaden av blockeringar gör att applikationen kan svara även under spikbelastningslägen eller vid fel.

I klustran finns det också ett problem med resursutnyttjande. Det är viktigt att alla maskiner i klustret är jämnt belastade och att nätverket inte är överbelastat. Tänk dig följande situation: användartrafik landar på de inkommande lastbalanserarna (haproxy, nginx, etc.), och de fördelar så jämnt som möjligt förfrågningar för behandling mellan en uppsättning tillgängliga backend-tjänster. Inom applikationsinfrastrukturen är tjänsten som tillhandahåller det nödvändiga gränssnittet bara den sista milen och den behöver begära flera andra tjänster för att kunna svara på den ursprungliga förfrågan. Internt begärningar kräver också routning och lastbalansering.
För att effektivt hantera dataflöden måste messaging tillhandahålla utvecklarna ett gränssnitt för att hantera routning och lastdistribution. Tack vare detta kan utvecklarna, med hjälp av mikrotjänst mönster (aggregator, proxy, kedja, gren, etc.), lösa både standarduppgifter och sällan förekommande problem.

Ur ett affärsperspektiv är skalbarhet ett av verktygen för riskhantering. Det viktigaste är att tillfredsställa kundernas krav genom att optimalt använda utrustningen:

• Vid ökad utrustningskapacitet som ett resultat av framsteg. Den kommer inte att stå oanvänd på grund av programvarans ofullkomlighet. Erlang skalar utmärkt vertikalt och kan alltid utnyttja alla CPU-kärnor och tillgängligt minne;
• I molnmiljöer kan vi hantera mängden utrustning beroende på nuvarande eller förväntad belastning och garantera SLA.

Fel-tolerans

Låt oss överväga två axiom: "Felkällor är oacceptabla" och "Felkällor kommer alltid att finnas". För verksamheten innebär programvarufel en förlust av pengar och, vad som är värre, skada på rykte. Genom att balansera möjliga förluster mot kostnaden för att utveckla felfri programvara kan man ofta hitta en kompromiss.

På kort sikt sparar en arkitektur med inbyggd felresistens pengar på att köpa färdiga klusterlösningar. De är dyra, och de har också sina fel.
På lång sikt betalar sig en felresistent arkitektur flera gånger om kostnaderna för dess användning i alla utvecklingsstadier.
Messaging inom kodbasen är fortfarande under utveckling och möjliggör en detaljerad bearbetning av komponenternas interaktioner inom systemet. Detta förenklar uppgiften att reagera på och hantera fel, eftersom alla berörda komponenter hanterar fel, och det slutliga systemet vet hur det automatiskt kan återgå till ett normalt tillstånd efter ett fel by design.

Responsivitet

Oavsett fel ska applikationen svara på förfrågningar och uppfylla SLA. Verkligheten är att människor inte vill vänta, därför måste verksamheten anpassa sig. Allt fler applikationer förväntas ha hög responsivitet.
Responsiva applikationer fungerar i en nära realtidsmiljö. Erlang VM fungerar i en mjuk realtidsmiljö. För vissa områden, såsom aktiehandel, medicin och hantering av industriell utrustning, är en hård realtidsmiljö viktigt.
Responsiva system förbättrar UX och är fördelaktiga för verksamheten.

Preliminärt resultat

När jag planerade denna artikel ville jag dela med mig av erfarenheten av att skapa en meddelandeutbytesbroker och bygga komplexa system baserade på den. Men den teoretiska och motivationsdelen blev ganska omfattande.
I den andra delen av artikeln kommer jag att berätta om nyanserna i implementeringen av utbytespunkter, meddelandeutbytesmönster och deras tillämpning.
I den tredje delen kommer vi att titta på allmänna frågor kring organisationen av tjänster, rutten och lastbalansering. Vi kommer att diskutera den praktiska sidan av skalbarhet och systemens tillförlitlighet.

Slutet av första delen.

Foto @lucabravo.

Källa: habr.com