{"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\/lv\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"\u0112rti arhitekt\u016bras mode\u013ci","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sveiki, Habr!<\/p>\n

<\/p>\n

Saist\u012bb\u0101 ar pa\u0161reiz\u0113jiem notikumiem, kas saist\u012bti ar koronav\u012brusu, vair\u0101ki interneta pakalpojumi ir sa\u0146\u0113mu\u0161i palielin\u0101tu slodzi. Piem\u0113ram, viena no tirdzniec\u012bbas \u0137\u0113d\u0113m Apvienotaj\u0101 Karalist\u0113 vienk\u0101r\u0161i apst\u0101din\u0101ja tie\u0161saistes pas\u016bt\u012bjumu vietni,<\/a><\/noindex>, jo jaudu nepietika. Un ne vienm\u0113r ir iesp\u0113jams pa\u0101trin\u0101t serveri, vienk\u0101r\u0161i pievienojot jaud\u012bg\u0101ku aparat\u016bru, tom\u0113r klientu piepras\u012bjumi ir j\u0101apstr\u0101d\u0101 (vai tie aizies pie konkurentiem).<\/p>\n

<\/p>\n

\u0160aj\u0101 rakst\u0101 es \u012bsi past\u0101st\u012b\u0161u par popul\u0101r\u0101m praks\u0113m, kuras \u013caus izveidot \u0101tru un notur\u012bgu pakalpojumu. Tom\u0113r no iesp\u0113jamaj\u0101m izstr\u0101des sh\u0113m\u0101m es izv\u0113l\u0113jos tikai t\u0101s, ar kur\u0101m \u0161obr\u012bd ir viegli izmantot.<\/strong>Katram punktam jums vai nu ir jau gatavas bibliot\u0113kas, vai iesp\u0113ja atrisin\u0101t uzdevumu, izmantojot m\u0101ko\u0146a platformu.<\/p>\n

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

Horizont\u0101l\u0101 m\u0113rogo\u0161ana<\/h1>\n

<\/p>\n

Visvienk\u0101r\u0161\u0101kais un visiem zin\u0101ms punkts. Nosac\u012bti visbie\u017e\u0101k sastopamas divas slodzes sadales sh\u0113mas \u2014 horizont\u0101l\u0101 un vertik\u0101l\u0101 m\u0113rogo\u0161ana. Pirmaj\u0101 gad\u012bjum\u0101<\/a><\/noindex> j\u016bs \u013caujat pakalpojumiem darboties paral\u0113li, t\u0101d\u0113j\u0101di sadalot slodzi starp tiem. Otraj\u0101<\/a><\/noindex> j\u016bs pas\u016bt\u0101t jaud\u012bg\u0101kus serverus vai optimiz\u0113jat kodu.<\/p>\n

<\/p>\n

Piem\u0113ram, es pa\u0146em\u0161u abstraktu m\u0101ko\u0146u failu glab\u0101\u0161anu, t\u0101tad noteiktu OwnCloud, OneDrive u.c. analogu.<\/p>\n

<\/p>\n

Standarta att\u0113ls \u0161\u0101das sh\u0113mas apak\u0161\u0101 ir nor\u0101d\u012bts zem\u0101k, tom\u0113r tas tikai demonstr\u0113 sist\u0113mas sare\u017e\u0123\u012bt\u012bbu. Galu gal\u0101 mums ir nepiecie\u0161ams k\u0101d\u0101 veid\u0101 sinhroniz\u0113t pakalpojumus. Kas notiks, ja no plan\u0161etdatora lietot\u0101js saglab\u0101s failu, bet p\u0113c tam v\u0113las to apskat\u012bt ar telefonu?<\/p>\n

<\/p>\n

\"\u0112rti
\nAt\u0161\u0137ir\u012bba starp pieej\u0101m: vertik\u0101laj\u0101 m\u0113rogo\u0161an\u0101 m\u0113s esam gatavi palielin\u0101t mezglu jaudu, bet horizont\u0101laj\u0101 \u2014 pievienot jaunus mezglus, lai sadal\u012btu slodzi.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> ir diezgan svar\u012bga sh\u0113ma, jo t\u0101 \u013cauj da\u017e\u0101diem klientiem ne tikai piesl\u0113gties da\u017e\u0101diem pakalpojumiem, bet ar\u012b sa\u0146emt vien\u0101dus notikumu pl\u016bsmas. T\u0101s priek\u0161roc\u012bbas nav tik ac\u012bmredzamas vienk\u0101r\u0161ai lietojumprogrammai, tom\u0113r t\u0101s ir \u0101rk\u0101rt\u012bgi svar\u012bgas (un vienk\u0101r\u0161as) slodzes pakalpojumam. T\u0101s b\u016bt\u012bba: ien\u0101ko\u0161aj\u0101m un izejo\u0161aj\u0101m datu pl\u016bsm\u0101m nedr\u012bkst krustoties. Proti, j\u016bs nevarat nos\u016bt\u012bt piepras\u012bjumu un gaid\u012bt atbildi, viet\u0101 tam j\u016bs nos\u016bt\u0101t piepras\u012bjumu pakalpojum\u0101 A, tom\u0113r sa\u0146emat atbildi pakalpojum\u0101 B.<\/p>\n

<\/p>\n

\u0160\u012b pieejas pirm\u0101 priek\u0161roc\u012bba ir iesp\u0113ja p\u0101rtraukt savienojumu (pla\u0161\u0101 noz\u012bm\u0113) ilga piepras\u012bjuma izpildes laik\u0101. Apskat\u012bsim vair\u0101k vai maz\u0101k standarta sec\u012bbu:<\/p>\n

<\/p>\n

    \n
  1. Klients nos\u016bt\u012bja piepras\u012bjumu uz serveri.<\/li>\n
  2. Serveris uzs\u0101ka garu apstr\u0101di.<\/li>\n
  3. Serveris atbild\u0113ja klientam ar rezult\u0101tu.<\/li>\n<\/ol>\n

    <\/p>\n

    Iedom\u0101simies, ka 2. punkt\u0101 notika savienojuma p\u0101rtraukums (vai nu t\u012bkls p\u0101rsl\u0113dz\u0101s, vai lietot\u0101js p\u0101rg\u0101ja uz citu lapu, p\u0101rtraucot savienojumu). \u0160aj\u0101 gad\u012bjum\u0101 serverim b\u016bs gr\u016bti nos\u016bt\u012bt atbildi lietot\u0101jam ar inform\u0101ciju par to, kas tie\u0161i tika apstr\u0101d\u0101ts. Izmantojot CQRS, sec\u012bba b\u016bs nedaudz at\u0161\u0137ir\u012bga:<\/p>\n

    <\/p>\n

      \n
    1. Klients pierakst\u012bj\u0101s uz atjaunin\u0101jumiem.<\/li>\n
    2. Klients nos\u016bt\u012bja piepras\u012bjumu uz serveri.<\/li>\n
    3. Serveris atbild\u0113ja: \"piepras\u012bjums pie\u0146emts\".<\/li>\n
    4. Serveris atbild\u0113ja ar rezult\u0101tu caur kan\u0101lu no punkta \"1\".<\/li>\n<\/ol>\n

      <\/p>\n

      \"\u0112rti<\/p>\n

      <\/p>\n

      K\u0101 redzams, sh\u0113ma ir nedaudz sare\u017e\u0123\u012bt\u0101ka. Vair\u0101k nek\u0101 tam, intuit\u012bv\u0101 pieeja piepras\u012bjums-atbilde \u0161eit nav kl\u0101teso\u0161a. Tom\u0113r k\u0101 redzams, savienojuma p\u0101rtraukums piepras\u012bjuma apstr\u0101des laik\u0101 nenoved\u012bs pie k\u013c\u016bdas. Turkl\u0101t, ja lietot\u0101js patie\u0161\u0101m ir savienots ar pakalpojumu no vair\u0101kiem ier\u012bc\u0113m (piem\u0113ram, no mobil\u0101 telefona un plan\u0161etes), ir iesp\u0113jams pan\u0101kt, ka atbilde tiek sa\u0146emta uz ab\u0101m ier\u012bc\u0113m.<\/p>\n

      <\/p>\n

      Interesanti, ka ien\u0101ko\u0161o zi\u0146ojumu apstr\u0101des kods k\u013c\u016bst l\u012bdz\u012bgs (ne uz 100%) gan tiem notikumiem, uz kuriem ietekm\u0113ja pats klients, gan citiem notikumiem, tostarp no citiem klientiem.<\/p>\n

      <\/p>\n

      Tom\u0113r realit\u0101t\u0113 m\u0113s ieg\u016bstam papildu priek\u0161roc\u012bbas, jo vienvirziena pl\u016bsmu var apstr\u0101d\u0101t funkcion\u0101laj\u0101 stil\u0101 (izmantojot RX un analogus). Un tas ir nopietns pluss, jo b\u016bt\u012bb\u0101 lietojumprogrammu var izveidot piln\u012bgi reakt\u012bvu, izmantojot v\u0113l funkcion\u0101lo pieeju. Lieliem projektiem tas var b\u016btiski ietaup\u012bt resursus izstr\u0101d\u0113 un atbalst\u0101.<\/p>\n

      <\/p>\n

      Ja apvieno \u0161o pieeju ar horizont\u0101lu m\u0113rogojam\u012bbu, tad bonus\u0101 m\u0113s ieg\u016bstam iesp\u0113ju nos\u016bt\u012bt piepras\u012bjumus uz vienu serveri, bet sa\u0146emt atbildes no cita. T\u0101d\u0113j\u0101di klients var pats izv\u0113l\u0113ties sev \u0113rtu pakalpojumu, bet sist\u0113ma iek\u0161pus\u0113 tom\u0113r sp\u0113s pareizi apstr\u0101d\u0101t notikumus.<\/p>\n

      <\/p>\n

      Notikumu avotu<\/h1>\n

      <\/p>\n

      K\u0101 j\u016bs zin\u0101t, viena no galvenaj\u0101m izplat\u012bto sist\u0113mu \u012bpa\u0161\u012bb\u0101m ir kop\u012bga laika un kop\u012bgas kritisk\u0101s sekcijas tr\u016bkums. Vienam procesam varat veikt sinhroniz\u0101ciju (uz to pa\u0161u mutex), iek\u0161\u0101 kur\u0101 esat p\u0101rliecin\u0101ts, ka neviens cits neizpilda \u0161o kodu. Tom\u0113r izplat\u012btai sist\u0113mai tas ir b\u012bstami, jo tam b\u016bs nepiecie\u0161ami papildu izdevumi, k\u0101 ar\u012b tiks zaud\u0113ta visa m\u0113rogo\u0161anas pievilc\u012bba \u2014 tom\u0113r visi komponenti gaid\u012bs vienu.<\/p>\n

      <\/p>\n

      No t\u0101 ieg\u016bstam svar\u012bgu faktu \u2014 \u0101tru izplat\u012btu sist\u0113mu nevar sinhroniz\u0113t, jo tad m\u0113s samazin\u0101sim veiktsp\u0113ju. No otras puses, bie\u017ei vien mums nepiecie\u0161ama noteikta komponentu saska\u0146ot\u012bba. Un tam var izmantot pieeju ar eventual consistency<\/a><\/noindex>, kur tiek garant\u0113ts, ka datos neizmai\u0146u gad\u012bjum\u0101 p\u0113c k\u0101da laika p\u0113c p\u0113d\u0113j\u0101s atjaunin\u0101\u0161anas (\u201cgalu gal\u0101\u201d) visas piepras\u012bjumi atgriez\u012bs p\u0113d\u0113jo atjaunin\u0101to v\u0113rt\u012bbu.<\/p>\n

      <\/p>\n

      Ir svar\u012bgi saprast, ka klasisk\u0101m datu b\u0101z\u0113m bie\u017ei tiek izmantota stingra saska\u0146ot\u012bba<\/a><\/noindex>, kur katram mezglam ir vien\u0101da inform\u0101cija (\u0161\u0101du parasti sasniedz, ja dar\u012bjums tiek uzskat\u012bts par izveidotu tikai p\u0113c otr\u0101 servera atbildes). \u0160eit ir da\u017ei atvieglojumi d\u0113\u013c izol\u0101cijas l\u012bme\u0146iem, tom\u0113r kop\u0113j\u0101 b\u016bt\u012bba paliek nemain\u012bga \u2014 j\u016bs varat dz\u012bvot piln\u012bgi saska\u0146ot\u0101 pasaul\u0113.<\/p>\n

      <\/p>\n

      Tom\u0113r atgriez\u012bsimies pie s\u0101kotn\u0113j\u0101s uzdevuma. Ja da\u013ca sist\u0113mas var tikt uzb\u016bv\u0113ta ar eventual consistency<\/a><\/noindex>, tad var uzb\u016bv\u0113t n\u0101kamo sh\u0113mu.<\/p>\n

      <\/p>\n

      \"\u0112rti<\/p>\n

      <\/p>\n

      Svar\u012bgas \u0161\u012b pieejas iez\u012bmes:<\/p>\n

      <\/p>\n