{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Prakti\u010dni arhitektonski obrasci","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bok, Habr!<\/p>\n

<\/p>\n

S obzirom na trenutne doga\u0111aje uzrokovane koronavirusom, nekoliko internetskih usluga po\u010delo je primati ve\u0107e optere\u0107enje. Na primjer, jedna trgova\u010dka mre\u017ea u Ujedinjenom Kraljevstvu jednostavno je obustavila web stranicu s online narud\u017ebama<\/a><\/noindex>, jer nije bilo dovoljnih resursa. A nije uvijek mogu\u0107e ubrzati server jednostavno dodavanjem mo\u0107nijih ure\u0111aja, me\u0111utim, zahtjeve klijenata treba obraditi (ili \u0107e oti\u0107i konkurentima).<\/p>\n

<\/p>\n

U ovom \u010dlanku \u0107u ukratko opisati popularne prakse koje omogu\u0107uju brzu i otpornu uslugu. Me\u0111utim, od svih mogu\u0107ih shema razvoja odabrao sam samo one koje su trenutno lako dostupne.<\/strong>Za svaku to\u010dku ve\u0107 imate pripremljene biblioteke ili mogu\u0107nost rje\u0161avanja zadatka putem obla\u010dne platforme.<\/p>\n

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

Horizontalno skaliranje<\/h1>\n

<\/p>\n

Najjednostavnija i svima poznata to\u010dka. U principu, naj\u010de\u0161\u0107e se susre\u0107u dva schematska pristupa raspodjeli optere\u0107enja \u2014 horizontalno i vertikalno skaliranje. U prvom slu\u010daju<\/a><\/noindex> dopu\u0161tate uslugama da rade paralelno, \u010dime se raspore\u0111uje optere\u0107enje me\u0111u njima. U drugom<\/a><\/noindex> naru\u010dujete mo\u0107nije servere ili optimizirate kod.<\/p>\n

<\/p>\n

Za primjer \u0107u uzeti apstraktno obla\u010dno pohranjivanje datoteka, odnosno neki analog OwnCloud, OneDrive i sli\u010dno.<\/p>\n

<\/p>\n

Standardna slika takve sheme je ispod, me\u0111utim ona samo prikazuje slo\u017eenost sustava. Naime, potrebno je na neki na\u010din sinkronizirati usluge. \u0160to \u0107e se dogoditi ako korisnik na tabletu spremi datoteku, a zatim je \u017eeli pregledati s telefona?<\/p>\n

<\/p>\n

\"Prakti\u010dni
\nRazlika izme\u0111u pristupa: u vertikalnom skaliranju spremni smo pove\u0107ati snagu \u010dvorova, dok u horizontalnom dodajemo nove \u010dvorove kako bismo rasporedili optere\u0107enje.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Razdvajanje odgovornosti za naredbe i upite<\/a><\/noindex> je prili\u010dno va\u017ean obrazac, jer omogu\u0107uje razli\u010ditim klijentima da se pove\u017eu s razli\u010ditim uslugama, ali i da primaju iste tokove doga\u0111aja. Njegove prednosti nisu toliko o\u010dite za jednostavne aplikacije, me\u0111utim, iznimno su va\u017ene (i jednostavne) za optere\u0107ene usluge. Njegova su\u0161tina: ulazni i izlazni tokovi podataka ne smiju se prekri\u017eiti. To jest, ne mo\u017eete poslati zahtjev i o\u010dekivati odgovor, umjesto toga \u0161aljete zahtjev u uslugu A, ali dobivate odgovor u usluzi B.<\/p>\n

<\/p>\n

Prva prednost ovog pristupa je mogu\u0107nost prekida veze (u \u0161irokom smislu te rije\u010di) tijekom izvr\u0161avanja dugog zahtjeva. Kao primjer, uzmimo prili\u010dno standardnu sekvencu:<\/p>\n

<\/p>\n

    \n
  1. Klijent je poslao zahtjev serveru.<\/li>\n
  2. Server je pokrenuo dug proces obrade.<\/li>\n
  3. Server je odgovorio klijentu rezultatom.<\/li>\n<\/ol>\n

    <\/p>\n

    Zamislimo da je u koraku 2 do\u0161lo do prekida veze (ili se mre\u017ea ponovno povezala, ili je korisnik pre\u0161ao na drugu stranicu, prekinuv\u0161i vezu). U tom \u0107e slu\u010daju serveru biti te\u0161ko poslati odgovor korisniku s informacijama o tome \u0161to je konkretno obra\u0111eno. Primjenom CQRS-a, sekvenca \u0107e biti malo druga\u010dija:<\/p>\n

    <\/p>\n

      \n
    1. Klijent se pretplatio na a\u017euriranja.<\/li>\n
    2. Klijent je poslao zahtjev serveru.<\/li>\n
    3. Server je odgovorio \"zahtjev primljen\".<\/li>\n
    4. Server je odgovorio rezultatom putem kanala iz to\u010dke \"1\".<\/li>\n<\/ol>\n

      <\/p>\n

      \"Prakti\u010dni<\/p>\n

      <\/p>\n

      Kao \u0161to se mo\u017ee vidjeti, shema je malo slo\u017eenija. \u0160tovi\u0161e, intuitivni pristup zahtjev-odgovor ovdje nedostaje. Me\u0111utim, kao \u0161to se mo\u017ee vidjeti, prekid veze tijekom obrade zahtjeva ne\u0107e uzrokovati gre\u0161ku. \u0160tovi\u0161e, ako je korisnik zapravo povezan na servis s nekoliko ure\u0111aja (na primjer, s mobilnog telefona i s tableta), mo\u017ee se omogu\u0107iti da odgovor stigne na oba ure\u0111aja.<\/p>\n

      <\/p>\n

      Ono \u0161to je zanimljivo, kod obrade dolaznih poruka postaje gotovo identi\u010dan (ne 100%) za doga\u0111aje na koje utje\u010de sam klijent, kao i za ostale doga\u0111aje, uklju\u010duju\u0107i one od drugih klijenata.<\/p>\n

      <\/p>\n

      Me\u0111utim, u stvarnosti dobivamo dodatne prednosti s obzirom na to da se jednosmjerni tok mo\u017ee obraditi u funkcionalnom stilu (koriste\u0107i RX i sli\u010dne). I to je ve\u0107 ozbiljna prednost, jer se u osnovi aplikacija mo\u017ee u\u010diniti potpuno reaktivnom, jo\u0161 s primjenom funkcionalnog pristupa. Za slo\u017eene programe to mo\u017ee zna\u010dajno u\u0161tedjeti resurse za razvoj i podr\u0161ku.<\/p>\n

      <\/p>\n

      Ako spojimo ovaj pristup s horizontalnim skaliranjem, kao bonus dobivamo mogu\u0107nost slanja zahtjeva na jedan server, a primanja odgovora s drugog. Tako klijent mo\u017ee odabrati najprikladniju uslugu, a sustav unutar nje i dalje mo\u017ee ispravno obraditi doga\u0111aje.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Kao \u0161to znate, jedna od osnovnih karakteristika distribuiranog sistema je odsutnost zajedni\u010dkog vremena i zajedni\u010dke kriti\u010dne sekcije. Za jedan proces mo\u017eete izvr\u0161iti sinhronizaciju (na istim mutexima), unutar koje ste sigurni da niko drugi ne izvr\u0161ava taj kod. Me\u0111utim, za distribuirani sistem ne\u0161to sli\u010dno je opasno, jer \u0107e to zahtevati dodatne tro\u0161kove, a tako\u0111e \u0107e pokvariti svu \u010dar obrade - svi \u0107e komponenti u svakom slu\u010daju \u010dekati jednog.<\/p>\n

      <\/p>\n

      Odatle dolazimo do va\u017enog zaklju\u010dka - brzi distribuirani sistem ne mo\u017ee biti sinhronizovan, jer bismo tada smanjili performanse. S druge strane, \u010desto imamo potrebu za odre\u0111enom dosledno\u0161\u0107u komponenti. I za to mo\u017eemo koristiti pristup s eventual consistency<\/a><\/noindex>, gde je garantirano da u odsustvu izmene podataka kroz odre\u0111eni period nakon poslednjeg a\u017euriranja (\"na kraju\") svi zahtevi \u0107e vra\u0107ati poslednju a\u017euriranu vrednost.<\/p>\n

      <\/p>\n

      Va\u017eno je razumeti da se za klasi\u010dne baze podataka prili\u010dno \u010desto primenjuje stroga doslednost<\/a><\/noindex>, gde svaki \u010dvor poseduje iste informacije (to se \u010desto posti\u017ee u slu\u010daju kada se transakcija smatra postavljenom tek nakon odgovora drugog servera). Postoje neka olak\u0161anja zbog nivoa izolacije, ali su\u0161tina ostaje ista - mo\u017eete \u017eiveti u potpuno doslednom svetu.<\/p>\n

      <\/p>\n

      Me\u0111utim, vratimo se na prvobitni zadatak. Ako deo sistema mo\u017ee biti izgra\u0111en sa eventual consistency<\/a><\/noindex>, onda se mo\u017ee izraditi slede\u0107a shema.<\/p>\n

      <\/p>\n

      \"Prakti\u010dni<\/p>\n

      <\/p>\n

      Va\u017ene karakteristike ovog pristupa:<\/p>\n

      <\/p>\n