Jaotatud rakenduste ehitusplokkide. Esimene lähenemine

Eelmisel artiklis Me käsitlesime reaktiivse arhitektuuri teoreetilisi aluseid. On aeg rääkida andmevoogudest, reaktiivsete Erlang/Elixir süsteemide elluviimise viisidest ja nende sõnumivahetuse mustritest:

• Päring-vastus
• Päring-osaline vastus
• Vastus päringu alusel
• Avalda-telli
• Pöördprotsesside ülekandmine
• Ülesannete jaotamine

SOA, MSA ja sõnumivahetus

SOA ja MSA on süsteemiarhitektuurid, mis määravad süsteemide ülesehituse reeglid, samas kui sõnumivahetus pakub nende rakendamiseks primitiive.

Ma ei soovi propageerida ühte ega teist süsteemide arhitektuuri. Ma olen selle poolt, et rakendada konkreetsele projektile ja ettevõttele maksimaalselt efektiivseid ja kasulikke praktikaid. Millist paradigmat me ei valiks, on süsteemide plokkide loomine parem Unix-way järgi: komponentide minimaalne seos, mis vastutavad eraldi entiteetide eest. API meetodid teevad entiteetidega võimalikult lihtsaid toiminguid.

Sõnumivahetus – nagu nimest järeldub – on sõnumi vahendaja. Selle põhieesmärk on sõnumite vastuvõtt ja edastamine. See vastutab teabe saatmise liideste, loogiliste teabeedastuskanalite loomise, marsruutimise ja tasakaalustamise ning süsteemitasandi rikete töötlemise eest.
Arendatav sõnumivahetus ei püüa konkureerida rabbitmq-ga ega asendada seda. Selle peamised omadused on:

• Jagatud olemus.
  Vahetuspunktid saab luua kõikides klastriteosades, maksimaalselt lähedale koodile, mis neid kasutab.
• Lihtsus.
  Minimaalne malli koodi ja kasutusmugavuse suund.
• Parim jõudlus.
  Me ei püüa kopeerida rabbitmq funktsionaalsust, vaid eristame ainult arhitektuurilist ja transpordikihti, mille integreerimine OTP-sse on võimalikult lihtne, minimeerides kulusid.
• Paindlikkus.
  Iga teenus võib hõlmata mitmeid sõnumivahetuse mustreid.
• Tõrketaluvus, mis on sisustatud disaini.
• Skaleeritavus.
  Sõnumivahetus kasvab koos rakendusega. Koormuse suurenedes saate vahetuspunktid eraldi masinatesse viia.

Märkus. Koodiorganisatsiooni seisukohalt sobivad keerukate süsteemide jaoks Erlangi/Elixiri metaprojektid hästi. Kogu projekti kood asub ühes hoidlas ‒ katuseprojekti all. Sellega samal ajal on mikroteenused maksimaalselt eraldatud ja teevad lihtsaid operatsioone, mis vastavad eraldi entiteedile. Sellise lähenemisega on lihtne toetada kogu süsteemi API-d, hõlpsasti teha muudatusi ja mugavalt kirjutada üksus- ja integreerimisteste.

Süsteemi komponendid suhtlevad vahetult või läbi maakleri. Messaging'u seisukohalt on igal teenusel mitu eluetappi:

• Teenuse initsialiseerimine.
  Sellel etapil toimub teenuse käitamisprotsessi ja sõltuvuste konfigureerimine ja käivitamine.
• Vahetuspunkti loomine.
  Teenusel võib olla staatiline vahetuspunkt, mis on määratud sõlme konfiguratsioonis, või võib see luua vahetuspunktid dünaamiliselt.
• Teenuse registreerimine.
  Kuna teenus peab teenindama päringuid, tuleb see registreerida vahetuspunktis.
• Normaalne toimimine.
  Teenuse kasulik töö.
• Töö lõpetamine.
  Töö lõpetamiseks on kaks varianti: regulaarne ja avarii. Regulaarse lõpetamise korral katkestatakse teenus vahetuspunktist ja peatub. Avarii korral täidab messaging ühe tõrke töötlemise stsenaariumidest.

See tundub üsna keeruline, kuid koodis pole kõik nii hirmus. Koodinäidised koos kommentaaridega esitatakse malle käsitlevas osas veidi hiljem.

Vahetused

Vahetuspunkt on messaging'u protsess, mis rakendab loogikat komponentide vahelise suhtluse jaoks vastavalt sõnumivahetuse malli. Kõikidel allpool esitatud näidistel suhtlevad komponendid vahetuspunktide kaudu, mille kombinatsioon moodustab messaging'u.

