🥇Banatutako aplikazioen blokeak eraikitzea. Bigarren hurbilketa

Anuntzio

Lankideok, uda erdialdean ilara-sistemen diseinuari buruzko beste artikulu sorta bat kaleratzeko asmoa dut: "VTrade Experiment" - merkataritza sistemetarako esparru bat idazteko saiakera bat. Serieak truke, enkante eta denda bat eraikitzeko teoria eta praktika aztertuko ditu. Artikuluaren amaieran, gehien interesatzen zaizkizun gaiei botoa ematera gonbidatzen zaituztet.

Hau da Erlang/Elixir-en banatutako aplikazio erreaktiboei buruzko serieko azken artikulua. IN lehen artikulua arkitektura erreaktiboaren oinarri teorikoak aurki ditzakezu. Bigarren artikulua sistema horiek eraikitzeko oinarrizko ereduak eta mekanismoak azaltzen ditu.

Gaur kode-oinarria eta, oro har, proiektuak garatzeko gaiak planteatuko ditugu.

Zerbitzuen antolaketa

Bizitza errealean, zerbitzu bat garatzerakoan, sarritan hainbat interakzio eredu konbinatu behar dituzu kontrolagailu batean. Esaterako, erabiltzaileen zerbitzuak, proiektuaren erabiltzaileen profilak kudeatzeko arazoa konpontzen duena, req-resp eskaerei erantzun behar die eta profilaren eguneraketak jakinarazi behar ditu pub-sub bidez. Kasu hau nahiko erraza da: mezuen atzean zerbitzu-logika inplementatzen duen eta eguneraketak argitaratzen dituen kontrolagailu bat dago.

Egoera zaildu egiten da hutsegite-tolerantzia-zerbitzu banatua ezarri behar dugunean. Imajina dezagun erabiltzaileen eskakizunak aldatu direla:

orain zerbitzuak eskaerak prozesatu beharko lituzke 5 cluster nodoetan,
atzeko planoko prozesatzeko zereginak egiteko gai izan,
eta profila eguneratzeko harpidetza-zerrendak modu dinamikoan kudeatu ahal izango ditu.

komentarioen: Ez dugu kontuan hartzen biltegiratze koherentearen eta datuen erreplikazioaren arazoa. Demagun arazo hauek lehenago konpondu direla eta sistemak biltegiratze geruza fidagarri eta eskalagarria duela jada, eta kudeatzaileek harekin elkarreragiteko mekanismoak dituztela.

Erabiltzaileen zerbitzuaren deskribapen formala zaildu egin da. Programatzaile baten ikuspuntutik, aldaketak gutxienekoak dira mezularitza erabiltzeagatik. Lehenengo eskakizuna betetzeko, oreka konfiguratu behar dugu req-resp truke puntuan.

Atzeko planoko zereginak prozesatzeko eskakizuna maiz gertatzen da. Erabiltzaileetan, hau izan daiteke erabiltzailearen dokumentuak egiaztatzea, deskargatutako multimedia prozesatzea edo datuak sare sozialekin sinkronizatzea. sareak. Zeregin horiek nolabait kluster barruan banatu behar dira eta exekuzioaren aurrerapena kontrolatu. Hori dela eta, bi konponbide-aukera ditugu: edo aurreko artikuluko atazen banaketa txantiloia erabili, edo, komeni ez bazaio, prozesadore multzoa behar dugun moduan kudeatuko duen ataza-antolatzaile pertsonalizatu bat idatzi.

3. puntuak pub-sub txantiloiaren luzapena behar du. Eta ezartzeko, pub-sub truke puntu bat sortu ondoren, gainera, puntu honen kontrolatzailea abiarazi behar dugu gure zerbitzuaren barruan. Horrela, mezularitza-geruzatik harpidetzak eta harpidetzak kentzeko logika erabiltzaileen inplementaziora eramango bagenu bezala da.

