De wereld staat niet stil. Vooruitgang creëert nieuwe technologische uitdagingen. In overeenstemming met veranderende eisen moet de architectuur van informatiesystemen evolueren. Vandaag zullen we het hebben over gebeurtenisgestuurde architectuur, gelijktijdigheid, gelijktijdigheid, asynchronie, en hoe je met dit alles in Erlang vreedzaam kunt leven.
Introductie
Afhankelijk van de grootte van het ontworpen systeem en de eisen die daaraan gesteld worden, kiezen wij als ontwikkelaars de wijze waarop informatie in het systeem wordt uitgewisseld. In de meeste gevallen kan een werkoptie, om de interactie tussen diensten te organiseren, een schema met een makelaar zijn, bijvoorbeeld gebaseerd op RabbitMQ of kafka. Maar soms zijn de stroom aan gebeurtenissen, de SLA en het niveau van controle over het systeem zodanig dat kant-en-klare berichtenuitwisseling niet geschikt is voor ons. Natuurlijk kun je het systeem een beetje ingewikkelder maken door de verantwoordelijkheid te nemen voor de transportlaag en clustervorming, bijvoorbeeld met behulp van ZeroMQ of nanomsg. Maar als het systeem voldoende doorvoer en mogelijkheden heeft van een standaard Erlang-cluster, dan vereist de kwestie van het introduceren van een extra entiteit een gedetailleerde studie en economische rechtvaardiging.
Het onderwerp reactief gedistribueerde applicaties is vrij breed. Om binnen de opzet van het artikel te blijven, zal het onderwerp van de discussie van vandaag uitsluitend gaan over homogene omgevingen gebouwd op Erlang/Elixir. Met het Erlang/OTP-ecosysteem kunt u met de minste inspanning een reactieve architectuur implementeren. Maar in ieder geval hebben we een berichtenlaag nodig.
Theoretische basis
Ontwerp begint met het definiëren van doelen en beperkingen. Het hoofddoel ligt niet op het gebied van ontwikkeling omwille van de ontwikkeling. We hebben een veilige en schaalbare tool nodig op basis waarvan we moderne applicaties van verschillende niveaus kunnen creëren en, belangrijker nog, ontwikkelen: beginnend met applicaties op één server die een klein publiek bedienen, die zich later kunnen ontwikkelen tot clusters van maximaal 50 -60 knooppunten, eindigend met clusterfederaties. Het belangrijkste doel is dus om de winst te maximaliseren door de kosten van ontwikkeling en eigendom van het uiteindelijke systeem te verlagen.
Laten we de vier belangrijkste vereisten voor het uiteindelijke systeem benadrukken:
- Сevenementgericht.
Het systeem staat altijd klaar om de stroom van gebeurtenissen te doorlopen en de nodige acties uit te voeren; - Мschaalbaarheid.
Individuele blokken kunnen zowel verticaal als horizontaal worden geschaald. Het hele systeem moet in staat zijn tot oneindige horizontale groei; - Оfouttolerantie.
Alle niveaus en alle diensten moeten automatisch kunnen herstellen van storingen; - Гgegarandeerde responstijd.
Tijd is kostbaar en gebruikers moeten niet te lang wachten.
Herinner je je het oude sprookje nog over “De kleine motor die dat kon”? Om het ontworpen systeem met succes de prototypefase te laten verlaten en vooruitstrevend te zijn, moet de basis ervan aan de minimale eisen voldoen SMOG.
Er wordt nog een punt toegevoegd aan messaging als infrastructuurtool en de basis voor alle diensten: gebruiksgemak voor programmeurs.
Evenementgericht
Wil een applicatie van een enkele server naar een cluster kunnen groeien, dan moet de architectuur losse koppeling ondersteunen. Het asynchrone model voldoet aan deze eis. Daarin zorgen de afzender en de ontvanger voor de informatiebelasting van het bericht en hoeven ze zich geen zorgen te maken over de verzending en routering binnen het systeem.
Schaalbaarheid
Schaalbaarheid en systeemefficiëntie liggen naast elkaar. Applicatiecomponenten moeten alle beschikbare bronnen kunnen benutten. Hoe efficiënter we de capaciteit kunnen benutten en hoe optimaler onze verwerkingsmethoden, hoe minder geld we uitgeven aan apparatuur.
Binnen één enkele machine creëert Erlang een zeer competitieve omgeving. De balans tussen gelijktijdigheid en parallellisme kan worden ingesteld door het aantal besturingssysteemthreads te kiezen dat beschikbaar is voor de Erlang VM en het aantal planners dat deze threads gebruikt.
Erlang-processen delen geen status en werken in een niet-blokkerende modus. Dit zorgt voor een relatief lage latentie en een hogere doorvoer dan traditionele op blokkering gebaseerde applicaties. De planner van Erlang zorgt voor een eerlijke toewijzing van CPU en IO, en door de afwezigheid van blokkering kan de applicatie zelfs reageren tijdens piekbelastingen of storingen.
Op clusterniveau bestaat het probleem met de verwijdering ook. Het is belangrijk dat alle machines in het cluster gelijkmatig worden belast en dat het netwerk niet overbelast raakt. Laten we ons een situatie voorstellen: gebruikersverkeer komt terecht op inkomende balancers (haproxy, nginx, enz.), zij verdelen verwerkingsverzoeken zo gelijkmatig mogelijk over de set beschikbare backends. Binnen de applicatie-infrastructuur bevindt de dienst die de vereiste interface implementeert zich pas in de laatste fase en zal een aantal andere diensten moeten aanvragen om op het initiële verzoek te reageren. Interne verzoeken vereisen ook routering en balancering.
Om datastromen effectief te kunnen beheren, moet messaging ontwikkelaars een interface bieden om routing en load-balancing te beheren. Dankzij dit kunnen ontwikkelaars, met behulp van microservicepatronen (aggregator, proxy, chain, branch, enz.), zowel standaardproblemen als problemen die zich zelden voordoen, oplossen.
Vanuit zakelijk oogpunt is schaalbaarheid een van de risicobeheerinstrumenten. Het belangrijkste is om aan de verzoeken van klanten te voldoen door de apparatuur optimaal te gebruiken:
- Wanneer de kracht van apparatuur toeneemt als gevolg van vooruitgang. Het zal niet stilzitten vanwege onvolmaakte software. Erlang schaalt verticaal goed en zal altijd alle CPU-kernen en beschikbaar geheugen kunnen gebruiken;
- In cloudomgevingen kunnen we de hoeveelheid apparatuur beheren afhankelijk van de huidige of voorspelde belasting en SLA garanderen.
fout tolerantie
Laten we twee axioma's eens bekijken: 'Mislukkingen zijn onaanvaardbaar' en 'Er zullen altijd mislukkingen zijn.' Voor een bedrijf betekent een softwarefout geldverlies, en wat nog erger is, reputatieverlies. Als je een evenwicht zoekt tussen mogelijke verliezen en de kosten van het ontwikkelen van fouttolerante software, kan er vaak een compromis worden gevonden.
Op de korte termijn bespaart een architectuur waarin fouttolerantie is opgenomen geld bij de aanschaf van kant-en-klare clusteroplossingen. Ze zijn duur en ze hebben ook bugs.
Op de lange termijn betaalt een fouttolerante architectuur zichzelf in alle ontwikkelingsfasen vele malen terug.
Dankzij berichten binnen de codebasis kunt u de interactie van componenten binnen het systeem in de ontwikkelingsfase gedetailleerd uitwerken. Dit vereenvoudigt de taak van het reageren op en beheren van storingen, aangezien alle kritieke componenten storingen afhandelen en het resulterende systeem weet hoe het na een ontwerpfout automatisch weer normaal kan worden.
Ontvankelijkheid
Ongeacht eventuele storingen moet de applicatie reageren op verzoeken en voldoen aan de SLA. De realiteit is dat mensen niet willen wachten, dus bedrijven moeten zich dienovereenkomstig aanpassen. Er wordt verwacht dat steeds meer applicaties zeer responsief zijn.
Responsieve applicaties werken vrijwel in realtime. Erlang VM werkt in zachte real-time modus. Voor sommige gebieden, zoals aandelenhandel, geneeskunde en controle van industriële apparatuur, is de harde realtime-modus belangrijk.
Responsieve systemen verbeteren de UX en komen het bedrijf ten goede.
Voorlopig resultaat
Bij het plannen van dit artikel wilde ik mijn ervaring delen met het creëren van een berichtenmakelaar en het bouwen van complexe systemen op basis daarvan. Maar het theoretische en motiverende deel bleek behoorlijk uitgebreid.
In het tweede deel van het artikel zal ik het hebben over de nuances van het implementeren van uitwisselingspunten, berichtenpatronen en hun toepassing.
In het derde deel zullen we algemene kwesties van het organiseren van diensten, routering en balancering bespreken. Laten we het hebben over de praktische kant van schaalbaarheid en fouttolerantie van systemen.
Einde van het eerste deel.
foto .
Bron: www.habr.com