{"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\/hr\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Gra\u0111evni blokovi distribuiranih aplikacija. Drugo pribli\u017eavanje","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Najava<\/strong><\/p>\n

<\/p>\n

Kolege, sredinom ljeta planiram objaviti jo\u0161 jedan niz \u010dlanaka o dizajniranju sustava masovne usluge: \u201cEksperiment VTrade\u201d \u2014 poku\u0161aj pisanja okvira za trgova\u010dke sustave. U nizu \u0107e se razmatrati teorija i praksa izgradnje burze, aukcije i trgovine. Na kraju \u010dlanka predla\u017eem da glasate za teme koje vas najvi\u0161e zanimaju.
\n<\/em><\/p>\n

<\/p>\n

\"Gra\u0111evni<\/p>\n

<\/p>\n

Ovo je zavr\u0161ni \u010dlanak niza o distribuiranim reaktivnim aplikacijama na Erlangu\/Elixiru. U prvom \u010dlanku<\/a><\/noindex> mo\u017ee se prona\u0107i teorijska osnova reaktivne arhitekture. Drugi \u010dlanak<\/a><\/noindex> ilustrira osnovne uzorke i mehanizme izgradnje sli\u010dnih sustava.<\/p>\n

<\/p>\n

Danas \u0107emo razmotriti pitanja razvoja kodne baze i projekata u cjelini. <\/p>\n

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

Organizacija servisa<\/h2>\n

<\/p>\n

U stvarnom \u017eivotu, prilikom razvoja servisa \u010desto je potrebno spojiti nekoliko uzoraka interakcije u jednom kontroleru. Na primjer, servis users, koji rje\u0161ava zadatke upravljanja profilima korisnika projekta, trebao bi odgovarati na zahtjeve req-resp i obavje\u0161tavati o a\u017euriranjima profila putem pub-sub. Ovaj slu\u010daj je prili\u010dno jednostavan: iza messaginga stoji jedan kontroler koji implementira logiku servisa i objavljuje a\u017euriranja.<\/p>\n

<\/p>\n

Situacija se komplikuje kada trebamo realizirati otporan distribuirani servis. Zamislite da su se zahtjevi za users promijenili: <\/p>\n

<\/p>\n

    \n
  1. sada servis treba obraditi zahtjeve na 5 \u010dvorova klastera, <\/li>\n
  2. imati mogu\u0107nost izvr\u0161avanja pozadinskih zadataka obrade, <\/li>\n
  3. kao i imati mogu\u0107nost dinami\u010dkog upravljanja popisima pretplate na a\u017euriranja profila.<\/li>\n<\/ol>\n

    <\/p>\n

    Napomena:<\/em> Pitanje konzistentnog pohranjivanja i replike podataka ne razmatramo. Pretpostavljamo da su ta pitanja ranije rije\u0161ena i da sustav ve\u0107 ima pouzdan i skalabilan sloj pohrane, a procesori imaju mehanizme interakcije s njim.<\/p>\n

    <\/p>\n

    Formalni opis servisa users postao je slo\u017eeniji. S programerskog stajali\u0161ta, zahvaljuju\u0107i kori\u0161tenju messaginga, promjene su minimalne. Da bismo zadovoljili prvi zahtjev, trebamo postaviti balansiranje na to\u010dki izmjene req-resp. <\/p>\n

    <\/p>\n

    Zahtev za obradu pozadinskih zadataka \u010desto se javlja. U korisnicima, to mogu biti provere dokumenata korisnika, obrada u\u010ditanih multimedijalnih sadr\u017eaja ili sinhronizacija podataka sa dru\u0161tvenim mre\u017eama. Ove zadatke treba nekako raspodeliti unutar klastera i kontrolisati tok izvr\u0161enja. Stoga imamo dve opcije re\u0161enja: ili koristiti \u0161ablon raspodele zadataka iz prethodnog \u010dlanka, ili, ako to ne odgovara, napisati prilago\u0111eni planer zadataka koji \u0107e upravljati grupom obrtnika na na\u010din koji nam je potreban. <\/p>\n

    <\/p>\n

    3. ta\u010dka zahteva pro\u0161irenje pub-sub \u0161ablona. Nakon kreiranja ta\u010dke razmene pub-sub, moramo dodatno pokrenuti kontroler te ta\u010dke u okviru na\u0161eg servisa. Na taj na\u010din kao da iznosimo logiku obrade pretplate i otplate iz sloja poruka u implementaciju korisnika.<\/p>\n

    <\/p>\n

    Na kraju, dekompozicija zadatka pokazala je da, da bismo ispunili zahteve, treba da pokrenemo 5 instanci servisa na razli\u010ditim \u010dvorovima i stvorimo dodatnu entitet - kontroler pub-sub, odgovoran za pretplatu.
    \nZa pokretanje 5 obrtnika nije potrebno menjati kod servisa. Jedina dodatna akcija je konfiguracija pravila balansiranja na ta\u010dki razmene, o \u010demu \u0107emo govoriti malo kasnije.
    \nPojavila se dodatna slo\u017eenost: kontroler pub-sub i prilago\u0111eni planer zadataka treba da rade u jednom jedinom primeru. Ponovo, servis za razmenu poruka, kao fundamentalni, treba da obezbedi mehanizam izbora lidera.<\/p>\n

    <\/p>\n

    Izbor lidera<\/h3>\n

    <\/p>\n

    U distribuiranim sistemima, izbor lidera je procedura imenovanja jedinog procesa koji je odgovoran za planiranje distribuirane obrade nekog optere\u0107enja. <\/p>\n

    <\/p>\n

    U sistemima koji nisu skloni centralizaciji, koriste se univerzalni algoritmi i algoritmi zasnovani na konsenzusu, kao \u0161to su paxos ili raft.
    \nBudu\u0107i da je razmena poruka \u2013 broker i centralna ta\u010dka, ona zna o svim kontrolerima servisa \u2013 kandidatima za lidere. Razmena poruka mo\u017ee imenovati lidera bez glasanja.<\/p>\n

    <\/p>\n

    Svi servisi nakon pokretanja i povezivanja sa ta\u010dkom razmene dobijaju sistemsku poruku #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. U slu\u010daju da LeaderPid<\/code> se podudara sa pid<\/code> trenutnog procesa, on se imenuje liderom, a lista Servers<\/code> sadr\u017ei sve \u010dvorove i njihove parametre.
    \nKada se novi \u010dvor klastera pojavi i radni \u010dvor isklju\u010di, svi kontroleri servisa primaju #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> i #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> odgovaraju\u0107e.<\/p>\n

    <\/p>\n

    Tako svi komponenti znaju o svim promjenama, a u klasteru je u svakoj trenutku zajam\u010den jedan lider.<\/p>\n

    <\/p>\n

    Posrednici<\/h2>\n

    <\/p>\n

    Za realizaciju slo\u017eenih distribuiranih procesa obrade, kao i u zadacima optimizacije postoje\u0107e arhitekture, prikladno je koristiti posrednike.
    \nKako bismo izbjegli promjenu koda servisa i rije\u0161ili, na primjer, zadatke dodatne obrade, usmjeravanja ili logiranja poruka, ispred servisa mo\u017eemo uklju\u010diti proxy obrtnika koji \u0107e izvr\u0161iti sav dodatni posao.<\/p>\n

    <\/p>\n

    Klasi\u010dni primjer optimizacije pub-sub je distribuirana aplikacija s poslovnim jezgrima koja generiraju doga\u0111aje a\u017euriranja, kao \u0161to je promjena cijene na tr\u017ei\u0161tu, i sloj pristupa - N servera koji pru\u017eaju websocket API za web klijente.
    \nAko se stvari rje\u0161avaju direktno, usluga klijenta izgleda ovako:<\/p>\n

    <\/p>\n