🥇 Byggingareiningar dreifðra forrita. Önnur nálgun

Tilkynning

Samstarfsmenn, um mitt sumar ætla ég að gefa út aðra röð greina um hönnun biðraðakerfa: „VTrade Experiment“ - tilraun til að skrifa ramma fyrir viðskiptakerfi. Röðin mun skoða kenninguna og framkvæmdina við að byggja upp kauphöll, uppboð og verslun. Í lok greinarinnar býð ég þér að kjósa þau efni sem vekur mestan áhuga þinn.

Þetta er lokagreinin í seríunni um dreifð hvarfgjörn forrit í Erlang/Elixir. IN fyrstu grein þú getur fundið fræðilegan grunn hvarfgjarnrar byggingarlistar. Önnur grein sýnir grunnmynstur og aðferðir til að smíða slík kerfi.

Í dag munum við taka upp mál um þróun kóðagrunnsins og verkefni almennt.

Skipulag þjónustu

Í raunveruleikanum, þegar þú þróar þjónustu, þarftu oft að sameina nokkur samskiptamynstur í einum stjórnanda. Til dæmis þarf notendaþjónustan, sem leysir vandamálið við að stjórna notendasniðum verkefna, að bregðast við beiðnum um beiðnir og tilkynna um uppfærslur á prófílnum í gegnum pub-sub. Þetta mál er frekar einfalt: á bak við skilaboð er einn stjórnandi sem útfærir þjónusturökfræðina og birtir uppfærslur.

Staðan verður flóknari þegar við þurfum að innleiða bilunarþolna dreifða þjónustu. Ímyndum okkur að kröfurnar til notenda hafi breyst:

nú ætti þjónustan að vinna úr beiðnum um 5 klasahnúta,
geta framkvæmt bakgrunnsvinnsluverkefni,
og einnig vera fær um að stjórna áskriftarlistum fyrir uppfærslur á prófílnum á virkan hátt.

Athugasemd: Við lítum ekki á spurninguna um stöðuga geymslu og afritun gagna. Gerum ráð fyrir að þessi mál hafi verið leyst fyrr og kerfið er nú þegar með áreiðanlegt og skalanlegt geymslulag og meðhöndlarar hafa kerfi til að hafa samskipti við það.

Formleg lýsing á notendaþjónustunni hefur orðið flóknari. Frá sjónarhóli forritara eru breytingar í lágmarki vegna notkunar skilaboða. Til að uppfylla fyrstu kröfuna þurfum við að stilla jafnvægi á req-resp skiptipunktinum.

Krafan um að vinna úr bakgrunnsverkefnum kemur oft fram. Hjá notendum gæti þetta verið að athuga notendaskjöl, vinna niðurhalað margmiðlun eða samstilla gögn við samfélagsmiðla. netkerfi. Þessum verkefnum þarf að dreifa á einhvern hátt innan klasans og fylgjast með framvindu framkvæmdarinnar. Þess vegna höfum við tvo lausnarmöguleika: annað hvort notaðu verkdreifingarsniðmátið úr fyrri grein, eða, ef það hentar ekki, skrifaðu sérsniðna verkefnaáætlun sem mun stjórna hópi örgjörva á þann hátt sem við þurfum.

Liður 3 krefst pub-sub sniðmátsframlengingarinnar. Og til innleiðingar, eftir að hafa búið til krá-undir-skiptapunkt, þurfum við að auka stjórnandi þessa punkts innan þjónustu okkar. Þannig er eins og við séum að færa rökfræðina fyrir vinnslu áskrifta og afskráninga úr skilaboðalaginu yfir í innleiðingu notenda.

Fyrir vikið sýndi niðurbrot vandans að til að uppfylla kröfurnar þurfum við að ræsa 5 tilvik af þjónustunni á mismunandi hnútum og búa til viðbótareiningu - krá-undirstjóra, sem ber ábyrgð á áskriftinni.
Til að keyra 5 meðferðaraðila þarftu ekki að breyta þjónustukóðanum. Eina viðbótaraðgerðin er að setja upp jöfnunarreglur á skiptipunktinum, sem við munum tala um aðeins síðar.
Það er líka flókið til viðbótar: krá-undirstýringin og sérsniðinn verkefnaáætlun verður að vinna í einu eintaki. Aftur verður skilaboðaþjónustan, sem grundvallaratriði, að bjóða upp á kerfi til að velja leiðtoga.

Leiðtogaval

Í dreifðum kerfum er leiðtogakjör aðferðin til að skipa eitt ferli sem ber ábyrgð á að skipuleggja dreifða vinnslu á einhverju álagi.

Í kerfum sem eru ekki viðkvæm fyrir miðstýringu eru alhliða reiknirit sem byggir á samstöðu, eins og paxos eða raft, notuð.
Þar sem skilaboð eru miðlari og miðlægur þáttur veit það um alla þjónustustjóra - leiðtoga umsækjenda. Skilaboð geta skipað leiðtoga án þess að greiða atkvæði.

