🥇 Bouwstenen van gedistribueerde applicaties. Nulbenadering

De wereld staat niet stil. Vooruitgang creëert nieuwe technologische uitdagingen. De architectuur van informatiesystemen moet evolueren in overeenstemming met de veranderende eisen. Vandaag gaan we het hebben over gebeurtenisgestuurde architectuur, concurrentie, paralleliteit, asynchroniciteit en hoe je vredig met al deze zaken kunt leven in Erlang.

Inleiding

Afhankelijk van de omvang van het te ontwerpen systeem en de eisen daarvoor, kiezen wij, ontwikkelaars, een manier van informatiewisseling in het systeem. In de meeste gevallen kan een schema met een broker, bijvoorbeeld op basis van RabbitMQ of Kafka, een werkbare optie zijn voor de interactie tussen diensten. Maar soms is de stroom van gebeurtenissen, SLA en het niveau van controle over het systeem zodanig dat een kant-en-klare messagingoplossing niet geschikt is. Natuurlijk kan het systeem wat complexer worden door de verantwoordelijkheid voor het transportniveau en het opzetten van een cluster op zich te nemen, bijvoorbeeld met ZeroMQ of nanomsg. Maar als het systeem voldoet aan de doorvoer- en capaciteitsvereisten van een standaard Erlang-cluster, vereist de vraag naar het toevoegen van een extra entiteit een grondige studie en economische rechtvaardiging.

Het onderwerp van reactieve gedistribueerde applicaties is vrij uitgebreid. Om binnen het formaat van een artikel te blijven, zullen we ons vandaag alleen richten op homogene omgevingen gebaseerd op Erlang/Elixir. Het ecosysteem Erlang/OTP laat toe om met de minste inspanning een reactieve architectuur te realiseren. Maar in elk geval hebben we een communicatielaag nodig.

Theoretische basis

Het ontwerp begint met het bepalen van doelen en beperkingen. Het belangrijkste doel ligt niet in de ontwikkeling om de ontwikkeling. We moeten een veilige en schaalbare tool krijgen, waarop we moderne applicaties van verschillende niveaus kunnen bouwen en, belangrijkste, ontwikkelen: variërend van enkele servers die een klein publiek bedienen en later kunnen uitgroeien tot clusters van 50-60 knooppunten, tot federaties van clusters. Dus het primaire doel is het maximaliseren van de winst door de kosten van ontwikkeling en eigendom van het eindproduct te verlagen.

Laten we vier belangrijke vereisten voor het eindproduct opstellen:

metgebeurtenisgestuurd.
Het systeem is altijd bereid om een stroom van gebeurtenissen te verwerken en de nodige acties uit te voeren;
Mschaalbaarheid.
Losse blokken kunnen zowel verticaal als horizontaal worden geschaald. Het hele systeem moet de mogelijkheid hebben voor onbeperkte horizontale groei;
groot aantal partitions.fouttolerantie.
Alle niveaus en diensten moeten in staat zijn om automatisch te herstellen bij storingen;
Gegarandeerde responstijd.
Tijd is kostbaar en gebruikers mogen niet te lang wachten.

Vergeet het oude sprookje over “The little engine that could”, ook bekend als “De trein die het kon”? Om het ontworpen systeem succesvol uit de prototypefase te laten komen en progressief te zijn, moet de basis voldoen aan minimale eisen. KON.

Aan messaging als een infrastructuurtool en basis voor alle diensten wordt nog een punt toegevoegd: gebruiksgemak voor programmeurs.

Gebeurtenisgerichtheid.

Om een applicatie te laten groeien van één de server tot een cluster, moet de architectuur zorgen voor losse koppeling. Dit wordt bereikt door een asynchrone model. Daarbij zorgen de afzender en ontvanger voor de informatiebelasting van het bericht en maken zich geen zorgen over de overdracht en routering binnen het systeem.

Schaalbaarheid

Schaalbaarheid en efficiëntie van het systeem gaan hand in hand. De componenten van de applicatie moeten in staat zijn om alle beschikbare bronnen te benutten. Hoe efficiënter we de capaciteiten kunnen benutten en hoe optimaler onze verwerkingsmethoden zijn, des te minder geld we uitgeven aan hardware.