Sõnumivahetuse mustrid (MEP-d)

Globaalsete mustrite kohaselt võib vahetused jaotada kahepoolsed ja ühekordsed. Esimene neist eeldab vastust saabunud sõnumile, teine aga mitte. Kliendi-serveri arhitektuuris on klassikaliseks näiteks kahepoolne mustri malli Request-response. Vaatame mustrit ja selle modifikatsioone.

Request–response või RPC

RPC-d kasutatakse siis, kui me peame saama vastuse teisest protsessist. See protsess võib töötada samal sõlmel või asuda teisel kontinendil. Allpool on esitatud skeem kliendi ja serverilt vahetuspunkti kaudu.

Kuna messaging on täielikult asünkroonne, jaguneb kliendi vahetus kaheks faasiks:

1. Päringu saatmine

   messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).

   Exchange ‒ unikaalne vahetuspunkti nimi
   ResponseMatchingTag ‒ kohalik silt vastuse töötlemiseks. Näiteks, kui saadetakse mitu sama taotlust erinevatelt kasutajatelt.
   RequestDefinition ‒ taotluse keha
   HandlerProcess ‒ töötleja PID. See protsess saab serverilt vastuse.

2. Vastuse töötlemine

   handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)

   ResponsePayload ‒ serveri vastus.

Serveri protsess koosneb ka kahest faasist:

1. Vahetuspunkti initsialiseerimine
2. Saadetud taotluste töötlemine

Ilustreerime seda näidet koodiga. Oletame, et peame rakendama lihtsat teenust, mis pakkub ainukest täpset aja meetodit.

Serveri kood

Viime teenuse API määratlemise api.hrl faili:

%% =====================================================
%%  entities
%% =====================================================
-record(time, {
  unixtime :: non_neg_integer(),
  datetime :: binary()
}).

-record(time_error, {
  code :: non_neg_integer(),
  error :: term()
}).

%% =====================================================
%%  methods
%% =====================================================
-record(time_req, {
  opts :: term()
}).
-record(time_resp, {
  result :: #time{} | #time_error{}
}).

Määratleme teenuse kontrolleri time_controller.erl

%% Näites on näidatud vaid oluline kood. Selle lisamine gen_server mallile annab töötava teenuse.

%% gen_serveri initsialiseerimine
init(Args) ->
  %% ühendamine vahetuspunktiga
  messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())
  {ok, #{}}.

%% kontakt kaotamise sündmuse töötlemine vahetuspunktiga. Sama sündmus esitatakse, kui vahetuspunkt pole veel käivitatud.
handle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->
  erlang:send(self(), monitor_exchange),
  {noreply, State};

%% API töötlemine
handle_info(#time_req{opts = _Opts}, State) ->
  messaging:response_once(Client, #time_resp{
result = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())}
  });
  {noreply, State};

%% gen_serveri lõpetamine
terminate(_Reason, _State) ->
  messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),
  ok.

Kliendi kood

Kliendis teenusele päringu saatmiseks saab igal pool kutsuda messaging request API-d:

case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of
    ok -> ok;
    _ -> %% kordamise või ebaõnnestumise loogika
end

Jaotatud süsteemis võivad komponentide konfiguratsioonid olla erinevad ning päringu ajal ei pruugi messaging käivituda või teenuse kontroller ei pruugi päringut teenindamiseks valmis olla. Seetõttu peame kontrollima messagingu vastust ja töötlema ebaõnnestumise juhtumi.
Pärast eduka saatmise korral saab klient teenuselt vastuse või vea.
Käsitleme mõlemat juhtumit handle_info-s:

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) ->
  ?debugVal(Utime),
  {noreply, State};

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) ->
  ?debugVal({error, ErrorCode}),
  {noreply, State};

Päring-osaline vastus

Suurem sõnumite saatmine ei ole soovitatav. See mõjutab kogu süsteemi reageerimist ja stabiilsust. Kui vastus päringule võtab palju mälu, on jagamine osadeks hädavajalik.

Tooksin paar sellist juhtumit:

• Komponendid vahetavad binaarandmeid, näiteks faile. Vastuse jagamine väikesteks osadeks aitab tõhusalt töötada mis tahes suurusega failidega ning vältida mälu ülevoolu.
• Loendid. Näiteks peame valima kõik kirjed tohutust andmebaasi tabelist ja saatma need teisele komponendile.

Ma kutsun selliseid vastuseid veduriteks. Igatahes on 1024 sõnumit, igaühes 1 MB, parem kui üksainus sõnum, mille suurus on 1 GB.