Ondorioz, arazoaren deskonposizioak erakutsi zuen baldintzak bete ahal izateko, zerbitzuaren 5 instantzia abiarazi behar ditugula nodo desberdinetan eta entitate gehigarri bat sortu behar dugula - pub-sub kontroladore bat, harpidetzaren arduraduna.
5 kudeatzaile exekutatzeko, ez duzu zerbitzu-kodea aldatu beharrik. Ekintza gehigarri bakarra truke puntuan oreka-arauak ezartzea da, eta horietaz apur bat geroago hitz egingo dugu.
Konplexutasun gehigarri bat ere badago: pub-sub kontroladoreak eta zereginen antolakuntza pertsonalizatuak kopia bakarrean funtzionatu behar dute. Berriz ere, mezularitza-zerbitzuak, oinarrizko gisa, liderra hautatzeko mekanismoa eman behar du.

Liderraren Aukera

Banatutako sistemetan, buruzagi-hautapena karga batzuen prozesamendu banatua programatzeko ardura duen prozesu bakarra izendatzeko prozedura da.

Zentralizaziorako joerarik ez duten sistemetan, algoritmo unibertsalak eta adostasunean oinarritutakoak erabiltzen dira, hala nola paxoak edo baltsa.
Mezularitza artekaria eta elementu zentrala denez, zerbitzu-kontrolatzaile guztiak ezagutzen ditu: hautagaien liderrak. Mezularitzak buruzagi bat izenda dezake botorik gabe.

Truke puntura hasi eta konektatu ondoren, zerbitzu guztiek sistema-mezu bat jasotzen dute #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Bada LeaderPid batekin bat dator pid egungo prozesua, buru izendatzen da, eta zerrenda Servers nodo guztiak eta haien parametroak biltzen ditu.
Berri bat agertzen den unean eta lanean ari den cluster-nodo bat deskonektatzen den unean, zerbitzu-kontrolatzaile guztiek jasotzen dute #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} hurrenez hurren.

Horrela, osagai guztiek aldaketa guztien berri izaten dute, eta klusterrak lider bat izango duela bermatuta dago une bakoitzean.

Bitartekariak

Banatutako prozesamendu prozesu konplexuak ezartzeko, baita lehendik dagoen arkitektura bat optimizatzeko arazoetan ere, bitartekariak erabiltzea komeni da.
Zerbitzu-kodea ez aldatzeko eta, adibidez, prozesatzeko, bideratzeko edo erregistratzeko mezu gehigarrien arazoak konpontzeko, zerbitzuaren aurretik proxy-kudeatzaile bat gaitu dezakezu, lan osagarri guztiak egingo dituena.

Pub-sub optimizazioaren adibide klasiko bat eguneratze-gertaerak sortzen dituen negozio-nukleoa duen aplikazio banatua da, hala nola merkatuan prezio-aldaketak, eta sarbide-geruza bat - web bezeroentzako websocket API bat eskaintzen duten N zerbitzariak.
Aurrez erabakitzen baduzu, bezeroarentzako arreta-zerbitzua honelakoa izango da:

bezeroak plataformarekin konexioak ezartzen ditu. Trafikoa amaitzen duen zerbitzariaren aldean, prozesu bat abiarazten da konexio honi zerbitzua emateko.
Zerbitzu-prozesuaren testuinguruan, eguneratzeetarako baimena eta harpidetza gertatzen dira. Prozesuak gaietarako harpidetza metodoa deitzen du.
Gertaera bat nukleoan sortzen denean, konexioak zerbitzatzen dituzten prozesuetara entregatzen da.

Pentsa dezagun 50000 harpidedun ditugula "berriak" gaian. Harpidedunak berdin banatzen dira 5 zerbitzarietan. Ondorioz, eguneratze bakoitza, truke puntura iristen dena, 50000 aldiz errepikatuko da: 10000 aldiz zerbitzari bakoitzean, bertan dagoen harpidedun kopuruaren arabera. Ez da oso eskema eraginkorra, ezta?
Egoera hobetzeko, sar dezagun truke puntuaren izen bera duen proxy bat. Izen erregistratzaile globalak hurbilen dagoen prozesua izenez itzultzeko gai izan behar du, hau garrantzitsua da.