Binnen één machine creëert Erlang een hoogconcurrerende omgeving. De balans tussen concurrentie en paralleliteit kan worden ingesteld door het aantal systeemthreads dat beschikbaar is voor de Erlang VM en het aantal planners dat deze threads benut.
Erlang-processen hebben geen gedeelde toestand en werken in een niet-blokkerende modus. Dit zorgt voor relatief lage latentie en een hogere doorvoer dan traditionele applicaties die zijn gebouwd op blokkerende synchronisatie. De planner van Erlang zorgt voor een eerlijke verdeling van CPU en IO, en het ontbreken van blokkeringen stelt de applicatie in staat om zelfs in piekbelastingen of bij storingen te reageren.

Op cluster level bestaat er ook een probleem met de benutting. Het is belangrijk dat alle machines in de cluster gelijkmatig belast zijn en dat het netwerk niet overbelast is. Stel je de situatie voor: gebruikersverkeer komt binnen op de inkomende load balancers (haproxy, nginx, enz.), die de verzoeken zo gelijkmatig mogelijk verdelen over een set beschikbare backends. Binnen de infrastructuur van de applicatie is de service die de vereiste interface implementeert – dit is slechts de laatste mijl, en deze moet een aantal andere services aanroepen om op het oorspronkelijke verzoek te kunnen antwoorden. Interne verzoeken vereisen ook routering en balans.
Om datastromen effectief te beheren, moet messaging ontwikkelaars een interface bieden voor het beheersen van de routering en het verdelen van de belasting. Daardoor kunnen ontwikkelaars, gebruikmakend van microservice-patronen (aggregator, proxy, chain, branch, enz.), zowel standaard taken als zeldzaam voorkomende problemen oplossen.

Vanuit zakelijk perspectief is schaalbaarheid een van de instrumenten voor risicobeheer. Het belangrijkste is om aan de wensen van klanten te voldoen en daarbij de apparatuur optimaal te gebruiken:

Bij een grotere capaciteit van de apparatuur als gevolg van vooruitgang. Het zal niet idle zijn vanwege de tekortkomingen van de software. Erlang schaalt uitstekend verticaal en kan altijd alle CPU-kernen en beschikbare geheugen benutten;
In cloudomgevingen kunnen we het aantal apparaten beheren op basis van de huidige of verwachte belasting en SLA garanderen.

Resilience

Laten we twee axioma's beschouwen: "Fouten zijn onaanvaardbaar" en "Fouten zullen altijd gebeuren". Voor een bedrijf betekent een softwarefout verlies van geld, wat nog erger is - het verlies van reputatie. Door te balanceren tussen mogelijke verliezen en de kosten van het ontwikkelen van fouttolerante software, kan vaak een compromis worden gevonden.

Op korte termijn bespaart een architectuur met ingebouwde fouttolerantie kosten voor de aanschaf van kant-en-klare clusteringoplossingen. Deze zijn duur en bevatten ook fouten.
Op lange termijn betaalt een fouttolerante architectuur zich multiple times terug in alle fasen van ontwikkeling.
Messaging binnen de codebasis is nog in ontwikkeling en stelt ons in staat om de interactie tussen componenten binnen het systeem gedetailleerd uit te werken. Dit vereenvoudigt het reageren op en beheren van storingen, aangezien alle betrokken componenten fouten verwerken en het uiteindelijke systeem weet hoe het automatisch kan terugkeren naar een normale toestand na een storing zoals bedoeld.

Responsiviteit

Ongeacht storingen moet de applicatie reageren op verzoeken en voldoen aan de SLA. De realiteit is dat mensen niet willen wachten, dus moet het bedrijf zich aanpassen. Van een toenemend aantal applicaties wordt hoge responsiviteit verwacht.
Responsieve applicaties werken in een bijna realtime modus. Erlang VM functioneert in een modus voor zachte realtime. Voor sommige gebieden, zoals aandelenhandel, gezondheidszorg en industriële apparatuurbeheer, is een strikte realtime modus belangrijk.
Responsieve systemen verbeteren de gebruikerservaring en zijn nuttig voor het bedrijf.

Tussentijdse conclusie

Bij het plannen van dit artikel wilde ik mijn ervaring delen over het creëren van een berichtbroker en het bouwen van complexe systemen daarop. Maar het theoretische en motiverende deel is behoorlijk uitgebreid geworden.
In het tweede deel van het artikel zal ik de nuances van de implementatie van uitwisselingspunten, sjablonen voor berichtuitwisseling en hun toepassing bespreken.
In het derde deel zullen we algemene vragen over de organisatie van diensten, routering en balancering behandelen. We zullen het hebben over de praktische kant van schaalbaarheid en foutbestendigheid van systemen.

Einde van het eerste deel.

Foto @lucabravo.

Bron: habr.com