{"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\/sl\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Prakti\u010dni arhitektonski obrasci","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello, Habr!<\/p>\n

<\/p>\n

V lu\u010di trenutnih dogodkov zaradi koronavirusa so nekateri internetni servisi za\u010deli prejemati pove\u010dano obremenitev. Na primer, eno od trgovskih omre\u017eij v Zdru\u017eenem kraljestvu je preprosto ustavilo spletno mesto za naro\u010danje<\/a><\/noindex>, ker ni bilo dovolj mo\u010di. In dale\u010d ne vedno je mogo\u010de izbolj\u0161ati stre\u017enik, preprosto dodajanje zmogljivej\u0161e opreme, vendar moramo obdelati zahteve strank (ali pa odidejo k konkurentom).<\/p>\n

<\/p>\n

V tem \u010dlanku bom na kratko opisal priljubljene prakse, ki bodo omogo\u010dile hitro in zanesljivo storitev. Izmed mo\u017enih razvoja sem izbral le tiste, ki jih lahko zdaj enostavno uporabite<\/strong>. Za vsako to\u010dko imate ali \u017ee pripravljene knji\u017enice, ali pa je mogo\u010de nalogo re\u0161iti s pomo\u010djo obla\u010dne platforme.<\/p>\n

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

Horizontalno skaliranje<\/h1>\n

<\/p>\n

Najpreprostej\u0161a in vsem znana to\u010dka. Pogojujemo, da sta najbolj pogosto uporabljeni dve shemi porazdelitve obremenitve \u2014 horizontalno in vertikalno skaliranje. V prvem primeru<\/a><\/noindex> dovolite storitvam, da delujejo vzporedno, s \u010dimer porazdelite obremenitev med njimi. V drugem<\/a><\/noindex> naro\u010dite mo\u010dnej\u0161e stre\u017enike ali optimizirate kodo.<\/p>\n

<\/p>\n

Kot primer bom vzel abstraktno obla\u010dno shrambo datotek, tj. nekak\u0161en analog OwnCloud, OneDrive in tako dalje.<\/p>\n

<\/p>\n

Standardna slika tak\u0161ne sheme je spodaj, vendar le predstavlja kompleksnost sistema. Kaj pa, \u010de uporabnik shrani datoteko iz tablice in jo nato \u017eeli pogledati na telefonu?<\/p>\n

<\/p>\n

\"Prakti\u010dni
\nRazlika med pristopi: pri vertikalnem skaliranju smo pripravljeni pove\u010dati mo\u010d enot, pri horizontalnem pa dodajamo nove enote, da porazdelimo obremenitev.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Lo\u010devanje odgovornosti po ukazu in poizvedbi<\/a><\/noindex> je precej pomemben vzorec, saj omogo\u010da razli\u010dnim strankam, ne le, da se pove\u017eejo z razli\u010dnimi storitvami, ampak tudi prejemajo enake tokove dogodkov. Njegove prednosti niso tako o\u010ditne za preprosto aplikacijo, vendar je izjemno pomemben (in preprost) za obremenjeno storitev. Njegovo bistvo je: vhodni in izhodni tokovi podatkov se ne smejo kri\u017eati. To pomeni, da ne morete poslati poizvedbe in pri\u010dakovati odgovora, temve\u010d po\u0161ljete poizvedbo v storitev A, vendar odgovor prejmete v storitvi B.<\/p>\n

<\/p>\n

Prvi bonus ovog pristupa je mogu\u0107nost prekida veze (u \u0161irokom smislu te re\u010di) tokom izvr\u0161avanja dugog zahteva. Na primer, uzmimo vi\u0161e-manje standardnu sekvencu:<\/p>\n

<\/p>\n

    \n
  1. Klijent je poslao zahtev serveru.<\/li>\n
  2. Server je pokrenuo dugu obradu.<\/li>\n
  3. Server je odgovorio klijentu rezultatom.<\/li>\n<\/ol>\n

    <\/p>\n

    Zamislimo da se u koraku 2 dogodio prekid veze (ili se mre\u017ea ponovo povezala, ili je korisnik pre\u0161ao na drugu stranicu, prekinuv\u0161i vezu). U tom slu\u010daju, serveru \u0107e biti te\u0161ko da po\u0161alje odgovor korisniku s informacijama o tome \u0161ta je ta\u010dno obra\u0111eno. Primenom CQRS, sekvenca \u0107e biti malo druga\u010dija:<\/p>\n

    <\/p>\n

      \n
    1. Klijent se pretplatio na a\u017euriranja.<\/li>\n
    2. Klijent je poslao zahtev serveru.<\/li>\n
    3. Server je odgovorio \"zahtev prihva\u0107en\".<\/li>\n
    4. Server je odgovorio rezultatom preko kanala iz ta\u010dke \"1\".<\/li>\n<\/ol>\n

      <\/p>\n

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

      <\/p>\n

      Kao \u0161to se mo\u017ee videti, shema je malo slo\u017eenija. \u0160tavi\u0161e, intuitivni pristup zahteva-odgovora ovde nedostaje. Me\u0111utim, kao \u0161to se vidi, prekid veze tokom obrade zahteva ne\u0107e dovesti do gre\u0161ke. \u0160tavi\u0161e, ako je korisnik zapravo povezan sa servisom s vi\u0161e ure\u0111aja (na primer, sa mobilnog telefona i sa tableta), mo\u017ee se omogu\u0107iti da odgovor dolazi na oba ure\u0111aja.<\/p>\n

      <\/p>\n

      Zanimljivo je da kod obrade dolaznih poruka postaje sli\u010dan (ne 100%) za doga\u0111aje na koje je uticao sam klijent, kao i za ostale doga\u0111aje, uklju\u010duju\u0107i one od drugih klijenata.<\/p>\n

      <\/p>\n

      Me\u0111utim, u stvarnosti dobijamo dodatne pogodnosti zbog toga \u0161to se jednosmerni protok mo\u017ee obra\u0111ivati u funkcionalnom stilu (koriste\u0107i RX i sli\u010dne alate). I ovo je ozbiljna prednost, jer se u su\u0161tini aplikacija mo\u017ee u\u010diniti potpuno reaktivnom, uz primenu funkcionalnog pristupa. Za kompleksne programe to mo\u017ee zna\u010dajno u\u0161tedeti resurse na razvoju i odr\u017eavanju.<\/p>\n

      <\/p>\n

      Ako spojimo ovaj pristup s horizontalnim skaliranjem, dobijamo mogu\u0107nost slanja zahteva na jedan server, a primanja odgovora od drugog. Tako klijent mo\u017ee sam izabrati uslugu koja mu odgovara, a sistem unutar mo\u017ee ispravno obraditi doga\u0111aje.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Kot veste, ena od osnovnih zna\u010dilnosti porazdeljenega sistema je pomanjkanje skupnega \u010dasa in skupne kriti\u010dne sekcije. Za en proces lahko izvedete sinhronizacijo (na istih mutexih), znotraj katere ste prepri\u010dani, da nih\u010de drug ne izvaja te kode. Vendar pa je to za porazdeljen sistem nevarno, saj bo to zahtevalo prevelike stro\u0161ke, hkrati pa bi uni\u010dilo vso \u010darobnost skaliranja \u2014 vse komponente bi se kljub temu morale zana\u0161ati na eno samo.<\/p>\n

      <\/p>\n

      Od tod pridemo do pomembnega dejstva \u2014 hitrega porazdeljenega sistema ni mogo\u010de sinhronizirati, saj bi s tem zmanj\u0161ali u\u010dinkovitost. Po drugi strani pa pogosto potrebujemo dolo\u010deno usklajenost komponent. In za to lahko uporabimo pristop z eventual consistency<\/a><\/noindex>, kjer je zagotovljeno, da v odsotnosti sprememb podatkov po nekem \u010dasovnem obdobju po zadnji posodobitvi (\u201ena koncu\u201c) vsi zahtevki vrnejo zadnjo posodobljeno vrednost.<\/p>\n

      <\/p>\n

      Pomembno je razumeti, da se za klasi\u010dne baze podatkov pogosto uporablja stroga usklajenost<\/a><\/noindex>, kjer vsak vozli\u0161\u010de obvladuje enake informacije (to se pogosto dose\u017ee, ko se transakcija \u0161teje za dokon\u010dano \u0161ele po odgovoru drugega stre\u017enika). Tukaj so nekatera popustitev zaradi stopenj izolacije, vendar osnovna ideja ostaja enaka \u2014 lahko \u017eivite v popolnoma usklajenem svetu.<\/p>\n

      <\/p>\n

      Vendar se vrnimo k prvotni nalogi. \u010ce je del sistema mogo\u010de zgraditi s eventual consistency<\/a><\/noindex>, potem lahko zgradimo naslednjo shemo.<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Pomembne zna\u010dilnosti tega pristopa:<\/p>\n

      <\/p>\n