{"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\/sk\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Pohodln\u00e9 architektonick\u00e9 vzory","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ahoj, Habr!<\/p>\n

<\/p>\n

V s\u00favislosti s aktu\u00e1lnymi udalos\u0165ami sp\u00f4soben\u00fdmi koronav\u00edrusom niektor\u00e9 internetov\u00e9 slu\u017eby zaznamenali zv\u00fd\u0161en\u00e9 za\u0165a\u017eenie. Napr\u00edklad, jedna z obchodn\u00fdch siet\u00ed vo Ve\u013ekej Brit\u00e1nii jednoducho zastavila svoj web pre online objedn\u00e1vky,<\/a><\/noindex>preto\u017ee nemali dostato\u010dn\u00fa kapacitu. A nie v\u017edy je mo\u017en\u00e9 ur\u00fdchli\u0165 server, jednoducho pridan\u00edm v\u00fdkonnej\u0161ieho hardv\u00e9ru, av\u0161ak po\u017eiadavky z\u00e1kazn\u00edkov je potrebn\u00e9 spracova\u0165 (in\u00e1\u010d od\u00eddu ku konkurencii).<\/p>\n

<\/p>\n

V tomto \u010dl\u00e1nku stru\u010dne pop\u00ed\u0161em popul\u00e1rne praktiky, ktor\u00e9 umo\u017e\u0148uj\u00fa vytvori\u0165 r\u00fdchlu a odoln\u00fa slu\u017ebu. Z dostupn\u00fdch v\u00fdvojov\u00fdch sch\u00e9m som vybral iba tie, ktor\u00fdmi sa teraz \u013eahko d\u00e1 vyu\u017ei\u0165.<\/strong>Pre ka\u017ed\u00fd bod u\u017e m\u00e1te bu\u010f hotov\u00e9 kni\u017enice, alebo je tu mo\u017enos\u0165 vyrie\u0161i\u0165 \u00falohu pomocou cloudovej platformy.<\/p>\n

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

Horizont\u00e1lne \u0161k\u00e1lovanie<\/h1>\n

<\/p>\n

Najjednoduch\u0161\u00ed a v\u0161etk\u00fdm zn\u00e1my bod. Pod\u013ea rozdelenia z\u00e1\u0165a\u017ee sa zvy\u010dajne najviac stret\u00e1va s dvoma sch\u00e9mami - horizont\u00e1lnym a vertik\u00e1lnym \u0161k\u00e1lovan\u00edm. V prvom pr\u00edpade<\/a><\/noindex> umo\u017e\u0148ujete slu\u017eb\u00e1m pracova\u0165 paralelne, \u010d\u00edm rozde\u013eujete z\u00e1\u0165a\u017e medzi nimi. V druhom<\/a><\/noindex> objedn\u00e1vate v\u00fdkonnej\u0161ie servery alebo optimalizujete k\u00f3d.<\/p>\n

<\/p>\n

Pre pr\u00edklad beriem abstraktn\u00e9 cloudov\u00e9 \u00falo\u017eisko s\u00faborov, teda nie\u010do ako OwnCloud, OneDrive a tak \u010falej.<\/p>\n

<\/p>\n

\u0160tandardn\u00fd obr\u00e1zok takejto sch\u00e9my je ni\u017e\u0161ie, av\u0161ak iba demon\u0161truje zlo\u017eitosti syst\u00e9mu. Ve\u010f potrebujeme nejak\u00fdm sp\u00f4sobom synchronizova\u0165 slu\u017eby. \u010co sa stane, ak pou\u017e\u00edvate\u013e ulo\u017e\u00ed s\u00fabor na tablete a potom chce na\u0148 pozrie\u0165 z telef\u00f3nu?<\/p>\n

<\/p>\n

\"Pohodln\u00e9
\nRozdiel medzi pr\u00edstupmi: pri vertik\u00e1lnom \u0161k\u00e1lovan\u00ed sme ochotn\u00ed zvy\u0161ova\u0165 v\u00fdkon uzlov, zatia\u013e \u010do pri horizont\u00e1lnom - prid\u00e1va\u0165 nov\u00e9 uzly, aby sme rozlo\u017eili z\u00e1\u0165a\u017e.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Rozdelenie zodpovednosti pr\u00edkazov a dotazov<\/a><\/noindex> je dos\u0165 d\u00f4le\u017eit\u00fd vzor, preto\u017ee umo\u017e\u0148uje r\u00f4znym klientom nielen sa pripoji\u0165 k r\u00f4znym slu\u017eb\u00e1m, ale aj z\u00edskava\u0165 rovnak\u00e9 toky udalost\u00ed. Jeho v\u00fdhody nie s\u00fa tak\u00e9 o\u010dividn\u00e9 pre jednoduch\u00fa aplik\u00e1ciu, av\u0161ak je extr\u00e9mne d\u00f4le\u017eit\u00fd (a jednoduch\u00fd) pre za\u0165a\u017een\u00e9 slu\u017eby. Jeho podstata: prich\u00e1dzaj\u00face a odch\u00e1dzaj\u00face toky \u00fadajov by sa nemali prekr\u00fdva\u0165. To znamen\u00e1, \u017ee nem\u00f4\u017eete posla\u0165 po\u017eiadavku a \u010daka\u0165 na odpove\u010f, namiesto toho posielate po\u017eiadavku do slu\u017eby A, av\u0161ak odpove\u010f dostanete zo slu\u017eby B.<\/p>\n

<\/p>\n

Prv\u00e1 v\u00fdhoda tohto pr\u00edstupu \u2014 mo\u017enos\u0165 preru\u0161i\u0165 spojenie (v \u0161irokom zmysle tohto slova) po\u010das vykon\u00e1vania dlh\u00e9ho po\u017eiadavku. Ako pr\u00edklad si berieme viac-menej \u0161tandardn\u00fa sekvenciu:<\/p>\n

<\/p>\n

    \n
  1. Klient odoslal po\u017eiadavku na server.<\/li>\n
  2. Server spustil dlh\u00e9 spracovanie.<\/li>\n
  3. Server odpovedal klientovi v\u00fdsledkom.<\/li>\n<\/ol>\n

    <\/p>\n

    Predstavme si, \u017ee v bode 2 do\u0161lo k preru\u0161eniu spojenia (alebo sa sie\u0165 preru\u0161ila, alebo pou\u017e\u00edvate\u013e pre\u0161iel na in\u00fa str\u00e1nku, \u010d\u00edm preru\u0161il spojenie). V takom pr\u00edpade bude serveru \u0165a\u017ek\u00e9 posla\u0165 odpove\u010f pou\u017e\u00edvate\u013eovi s inform\u00e1ciou, \u010do presne bolo spracovan\u00e9. Pou\u017eit\u00edm CQRS bude sekvencia trochu in\u00e1:<\/p>\n

    <\/p>\n

      \n
    1. Klient sa prihl\u00e1sil na aktualiz\u00e1cie.<\/li>\n
    2. Klient odoslal po\u017eiadavku na server.<\/li>\n
    3. Server odpovedal \u201epo\u017eiadavka prijat\u00e1\u201c.<\/li>\n
    4. Server odpovedal v\u00fdsledkom cez kan\u00e1l z bodu \u201e1\u201c.<\/li>\n<\/ol>\n

      <\/p>\n

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

      <\/p>\n

      Ako je vidie\u0165, sch\u00e9ma je o nie\u010do zlo\u017eitej\u0161ia. Navy\u0161e intuit\u00edvny pr\u00edstup request-response tu ch\u00fdba. Ako je v\u0161ak vidie\u0165, preru\u0161enie spojenia po\u010das spracovania po\u017eiadavky nesp\u00f4sob\u00ed chybu. Navy\u0161e, ak je pou\u017e\u00edvate\u013e naozaj pripojen\u00fd k slu\u017ebe z viacer\u00fdch zariaden\u00ed (napr\u00edklad z mobiln\u00e9ho telef\u00f3nu a z tabletu), m\u00f4\u017eeme zabezpe\u010di\u0165, aby odpove\u010f pri\u0161la na obe zariadenia.<\/p>\n

      <\/p>\n

      Zauj\u00edmav\u00e9 je, \u017ee k\u00f3d spracovania prich\u00e1dzaj\u00facich spr\u00e1v sa st\u00e1va rovnak\u00fdm (nie na 100%) pre udalosti, na ktor\u00e9 mal vplyv s\u00e1m klient, ako aj pre ostatn\u00e9 udalosti, vr\u00e1tane t\u00fdch od in\u00fdch klientov.<\/p>\n

      <\/p>\n

      V skuto\u010dnosti v\u0161ak z\u00edskavame \u010fal\u0161ie v\u00fdhody, preto\u017ee jednosmern\u00fd tok je mo\u017en\u00e9 spracov\u00e1va\u0165 vo funkcion\u00e1lnom \u0161t\u00fdle (pou\u017e\u00edvaj\u00fac RX a anal\u00f3gy). A to je u\u017e zna\u010dn\u00e1 v\u00fdhoda, preto\u017ee aplik\u00e1ciu je mo\u017en\u00e9 \u00faplne urobi\u0165 reakt\u00edvnou, pri\u010dom sa pou\u017e\u00edva funkcion\u00e1lny pr\u00edstup. Pre rozsiahle programy to m\u00f4\u017ee v\u00fdrazne u\u0161etri\u0165 zdroje pri v\u00fdvoji a podpore.<\/p>\n

      <\/p>\n

      Ak spoj\u00edme tento pr\u00edstup s horizont\u00e1lnym \u0161k\u00e1lovan\u00edm, dost\u00e1vame bonus v podobe schopnosti posiela\u0165 po\u017eiadavky na jeden server a prij\u00edma\u0165 odpovede od in\u00e9ho. Tak\u00fdmto sp\u00f4sobom si klient m\u00f4\u017ee s\u00e1m vybra\u0165 pohodln\u00fa slu\u017ebu, zatia\u013e \u010do syst\u00e9m vo vn\u00fatri bude st\u00e1le schopn\u00fd spr\u00e1vne spracova\u0165 udalosti.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Ako v\u0161etci viete, jednou z hlavn\u00fdch vlastnost\u00ed distribuovan\u00e9ho syst\u00e9mu je absencia spolo\u010dn\u00e9ho \u010dasu a spolo\u010dnej kritickej sekcie. Pre jeden proces m\u00f4\u017eete urobi\u0165 synchroniz\u00e1ciu (na t\u00fdch ist\u00fdch mutexoch), po\u010das ktorej si m\u00f4\u017eete by\u0165 ist\u00ed, \u017ee nikto in\u00fd tento k\u00f3d nevykon\u00e1va. Av\u0161ak pre distribuovan\u00fd syst\u00e9m je to nebezpe\u010dn\u00e9, preto\u017ee to vy\u017eaduje n\u00e1klady a zni\u010d\u00ed to v\u0161etku kr\u00e1su \u0161k\u00e1lovania - aj tak v\u0161etky komponenty bud\u00fa \u010daka\u0165 na jednu vec.<\/p>\n

      <\/p>\n

      Odtia\u013e dost\u00e1vame d\u00f4le\u017eit\u00fd fakt - r\u00fdchlu distribuovan\u00fa syst\u00e9m nie je mo\u017en\u00e9 synchronizova\u0165, lebo v opa\u010dnom pr\u00edpade zn\u00ed\u017eime v\u00fdkon. Na druhej strane, \u010dasto potrebujeme ur\u010dit\u00fa konzistenciu komponentov. A na to m\u00f4\u017eeme pou\u017ei\u0165 pr\u00edstup s eventu\u00e1lnou konzistenciou<\/a><\/noindex>, kde sa zaru\u010duje, \u017ee pri absencii zmien \u00fadajov po ur\u010ditom \u010dasovom intervale od poslednej aktualiz\u00e1cie (\"na konci\") v\u0161etky \u017eiadosti vr\u00e1tia posledn\u00fa aktualizovan\u00fa hodnotu.<\/p>\n

      <\/p>\n

      Je d\u00f4le\u017eit\u00e9 ch\u00e1pa\u0165, \u017ee pre klasick\u00e9 datab\u00e1zy sa pomerne \u010dasto pou\u017e\u00edva pr\u00edsna konzistencia<\/a><\/noindex>, kde ka\u017ed\u00fd uzol vlastn\u00ed rovnak\u00e9 inform\u00e1cie (to sa \u010dasto dosahuje, ke\u010f sa transakcia pova\u017euje za potvrden\u00fa a\u017e po odpovedi druh\u00e9ho servera). Tu existuj\u00fa niektor\u00e9 \u00fa\u013eavy v\u010faka \u00farovniam izol\u00e1cie, av\u0161ak celkov\u00fd princ\u00edp zost\u00e1va rovnak\u00fd - m\u00f4\u017eete \u017ei\u0165 v \u00faplne konzistentnom svete.<\/p>\n

      <\/p>\n

      Av\u0161ak vr\u00e1\u0165me sa k po\u010diato\u010dnej \u00falohe. Ak m\u00f4\u017ee by\u0165 \u010das\u0165 syst\u00e9mu postaven\u00e1 s eventu\u00e1lnou konzistenciou<\/a><\/noindex>, m\u00f4\u017eeme postavi\u0165 nasleduj\u00facu sch\u00e9mu.<\/p>\n

      <\/p>\n

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

      <\/p>\n

      D\u00f4le\u017eit\u00e9 vlastnosti tohto pr\u00edstupu:<\/p>\n

      <\/p>\n