{"id":31124,"date":"2019-10-31T21:39:36","date_gmt":"2019-10-31T18:39:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie\/"},"modified":"2019-10-31T21:39:36","modified_gmt":"2019-10-31T18:39:36","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Stavebn\u00e9 bloky distribuovan\u00fdch aplik\u00e1ci\u00ed. Druh\u00e9 pribl\u00ed\u017eenie","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ozn\u00e1menie<\/strong><\/p>\n

<\/p>\n

Kollega, v polovici leta pl\u00e1nujem zverejni\u0165 \u010fal\u0161\u00ed cyklus \u010dl\u00e1nkov o navrhovan\u00ed syst\u00e9mov hromadn\u00e9ho obsluhy: \u201eExperiment VTrade\u201c \u2014 pokus nap\u00edsa\u0165 framework pre obchodn\u00e9 syst\u00e9my. V cykle budeme rozobera\u0165 te\u00f3riu a prax budovania burzy, aukcie a obchodu. Na konci \u010dl\u00e1nku navrhujem hlasova\u0165 za t\u00e9my, ktor\u00e9 v\u00e1s najviac zauj\u00edmaj\u00fa.
\n<\/em><\/p>\n

<\/p>\n

\"Stavebn\u00e9<\/p>\n

<\/p>\n

Toto je z\u00e1vere\u010dn\u00fd \u010dl\u00e1nok cyklu o distribuovan\u00fdch reakt\u00edvnych aplik\u00e1ci\u00e1ch na Erlang\/Elixir. V v prvej \u010dl\u00e1nku<\/a><\/noindex> n\u00e1jdete teoretick\u00e9 z\u00e1klady reakt\u00edvnej architekt\u00fary. Druh\u00fd \u010dl\u00e1nok<\/a><\/noindex> ilustruje z\u00e1kladn\u00e9 vzory a mechanizmy budovania tak\u00fdchto syst\u00e9mov.<\/p>\n

<\/p>\n

Dnes sa budeme zaobera\u0165 ot\u00e1zkami rozvoja k\u00f3dovej z\u00e1kladne a projektov ako celku. <\/p>\n

<\/a><\/noindex><\/p>\n

Organiz\u00e1cia slu\u017eieb<\/h2>\n

<\/p>\n

V re\u00e1lnom \u017eivote pri v\u00fdvoji slu\u017eby \u010dasto mus\u00edme kombinova\u0165 nieko\u013eko vzorov interakcie v jednom kontrol\u00e9ri. Napr\u00edklad, slu\u017eba users, ktor\u00e1 rie\u0161i \u00falohy spr\u00e1vy profilov pou\u017e\u00edvate\u013eov projektu, mus\u00ed reagova\u0165 na po\u017eiadavky req-resp a informova\u0165 o aktualiz\u00e1ci\u00e1ch profilov cez pub-sub. Tento pr\u00edpad je pomerne jednoduch\u00fd: za messaging stoj\u00ed jeden kontrol\u00e9r, ktor\u00fd implementuje logiku slu\u017eby a publikovuje aktualiz\u00e1cie.<\/p>\n

<\/p>\n

Situ\u00e1cia sa komplikuje, ke\u010f potrebujeme implementova\u0165 odoln\u00fa distribuovan\u00fa slu\u017ebu. Predpokladajme, \u017ee po\u017eiadavky na users sa zmenili: <\/p>\n

