{"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\/ro\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Modele arhitecturale convenabile","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Salut, Habr!<\/p>\n

<\/p>\n

\u00cen lumina evenimentelor curente cauzate de coronavirus, o serie de servicii internet au \u00eenceput s\u0103 primeasc\u0103 o \u00eenc\u0103rc\u0103tur\u0103 crescut\u0103. De exemplu, una dintre re\u021belele de retail din Regatul Unit a oprit pur \u0219i simplu site-ul cu comenzi online<\/a><\/noindex>, deoarece nu erau suficiente resurse. \u0218i de cele mai multe ori nu po\u021bi accelera un server doar prin ad\u0103ugarea de hardware mai puternic, \u00eens\u0103 trebuie s\u0103 gestionezi cererile clien\u021bilor (sau ace\u0219tia vor merge la concuren\u021b\u0103).<\/p>\n

<\/p>\n

\u00cen acest articol, voi prezenta pe scurt practici populare care vor permite crearea unui serviciu rapid \u0219i rezistent la erori. Totu\u0219i, din schemele posibile de dezvoltare, am selectat doar acele metode u\u0219or de utilizat<\/strong>. Pentru fiecare punct, ave\u021bi fie biblioteci gata preg\u0103tite, fie solu\u021bii disponibile prin platforme cloud.<\/p>\n

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

Scalare orizontal\u0103<\/h1>\n

<\/p>\n

Cel mai simplu \u0219i cunoscut punct. Schematic, cele dou\u0103 metode cele mai frecvente de distribuire a sarcinii sunt scalarea orizontal\u0103 \u0219i vertical\u0103. \u00cen primul caz,<\/a><\/noindex> permi\u021bi serviciilor s\u0103 func\u021bioneze \u00een paralel, distribuind astfel sarcina \u00eentre ele. \u00cen al doilea caz,<\/a><\/noindex> comanzi servere mai puternice sau \u00ee\u021bi optimizezi codul.<\/p>\n

<\/p>\n

Pentru exemplu, voi lua un spa\u021biu de stocare \u00een cloud abstract, adic\u0103 un analog al OwnCloud, OneDrive etc.<\/p>\n

<\/p>\n

Imaginea standard a unei astfel de scheme este prezentat\u0103 mai jos, dar aceasta demonstreaz\u0103 doar complexitatea sistemului. Trebuie s\u0103 g\u0103sim o modalitate de a sincroniza serviciile. Ce se \u00eent\u00e2mpl\u0103 dac\u0103 un utilizator salveaz\u0103 un fi\u0219ier de pe tablet\u0103 \u0219i apoi vrea s\u0103-l vizualizeze pe telefon?<\/p>\n

<\/p>\n

\"Modele
\nDiferen\u021ba dintre abord\u0103ri: \u00een scalarea vertical\u0103 suntem preg\u0103ti\u021bi s\u0103 cre\u0219tem puterea nodurilor, iar \u00een scalarea orizontal\u0103 \u2013 s\u0103 ad\u0103ug\u0103m noduri noi pentru a distribui sarcina.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> este un tipar destul de important, deoarece permite diferitelor clien\u021bi s\u0103 se conecteze nu doar la servicii diferite, ci \u0219i s\u0103 primeasc\u0103 fluxuri de evenimente identice. Beneficiile sale nu sunt at\u00e2t de evidente pentru o aplica\u021bie simpl\u0103, totu\u0219i, este extrem de important (\u0219i simplu) pentru un serviciu saturat. Conceptul s\u0103u: fluxurile de date de intrare \u0219i ie\u0219ire nu trebuie s\u0103 se intersece. Aceasta \u00eenseamn\u0103 c\u0103 nu po\u021bi trimite o cerere \u0219i a\u0219tepta un r\u0103spuns, \u00een schimb trimite\u021bi o cerere la serviciul A, dar prime\u0219ti un r\u0103spuns la serviciul B.<\/p>\n

<\/p>\n

Primul avantaj al acestei abord\u0103ri este capacitatea de a \u00eentrerupe conexiunea (\u00een sens larg) \u00een timpul execut\u0103rii unei cereri de lung\u0103 durat\u0103. Ca exemplu, s\u0103 lu\u0103m o secven\u021b\u0103 mai mult sau mai pu\u021bin standard:<\/p>\n

<\/p>\n

    \n
  1. Clientul a trimis o cerere serverului.<\/li>\n
  2. Serverul a \u00eenceput prelucrarea \u00eendelungat\u0103.<\/li>\n
  3. Serverul a r\u0103spuns clientului cu rezultatul.<\/li>\n<\/ol>\n

    <\/p>\n

    S\u0103 presupunem c\u0103 la punctul 2 a avut loc o \u00eentrerupere a conexiunii (sau re\u021beaua s-a reconectat, sau utilizatorul a navigat pe o alt\u0103 pagin\u0103, \u00eentrerup\u00e2nd conexiunea). \u00cen acest caz, serverului \u00eei va fi greu s\u0103 trimit\u0103 r\u0103spunsul utilizatorului cu informa\u021bii despre ce a fost procesat. Aplic\u00e2nd CQRS, secven\u021ba va fi pu\u021bin diferit\u0103:<\/p>\n

    <\/p>\n

      \n
    1. Clientul s-a abonat la actualiz\u0103ri.<\/li>\n
    2. Clientul a trimis o cerere serverului.<\/li>\n
    3. Serverul a r\u0103spuns \u201ecerere acceptat\u0103\u201d.<\/li>\n
    4. Serverul a trimis rezultatul prin canalul din punctul \u201e1\u201d.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Modele<\/p>\n

      <\/p>\n

      Dup\u0103 cum se poate observa, schema este pu\u021bin mai complex\u0103. Mai mult, abordarea intuitiv\u0103 request-response lipse\u0219te aici. Cu toate acestea, dup\u0103 cum se poate observa, o \u00eentrerupere a conexiunii \u00een timpul proces\u0103rii cererii nu va duce la o eroare. Mai mult, dac\u0103 utilizatorul este \u00eentr-adev\u0103r conectat la serviciu de pe mai multe dispozitive (de exemplu, de pe telefonul mobil \u0219i de pe tablet\u0103), r\u0103spunsul poate fi trimis pe ambele dispozitive.<\/p>\n

      <\/p>\n

      Ce este interesant, este c\u0103 codul de prelucrare a mesajelor de intrare devine similar (nu 100%) at\u00e2t pentru evenimentele afectate de client, c\u00e2t \u0219i pentru celelalte evenimente, inclusiv cele de la al\u021bi clien\u021bi.<\/p>\n

      <\/p>\n

      Cu toate acestea, \u00een realitate ob\u021binem bonusuri suplimentare datorit\u0103 faptului c\u0103 fluxul unidirec\u021bional poate fi procesat \u00een stil func\u021bional (folosind RX \u0219i analogii). Aceasta este o mare realizare, deoarece, \u00een esen\u021b\u0103, aplica\u021bia poate deveni complet reactiv\u0103, cu aplicarea abord\u0103rii func\u021bionale. Pentru aplica\u021biile complexe, aceasta poate economisi semnificativ resurse \u00een dezvoltare \u0219i \u00eentre\u021binere.<\/p>\n

      <\/p>\n

      Dac\u0103 combin\u0103m aceast\u0103 abordare cu scalarea orizontal\u0103, atunci ca bonus ob\u021binem capacitatea de a trimite cereri la un server, dar a primi r\u0103spunsuri de la altul. Astfel, clientul poate alege serviciul care \u00eei este convenabil, iar sistemul intern va putea totu\u0219i s\u0103 proceseze corect evenimentele.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Dup\u0103 cum \u0219ti\u021bi, una dintre caracteristicile principale ale unui sistem distribuit este lipsa unui timp comun \u0219i a unei sec\u021biuni critice comune. Pentru un singur proces, pute\u021bi realiza sincronizarea (pe acelea\u0219i mutexuri), \u00een care sunte\u021bi sigur c\u0103 nimeni altcineva nu execut\u0103 acest cod. Totu\u0219i, pentru un sistem distribuit, aceasta este periculoas\u0103, deoarece va necesita overhead, iar toat\u0103 frumuse\u021bea scalabilit\u0103\u021bii va fi anulat\u0103 \u2014 \u00een orice caz, toate componentele vor a\u0219tepta una.<\/p>\n

      <\/p>\n

      A\u0219adar, ajungem la un fapt important \u2014 un sistem distribuit rapid nu poate fi sincronizat, deoarece ne va reduce performan\u021ba. Pe de alt\u0103 parte, de multe ori avem nevoie de o anumit\u0103 coeren\u021b\u0103 a componentelor. \u0218i pentru asta putem folosi abordarea cu consisten\u021b\u0103 eventual\u0103<\/a><\/noindex>, unde se garanteaz\u0103 c\u0103, \u00een absen\u021ba modific\u0103rilor datelor, dup\u0103 un anumit interval de timp de la ultima actualizare (\u201e\u00een cele din urm\u0103\u201d), toate solicit\u0103rile vor returna ultima valoare actualizat\u0103.<\/p>\n

      <\/p>\n

      Este important s\u0103 \u00een\u021belegem c\u0103 pentru bazele de date clasice se aplic\u0103 destul de des coeren\u021ba strict\u0103<\/a><\/noindex>, unde fiecare nod de\u021binea aceea\u0219i informa\u021bie (acest lucru se ob\u021bine de obicei atunci c\u00e2nd tranzac\u021bia este considerat\u0103 stabilit\u0103 doar dup\u0103 ce prime\u0219te un r\u0103spuns de la al doilea server). Aici exist\u0103 anumite relax\u0103ri din cauza nivelurilor de izolare, totu\u0219i esen\u021ba general\u0103 r\u0103m\u00e2ne aceea\u0219i \u2014 pute\u021bi tr\u0103i \u00eentr-o lume complet coerent\u0103.<\/p>\n

      <\/p>\n

      Dar s\u0103 ne \u00eentoarcem la problema ini\u021bial\u0103. Dac\u0103 o parte a sistemului poate fi construit\u0103 cu consisten\u021b\u0103 eventual\u0103<\/a><\/noindex>, atunci se poate construi urm\u0103toarea schem\u0103.<\/p>\n

      <\/p>\n

      \"Modele<\/p>\n

      <\/p>\n

      Caracteristicile importante ale acestei abord\u0103ri:<\/p>\n

      <\/p>\n