Abiarazi dezagun proxy hau sarbide-geruzen zerbitzarietan, eta websocket APIa zerbitzatzen duten gure prozesu guztiak harpidetuko dira, eta ez nukleoko jatorrizko pub-sub truke puntura. Proxy-k harpidetza bakarraren kasuan soilik harpidetzen du corera eta sarrerako mezua bere harpidedun guztiei errepikatzen die.
Ondorioz, 5 mezu bidaliko dira nukleoaren eta sarbide zerbitzarien artean, 50000ren ordez.

Bideratzea eta orekatzea

Eskaera-Erresp

Egungo mezularitza inplementazioan, eskaerak banatzeko 7 estrategia daude:

default. Eskaera kontrolatzaile guztiei bidaltzen zaie.
round-robin. Eskaerak zenbatzen eta ziklikoki banatzen dira kontrolatzaileen artean.
consensus. Zerbitzua zerbitzatzen duten kontrolatzaileak buruzagi eta esklaboetan banatzen dira. Eskaerak liderrari bakarrik bidaltzen zaizkio.
consensus & round-robin. Taldeak lider bat du, baina eskaerak kide guztien artean banatzen dira.
sticky. Hash funtzioa kalkulatzen da eta kudeatzaile zehatz bati esleitzen zaio. Sinadura honekin ondorengo eskaerak kudeatzaile berera joaten dira.
sticky-fun. Truke-puntua hasterakoan, hash kalkulurako funtzioa sticky orekatzeko.
fun. Sticky-fun-en antzera, zuk bakarrik birbideratu, baztertu edo aurrez prozesatu dezakezu.

Banaketa-estrategia truke-puntua hasieratzen denean ezartzen da.

Orekatzeaz gain, mezuak entitateak etiketatzeko aukera ematen du. Ikus ditzagun sistemako etiketa motak:

Konexio-etiketa. Gertaerak zein konexioren bidez gertatu diren ulertzeko aukera ematen du. Kontrolagailu-prozesu bat truke-puntu berdinera konektatzen denean erabiltzen da, baina bideratze-gako desberdinekin.
Zerbitzu-etiketa. Kudeatzaileak zerbitzu bakarrerako taldetan konbinatzeko eta bideratze- eta orekatzeko gaitasunak zabaltzeko aukera ematen du. Req-resp eredurako, bideratzea lineala da. Eskaera bat truke puntura bidaltzen dugu, gero zerbitzura pasatzen du. Baina kudeatzaileak talde logikoetan banatu behar baditugu, orduan zatiketa etiketak erabiliz egiten da. Etiketa bat zehaztean, eskaera kontrolatzaile talde jakin batera bidaliko da.
Eskatu etiketa. Erantzunak bereizteko aukera ematen du. Gure sistema asinkronoa denez, zerbitzuaren erantzunak prozesatzeko RequestTag bat zehaztu behar dugu eskaera bat bidaltzean. Bertatik ulertu ahal izango dugu zein eskaerari heldu zitzaigun erantzuna.

Pub-sub

Pub-subentzat dena apur bat sinpleagoa da. Mezuak argitaratzen diren truke-puntu bat dugu. Truke puntuak mezuak banatzen ditu behar dituzten bideratze-gakoetara harpidetuta dauden harpidedunen artean (esan dezakegu gaien antzekoa dela).

Eskalagarritasuna eta akatsen tolerantzia

Sistema osoaren eskalagarritasuna sistemaren geruzen eta osagaien eskalagarritasun-mailaren araberakoa da:

Zerbitzuak zerbitzu honen kudeatzaileak dituzten clusterra nodo gehigarriak gehituz eskalatzen dira. Probako funtzionamenduan, orekatze-politika optimoa hauta dezakezu.
Mezularitza-zerbitzua bera aparteko kluster batean eskalatzen da, bai bereziki kargatutako truke-puntuak kluster-nodo bereizietara eramanez, edo proxy-prozesuak gehituz klusterraren eremu bereziki kargatuta.
Sistema osoaren eskalagarritasuna ezaugarri gisa arkitekturaren malgutasunaren eta kluster indibidualak entitate logiko komun batean konbinatzeko gaitasunaren araberakoa da.