<\/p>\n

    \n
  1. teraz mus\u00ed slu\u017eba spracov\u00e1va\u0165 po\u017eiadavky na 5 uzloch v klastri, <\/li>\n
  2. ma\u0165 schopnos\u0165 vykon\u00e1va\u0165 pozadie spracovanie \u00faloh, <\/li>\n
  3. ako aj schopnos\u0165 dynamicky spravova\u0165 zoznamy prihl\u00e1senia na aktualiz\u00e1cie profilov.<\/li>\n<\/ol>\n

    <\/p>\n

    Pozn\u00e1mka:<\/em> Ot\u00e1zka konzistentn\u00e9ho ukl\u00e1dania a replik\u00e1cie \u00fadajov sa neberie do \u00favahy. Predpokladajme, \u017ee tieto ot\u00e1zky boli vyrie\u0161en\u00e9 sk\u00f4r a v syst\u00e9me u\u017e existuje spo\u013eahliv\u00e1 a \u0161k\u00e1lovate\u013en\u00e1 vrstva ukladania, pri\u010dom spracovatelia maj\u00fa mechanizmy interakcie s \u0148ou.<\/p>\n

    <\/p>\n

    Form\u00e1lne op\u00edsanie slu\u017eby users sa skomplikovalo. Z poh\u013eadu program\u00e1tora s\u00fa v\u010faka pou\u017e\u00edvaniu messaging zmeny minim\u00e1lne. Aby sme vyhoveli prv\u00e9mu po\u017eiadavku, mus\u00edme nastavi\u0165 vyva\u017eovanie na mieste v\u00fdmeny req-resp. <\/p>\n

    <\/p>\n

    Po\u017eiadavka na spracovanie pozad\u00ed \u00faloh sa \u010dasto vyskytuje. V u\u017e\u00edvate\u013esk\u00fdch \u00fa\u010dtoch to m\u00f4\u017eu by\u0165 kontroly dokumentov pou\u017e\u00edvate\u013eov, spracovanie nahran\u00e9ho multim\u00e9di\u00e1 alebo synchroniz\u00e1cia \u00fadajov so soci\u00e1lnymi sie\u0165ami. Tieto \u00falohy je potrebn\u00e9 nejak\u00fdm sp\u00f4sobom rozde\u013eova\u0165 v r\u00e1mci clustra a kontrolova\u0165 priebeh vykon\u00e1vania. Preto m\u00e1me dve mo\u017enosti rie\u0161enia: bu\u010f pou\u017ei\u0165 vzor rozde\u013eovania \u00faloh z predch\u00e1dzaj\u00faceho \u010dl\u00e1nku, alebo, ak ten nie je vhodn\u00fd, nap\u00edsa\u0165 vlastn\u00fd pl\u00e1nova\u010d \u00faloh, ktor\u00fd bude spravova\u0165 skupinu spracovate\u013eov tak, ako to potrebujeme. <\/p>\n

    <\/p>\n

    3. bod vy\u017eaduje roz\u0161\u00edrenie vzoru pub-sub. A na jeho implement\u00e1ciu, po vytvoren\u00ed bodu v\u00fdmeny pub-sub, mus\u00edme navy\u0161e spusti\u0165 riadiaci prvok tohto bodu v r\u00e1mci na\u0161ich slu\u017eieb. T\u00fdmto sp\u00f4sobom akoby vy\u0165ahujeme logiku spracovania prihl\u00e1senia a odhl\u00e1senia z vrstvy messaging do implement\u00e1cie pou\u017e\u00edvate\u013eov.<\/p>\n

    <\/p>\n

    Nakoniec, dekompoz\u00edcia \u00falohy uk\u00e1zala, \u017ee na splnenie po\u017eiadaviek potrebujeme spusti\u0165 na r\u00f4znych uzloch 5 in\u0161tanci\u00ed slu\u017eby a vytvori\u0165 dodato\u010dn\u00fa entitu \u2013 riadi\u010d pub-sub, ktor\u00fd bude zodpovedn\u00fd za prihl\u00e1senie.
    \nNa spustenie 5 spracovate\u013eov nie je potrebn\u00e9 meni\u0165 k\u00f3d slu\u017eby. Jedinou dodato\u010dnou \u010dinnos\u0165ou je nastavenie pravidiel vyva\u017eovania na bode v\u00fdmeny, o \u010dom budeme hovori\u0165 nesk\u00f4r.
    \nTaktie\u017e sa objavila dodato\u010dn\u00e1 zlo\u017eitost: riadi\u010d pub-sub a vlastn\u00fd pl\u00e1nova\u010d \u00faloh musia pracova\u0165 v jedinom in\u0161tanci. Op\u00e4\u0165, slu\u017eba messaging, ako fundament\u00e1lna, mus\u00ed poskytova\u0165 mechanizmus vo\u013eby l\u00eddra.<\/p>\n

    <\/p>\n

    Vo\u013eba l\u00eddra<\/h3>\n

    <\/p>\n

    V distribuovan\u00fdch syst\u00e9moch vo\u013eba l\u00eddra \u2013 proced\u00fara menovania jedin\u00e9ho procesu, ktor\u00fd zodpoved\u00e1 za pl\u00e1novanie distribuovan\u00e9ho spracovania nejak\u00e9ho za\u0165a\u017eenia. <\/p>\n

    <\/p>\n

    V syst\u00e9moch, ktor\u00e9 nie s\u00fa naklonen\u00e9 centraliz\u00e1cii, sa pou\u017e\u00edvaj\u00fa univerz\u00e1lne algoritmy a algoritmy zalo\u017een\u00e9 na konsenze, ako napr\u00edklad paxos alebo raft.
    \nKe\u010f\u017ee messaging je broker a centr\u00e1lna s\u00fa\u010das\u0165, pozn\u00e1 v\u0161etk\u00fdch riadi\u010dov slu\u017eby \u2013 kandid\u00e1tov na l\u00eddra. Messaging m\u00f4\u017ee vymenova\u0165 l\u00eddra bez vykon\u00e1vania hlasovania.<\/p>\n

    <\/p>\n

    V\u0161etky slu\u017eby po spusten\u00ed a pripojen\u00ed k bodu v\u00fdmeny dostan\u00fa syst\u00e9mov\u00fa spr\u00e1vu #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. V pr\u00edpade, ak LeaderPid<\/code> s\u00fahlas\u00ed s pid<\/code> aktu\u00e1lneho procesu, je menovan\u00fd za l\u00eddra, a zoznam Servers<\/code> zah\u0155\u0148a v\u0161etky uzly a ich parametre.
    \nPri vzniku nov\u00e9ho a vypnut\u00ed funguj\u00faceho uzla klastera v\u0161etci spr\u00e1vcovia slu\u017eby dost\u00e1vaj\u00fa #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> a #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> pr\u00edpadne.<\/p>\n

    <\/p>\n

    T\u00fdmto sp\u00f4sobom v\u0161etky komponenty vedia o v\u0161etk\u00fdch zmen\u00e1ch a v klasteri je v ka\u017edom okamihu zaru\u010den\u00fd jeden l\u00edder.<\/p>\n

    <\/p>\n

    Proxy<\/h2>\n

    <\/p>\n

    Na realiz\u00e1ciu zlo\u017eit\u00fdch distribuovan\u00fdch procesov spracovania a takisto pri optimaliz\u00e1cii existuj\u00facej architekt\u00fary je v\u00fdhodn\u00e9 pou\u017e\u00edva\u0165 proxy.
    \nAby sme nemuseli meni\u0165 k\u00f3d slu\u017eieb a rie\u0161ili napr\u00edklad \u00falohy dodato\u010dn\u00e9ho spracovania, smerovania alebo logovania spr\u00e1v, m\u00f4\u017eeme pred slu\u017ebu zahrn\u00fa\u0165 proxy spracovate\u013ea, ktor\u00fd vykon\u00e1 v\u0161etku dodato\u010dn\u00fa pr\u00e1cu.<\/p>\n

    <\/p>\n

    Klasick\u00fdm pr\u00edkladom optimaliz\u00e1cie pub-sub je distribuovan\u00e1 aplik\u00e1cia s obchodn\u00fdm jadrom, ktor\u00e9 generuje udalnosti aktualiz\u00e1ci\u00ed, ako napr\u00edklad zmeny cien na trhu, a pr\u00edstupov\u00e1 vrstva \u2014 N serverov poskytuj\u00facich websocket API pre webov\u00fdch klientov.
    \nAk sa na probl\u00e9m pozrieme priamo, spr\u00e1va klienta vyzer\u00e1 nasledovne:<\/p>\n

    <\/p>\n