Eftir ræsingu og tengingu við skiptipunkt fá öll þjónusta kerfisskilaboð #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Ef LeaderPid fellur saman við pid núverandi ferli, það er skipað sem leiðtogi, og listinn Servers inniheldur alla hnúta og færibreytur þeirra.
Í augnablikinu sem nýr birtist og starfandi klasahnútur er aftengdur, fá allir þjónustustýringar #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} sig.

Þannig eru allir þættir meðvitaðir um allar breytingar og tryggt er að þyrpingin hafi einn leiðtoga á hverjum tíma.

Sáttasemjari

Til að innleiða flókin dreifð vinnsluferli, sem og í vandamálum við að hagræða núverandi arkitektúr, er þægilegt að nota milliliði.
Til þess að breyta ekki þjónustukóðanum og leysa td vandamál með viðbótarvinnslu, leiðarlýsingu eða skráningu skilaboða, geturðu virkjað umboðsmann fyrir þjónustuna, sem mun framkvæma alla viðbótarvinnu.

Klassískt dæmi um hagræðingu á krá-undirbúum er dreift forrit með viðskiptakjarna sem býr til uppfærsluviðburði, svo sem verðbreytingar á markaðnum, og aðgangslag - N netþjónar sem bjóða upp á vefsocket API fyrir vefbiðlara.
Ef þú ákveður beint, lítur þjónusta við viðskiptavini svona út:

viðskiptavinurinn kemur á tengslum við vettvanginn. Á hlið þjónsins sem stöðvar umferðina er sett af stað ferli til að þjónusta þessa tengingu.
Í tengslum við þjónustuferlið á sér stað heimild og áskrift að uppfærslum. Ferlið kallar áskriftaraðferðina fyrir efni.
Þegar atburður er búinn til í kjarnanum er hann afhentur ferlunum sem þjónusta tengingarnar.

Við skulum ímynda okkur að við höfum 50000 áskrifendur að efninu „fréttum“. Áskrifendum er dreift jafnt yfir 5 netþjóna. Þess vegna verður hver uppfærsla, sem kemur á skiptistöð, endurtekin 50000 sinnum: 10000 sinnum á hverjum netþjóni, í samræmi við fjölda áskrifenda á honum. Ekki mjög áhrifaríkt kerfi, ekki satt?
Til að bæta ástandið skulum við kynna umboð sem ber sama nafn og skiptipunkturinn. Alheimsnafnaskrárinn verður að geta skilað næsta ferli með nafni, þetta er mikilvægt.

Við skulum ræsa þennan proxy á aðgangslagsþjónunum og öll ferli okkar sem þjóna websocket API gerast áskrifandi að því, en ekki upprunalega pub-sub skiptipunktinum í kjarnanum. Umboð gerist aðeins áskrifandi að kjarnanum ef um einstaka áskrift er að ræða og endurtekur skilaboðin sem berast til allra áskrifenda sinna.
Fyrir vikið verða send 5 skilaboð á milli kjarnans og aðgangsþjónanna í stað 50000.

Leiðsögn og jafnvægi

Req-Resp

Í núverandi útfærslu skilaboða eru 7 dreifingaraðferðir fyrir beiðnir:

default. Beiðnin er send til allra stjórnenda.
round-robin. Beiðnir eru taldar upp og dreift á milli stjórnenda.
consensus. Stjórnendurnir sem þjóna þjónustunni skiptast í leiðtoga og þræla. Beiðnir eru eingöngu sendar til leiðtoga.
consensus & round-robin. Hópurinn er með leiðtoga en beiðnum er dreift á alla meðlimi.
sticky. Hash aðgerðin er reiknuð út og úthlutað til ákveðins meðhöndlunar. Síðari beiðnir með þessari undirskrift fara til sama meðferðaraðila.
sticky-fun. Þegar skiptipunkturinn er frumstilltur er kjötkássaútreikningsaðgerðin fyrir sticky jafnvægi.
fun. Svipað og klístur-skemmtilegt, aðeins þú getur til viðbótar beina því, hafnað eða forvinnið það.

Dreifingarstefnan er stillt þegar skiptipunkturinn er frumstilltur.

Auk jafnvægis gerir skilaboð þér kleift að merkja aðila. Við skulum skoða tegundir merkja í kerfinu:

Tengimerki. Gerir þér kleift að skilja í gegnum hvaða tengingu atburðir komu. Notað þegar stjórnandi ferli tengist sama skiptipunkti, en með mismunandi leiðarlyklum.
Þjónustumerki. Gerir þér kleift að sameina meðhöndlara í hópa fyrir eina þjónustu og auka leiðar- og jafnvægismöguleika. Fyrir req-resp mynstrið er leiðin línuleg. Við sendum beiðni til skiptistöðvarinnar og sendir hana síðan áfram til þjónustunnar. En ef við þurfum að skipta meðhöndlunum í rökræna hópa, þá er skiptingin gerð með því að nota merki. Þegar merki er tilgreint verður beiðnin send til ákveðins hóps stýrimanna.
Biðja um merki. Gerir þér kleift að greina á milli svara. Þar sem kerfið okkar er ósamstillt, til að vinna úr þjónustusvörum þurfum við að geta tilgreint RequestTag þegar beiðni er send. Út frá því munum við geta skilið svarið við hvaða beiðni kom til okkar.