Proiektu baten arrakasta sarritan eskalatzearen sinpletasunaren eta abiaduraren araberakoa da. Egungo bertsioko mezularitza aplikazioarekin batera hazten da. Nahiz eta 50-60 makinako multzo bat falta zaigun, federaziora jo dezakegu. Zoritxarrez, federazioaren gaia artikulu honen esparrutik kanpo dago.

Erreserba

Karga-orekatzea aztertzerakoan, zerbitzu-kontrolagailuen erredundantziari buruz hitz egin dugu. Hala ere, mezularitza ere gorde behar da. Nodo edo makina hutsegite bat gertatuz gero, mezuak automatikoki berreskuratu beharko lirateke eta ahalik eta denbora laburrenean.

Nire proiektuetan erorketaren kasuan karga jasotzen duten nodo gehigarriak erabiltzen ditut. Erlang-ek OTP aplikazioetarako modu banatuko inplementazio estandarra du. Banatutako moduak hutsegite kasuan berreskuratzea egiten du huts egindako aplikazioa aurretik abiarazitako beste nodo batean abiaraziz. Prozesua gardena da; hutsegite baten ondoren, aplikazioa automatikoki hutsegite-nodora mugitzen da. Funtzio honi buruz gehiago irakur dezakezu Hemen.

produktibitatea

Saia gaitezen gutxi gorabehera rabbitmq-en errendimendua eta gure mezu pertsonalizatuak alderatzen.
aurkitu dut emaitza ofizialak openstack taldeko rabbitmq probak.

6.14.1.2.1.2.2 paragrafoan. Jatorrizko dokumentuak RPC CAST-en emaitza erakusten du:

Ez dugu ezarpen gehigarririk egingo OS kernelean edo erlang VM-n aldez aurretik. Probak egiteko baldintzak:

erl aukerak: +A1 +sbtu.
Erlang nodo bakarreko proba i7 zahar bat duen ordenagailu eramangarri batean exekutatzen da mugikorreko bertsioan.
Kluster probak 10G sareko zerbitzarietan egiten dira.
Kodea docker edukiontzietan exekutatzen da. Sarea NAT moduan.

Proba kodea:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

1. eszenatokia: Proba i7 mugikorren bertsio zaharra duen ordenagailu eramangarri batean egiten da. Proba, mezularitza eta zerbitzua Docker edukiontzi bateko nodo batean exekutatzen dira:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

2. eszenatokia: Docker azpian (NAT) makina ezberdinetan exekutatzen diren 3 nodo.

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

Kasu guztietan, CPUaren erabilera ez zen %250etik gorakoa izan.

Emaitzak

Espero dut ziklo honek ez duela pentsamendu-zabortegi baten itxura izatea eta nire esperientziak benetako onuragarria izatea bai sistema banatuen ikertzaileentzat, bai beren negozio-sistemetarako arkitektura banatuak eraikitzen hasi eta Erlang/Elixir-i interes handiz begiratzen ari diren profesionalentzat. , baina duda izan merezi al du...

Photo Shoot @chuttersnap

Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. Hasi saioa, mesedez.

Zein gai landu behar ditut xehetasun gehiago VTrade Experiment seriearen barruan?

Teoria: Merkatuak, eskaerak eta haien denborak: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
Aginduen liburua. Taldekatzeekin liburu bat gauzatzeko teoria eta praktika
Negoziazioen bistaratzea: Ticks, barrak, ebazpenak. Nola gorde eta nola itsatsi
Backoffice. Plangintza eta garapena. Langileen jarraipena eta gertakarien ikerketa
APIa. Ikus dezagun zer interfaze behar diren eta nola inplementatu
Informazio biltegiratzea: PostgreSQL, Timescale, Tarantool merkataritza sistemetan
Erreaktibitatea merkataritza-sistemetan
Bestela. Iruzkinetan idatziko dut

6 erabiltzailek eman dute botoa. 4 erabiltzaile abstenitu ziren.

Iturria: www.habr.com

Banatutako aplikazioen eraikuntza-blokeak. Bigarren hurbilketa