Erlangi klastris saame täiendava eelise – koormuse vähendamine vahetuspunktile ja võrgu koormusele, kuna vastused suunatakse otse saajale, mööda vahetuspunkti.

Vastus päringu alusel

See on üsna haruldane RPC-mudeli modifikatsioon dialoogisüsteemide loomisel.

Publish-subscribe (andmete jaotamise puu)

Sündmustepõhised süsteemid toimetavad andmed tarbijatele kohe, kui need on valmis. Nii kalduvad süsteemid pigem push-mudelile kui pull või poll. See omadus võimaldab mitte raisata ressursse, pidevalt küsides ja oodates andmeid.
Joonisel on kujutatud sõnumi edastamise protsessi tarbijatele, kes on registreeritud konkreetse teema jaoks.

Klassikalised näited selle mustri kasutamisest on oleku levitamine: mängumaailma arvutimängudes, turuandmed börsil, kasulik informatsioon andmevoogudes.

Vaatame tellija koodi:

init(_Args) ->
  %% registreerume vahetuspunktis, võti = key
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {ok, #{}}.

handle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->
  %% kui vahetuspunkt pole saadaval, proovime uuesti ühenduda
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {noreply, State};

%% töötleme saabunud sõnumeid
handle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->
  ?debugVal(Msg),
  {noreply, State};

%% tarbija peatamisel katkestame ühenduse vahetuspunktiga
terminate(_Reason, _State) ->
  messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),
  ok.

Allikas võib kutsuda esile sõnumi avaldamise mis tahes soovitud kohas:

messaging:publish_message(Exchange, Key, Message).

Exchange ‒ vahetuspunkti nimi,
Ava ‒ marsruudi võti,
Sõnum, ‒ koormus,

Pöördprotsesside ülekandmine

Pub-sub‘i juurutamine võimaldab saada logimisele mugava mustri. Allikate ja tarbimise komplekt võib olla täiesti erinev. Joonisel on kujutatud olukorda, kus on üks tarbija ja palju allikaid.

Ülesannete jaotamise muster.

Pealmost igas projektis tekivad viivitusega töötlemise ülesanded, nagu aruannete koostamine, teavituste saatmine, andmete saamine väliste süsteemide kaudu. Nende ülesannete täitmise süsteemi läbilaskevõimet saab hõlpsasti skaleerida, lisades töötlejat. Meie ülesanne on moodustada töötlejate klaster ja jaotada ülesanded nende vahel võrdselt.

Vaatleme tekkinud olukordi kolme töötleja näitel. Juba ülesannete jagamise etapis tõuseb esile õigusemõistmise küsimus ja töötlejate ülevoolu vältimine. Õigusemõistmise eest vastutab round-robin jaotamine ning et vältida töötlejate ülevoolu, seame piirangu prefetch_limit. Üleminekuperioodides prefetch_limit ei luba ühelgi töötlejal saada kõiki ülesandeid.

Messsage haldab järjekordi ja töötlemise prioriteete. Töötlejad saavad ülesandeid nende saabumise järjekorras. Ülesande täitmine võib lõppeda kas edukalt või ebaõnnestumisega:

• messaging:ack(Tack) ‒ kutsutakse esile sõnumi eduka töötlemise korral.
• messaging:nack(Tack) ‒ kutsutakse esile igasugustes erakorralistes olukordades. Pärast ülesande tagastamist edastab sõnumiteenus selle teisele töötlejale.

Olgu öeldud, et kolme ülesande töötlemisel toimus keeruline ebaõnnestumine: töötleja 1 kukkus pärast ülesande saamist kokku, ilma et oleks jõudnud vahetuspunktile midagi teatada. Sellisel juhul edastab vahetuspunkt ülesande pärast ack timeout'i möödumist teisele töötlejale. Töötleja 3 keeldus mingil põhjusel ülesandest ja saatis nack'i, lõpuks läks ülesanne ka teisele töötlejale, kes selle edukalt täitis.

Eelkokkuvõte

Oleme käsitlenud jaotatud süsteemide põhikivisid ning omandanud nende rakendamise põhiteadmisi Erlangis/Elixir'is.

Kombineerides põhimustreid, on võimalik luua keerulisi paradigmadesse probleemide lahendamiseks.

Selle tsükli lõpposas käsitleme teenuste korraldust, marsruutimist ja koormuse tasakaalustamist, samuti räägime süsteemide skaleeritavuse ja talitluspidevuse praktilisest küljest.

Teise osa lõpp.

Foto Marius Christensen
Illustratsioonid on koostatud websequencediagrams.com abil.

Allikas: habr.com