Pub-sub

Fyrir pub-sub er allt aðeins einfaldara. Við erum með skiptipunkt sem skilaboð eru birt til. Skiptipunkturinn dreifir skilaboðum meðal áskrifenda sem hafa gerst áskrifandi að leiðarlyklum sem þeir þurfa (við getum sagt að þetta sé hliðstætt efni).

Sveigjanleiki og bilanaþol

Sveigjanleiki kerfisins í heild fer eftir því hversu sveigjanlegur laga og íhlutir kerfisins eru:

Þjónusta er stækkuð með því að bæta við viðbótarhnútum við þyrpinguna með meðhöndlum fyrir þessa þjónustu. Meðan á prufuaðgerð stendur geturðu valið bestu jöfnunarstefnuna.
Skilaboðaþjónustan sjálf innan sérstakrar klasa er almennt stækkuð annað hvort með því að færa sérstaklega hlaðna skiptipunkta yfir á aðskilda klasahnúta eða með því að bæta umboðsferlum við sérstaklega hlaðin svæði klasans.
Sveigjanleiki alls kerfisins sem eiginleiki fer eftir sveigjanleika arkitektúrsins og getu til að sameina einstaka klasa í sameiginlega rökrétta heild.

Árangur verkefnis veltur oft á einfaldleika og hraða mælikvarða. Skilaboð í núverandi útgáfu stækka samhliða forritinu. Jafnvel þótt okkur vanti 50-60 vélaþyrpingar getum við gripið til sambands. Því miður er sambandsefnið utan gildissviðs þessarar greinar.

Fyrirvari

Við greiningu álagsjafnvægis ræddum við þegar offramboð þjónustustýringa. Hins vegar verður einnig að taka frá skilaboðum. Ef hnútur eða vél hrun verður, ættu skilaboðin að batna sjálfkrafa og á sem skemmstum tíma.

Í verkefnum mínum nota ég viðbótarhnúta sem taka upp álagið ef það fellur. Erlang er með staðlaða útfærslu á dreifðri stillingu fyrir OTP forrit. Dreifður háttur framkvæmir endurheimt ef bilun verður með því að ræsa misheppnaða forritið á öðrum áður ræstum hnút. Ferlið er gagnsætt; eftir bilun færist forritið sjálfkrafa yfir á bilunarhnútinn. Þú getur lesið meira um þessa virkni hér.

Framleiðni

Við skulum reyna að minnsta kosti að bera saman frammistöðu rabbitmq og sérsniðnum skilaboðum okkar.
ég fann opinber úrslit rabbitmq próf frá openstack teyminu.

Í lið 6.14.1.2.1.2.2. Upprunalega skjalið sýnir niðurstöðu RPC CAST:

Við munum ekki gera neinar viðbótarstillingar á OS kjarnanum eða erlang VM fyrirfram. Skilyrði fyrir prófun:

erl opt: +A1 +sbtu.
Prófið í einum erlang hnút er keyrt á fartölvu með gömlum i7 í farsímaútgáfu.
Klasapróf eru gerðar á netþjónum með 10G net.
Kóðinn keyrir í hafnargámum. Netkerfi í NAT ham.

Prófkóði:

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.

Sviðsmynd 1: Prófið er keyrt á fartölvu með gamalli i7 farsímaútgáfu. Prófið, skilaboðin og þjónustan eru framkvæmd á einum hnút í einum Docker ílát:

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)

Sviðsmynd 2: 3 hnútar sem keyra á mismunandi vélum undir docker (NAT).

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)

Í öllum tilfellum fór CPU nýting ekki yfir 250%

Niðurstöður

Ég vona að þessi hringrás líti ekki út eins og hugarkast og reynsla mín muni nýtast bæði rannsakendum dreifðra kerfa og sérfræðingum sem eru í byrjun að byggja upp dreifða arkitektúr fyrir viðskiptakerfi sín og skoða Erlang/Elixir af áhuga. , en efast um hvort það sé þess virði...

Photo Shoot @chuttersnap

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Hvaða efni ætti ég að fjalla nánar um sem hluta af VTrade Experiment röðinni?

Kenning: Markaðir, pantanir og tímasetning þeirra: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
Pantanabók. Kenning og framkvæmd um að útfæra bók með hópum
Sjónræn viðskipti: Merkingar, stangir, ályktanir. Hvernig á að geyma og hvernig á að líma
Backoffice. Skipulag og þróun. Eftirlit starfsmanna og atvikarannsókn
API. Við skulum reikna út hvaða tengi er þörf og hvernig á að útfæra þau
Upplýsingageymsla: PostgreSQL, Timescale, Tarantool í viðskiptakerfum
Viðbrögð í viðskiptakerfum
Annað. Ég skrifa í athugasemdir

6 notendur greiddu atkvæði. 4 notendur sátu hjá.

Heimild: www.habr.com

Byggingareiningar dreifðra forrita. Önnur nálgun