{"id":31124,"date":"2019-10-31T21:39:36","date_gmt":"2019-10-31T18:39:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie\/"},"modified":"2019-10-31T21:39:36","modified_gmt":"2019-10-31T18:39:36","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Elementy buduj\u0105ce aplikacje rozproszone. Drugie podej\u015bcie","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Og\u0142oszenie<\/strong><\/p>\n

<\/p>\n

Kole\u017canki i koledzy, w \u015brodku lata planuj\u0119 opublikowa\u0107 kolejny cykl artyku\u0142\u00f3w na temat projektowania system\u00f3w obs\u0142ugi masowej: \u201eEksperyment VTrade\u201d \u2013 pr\u00f3ba stworzenia frameworka dla system\u00f3w handlowych. W cyklu om\u00f3wimy teori\u0119 i praktyk\u0119 budowy gie\u0142dy, aukcji i sklepu. Na ko\u0144cu artyku\u0142u proponuj\u0119 zag\u0142osowa\u0107 na najciekawsze dla Was tematy.
\n<\/em><\/p>\n

<\/p>\n

\"Elementy<\/p>\n

<\/p>\n

To ko\u0144cowy artyku\u0142 cyklu o rozproszonych aplikacjach reaktywnych na Erlang\/Elixir. W pierwszym artykule<\/a><\/noindex> mo\u017cna znale\u017a\u0107 teoretyczne podstawy architektury reaktywnej. Drugi artyku\u0142<\/a><\/noindex> ilustruje g\u0142\u00f3wne wzorce i mechanizmy budowy podobnych system\u00f3w.<\/p>\n

<\/p>\n

Dzi\u015b poruszymy kwestie rozwoju bazy kodu i projekt\u00f3w jako ca\u0142o\u015bci. <\/p>\n

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

Organizacja us\u0142ug<\/h2>\n

<\/p>\n

W rzeczywisto\u015bci, przy projektowaniu us\u0142ugi cz\u0119sto trzeba \u0142\u0105czy\u0107 kilka wzorc\u00f3w interakcji w jednym kontrolerze. Na przyk\u0142ad, us\u0142uga users, kt\u00f3ra zajmuje si\u0119 zarz\u0105dzaniem profilami u\u017cytkownik\u00f3w projektu, powinna odpowiada\u0107 na zapytania req-resp i informowa\u0107 o aktualizacjach profili poprzez pub-sub. Ten przypadek jest do\u015b\u0107 prosty: za messagingiem stoi jeden kontroler, kt\u00f3ry realizuje logik\u0119 us\u0142ugi i publikuje aktualizacje.<\/p>\n

<\/p>\n

Sytuacja komplikuje si\u0119, gdy potrzebujemy wdro\u017cy\u0107 odporn\u0105 na b\u0142\u0119dy rozproszon\u0105 us\u0142ug\u0119. Za\u0142\u00f3\u017cmy, \u017ce wymagania wobec users si\u0119 zmieni\u0142y: <\/p>\n

<\/p>\n

    \n
  1. teraz us\u0142uga musi obs\u0142ugiwa\u0107 zapytania na 5 w\u0119z\u0142ach klastra, <\/li>\n
  2. mie\u0107 mo\u017cliwo\u015b\u0107 wykonywania zada\u0144 w tle, <\/li>\n
  3. a tak\u017ce umie\u0107 dynamicznie zarz\u0105dza\u0107 listami subskrypcyjnymi na aktualizacje profili.<\/li>\n<\/ol>\n

    <\/p>\n

    Uwaga:<\/em> Kwestia sp\u00f3jnego przechowywania i replikacji danych nie jest przez nas rozpatrywana. Zak\u0142adamy, \u017ce te kwestie zosta\u0142y rozwi\u0105zane wcze\u015bniej i w systemie ju\u017c istnieje niezawodna i skalowalna warstwa przechowywania, a przetwarzacze maj\u0105 mechanizmy interakcji z ni\u0105.<\/p>\n

    <\/p>\n

    Formalny opis us\u0142ugi users sta\u0142 si\u0119 bardziej skomplikowany. Z perspektywy programisty, dzi\u0119ki zastosowaniu messagingu, zmiany s\u0105 minimalne. Aby spe\u0142ni\u0107 pierwsze wymaganie, musimy skonfigurowa\u0107 balansowanie na punkcie wymiany req-resp. <\/p>\n

    <\/p>\n

    Wym\u00f3g przetwarzania zada\u0144 w tle wyst\u0119puje cz\u0119sto. W przypadku u\u017cytkownik\u00f3w mog\u0105 to by\u0107 weryfikacje dokument\u00f3w u\u017cytkownik\u00f3w, przetwarzanie przes\u0142anego multimedia lub synchronizacja danych z sieciami spo\u0142eczno\u015bciowymi. Te zadania musz\u0105 by\u0107 w jaki\u015b spos\u00f3b podzielone w ramach klastra i kontrolowane. Dlatego mamy dwa warianty rozwi\u0105zania: albo skorzysta\u0107 ze wzorca przydzielania zada\u0144 z poprzedniego artyku\u0142u, albo, je\u015bli si\u0119 nie nadaje, napisa\u0107 niestandardowy harmonogram zada\u0144, kt\u00f3ry b\u0119dzie w odpowiedni spos\u00f3b zarz\u0105dza\u0142 pul\u0105 przetwarzaj\u0105cych. <\/p>\n

    <\/p>\n

    Punkt 3 wymaga rozszerzenia wzorca pub-sub. Aby to zrealizowa\u0107, po utworzeniu punktu wymiany pub-sub, musimy dodatkowo uruchomi\u0107 kontroler tego punktu w naszym serwisie. W ten spos\u00f3b jakby wyjmujemy logik\u0119 przetwarzania subskrypcji i wypisania z warstwy messaging do implementacji u\u017cytkownik\u00f3w.<\/p>\n

    <\/p>\n

    W wyniku tego, dekompozycja zadania pokaza\u0142a, \u017ce aby spe\u0142ni\u0107 wymagania, musimy uruchomi\u0107 na r\u00f3\u017cnych w\u0119z\u0142ach 5 egzemplarzy serwisu i stworzy\u0107 dodatkow\u0105 encj\u0119 \u2013 kontroler pub-sub, odpowiedzialny za subskrycj\u0119.
    \nAby uruchomi\u0107 5 przetw\u00f3rc\u00f3w, nie ma potrzeby zmiany kodu serwisu. Jedynym dodatkowym dzia\u0142aniem jest konfiguracja zasad r\u00f3wnowa\u017cenia na punkcie wymiany, o czym porozmawiamy nieco p\u00f3\u017aniej.
    \nPojawi\u0142a si\u0119 tak\u017ce dodatkowa z\u0142o\u017cono\u015b\u0107: kontroler pub-sub i niestandardowy harmonogram zada\u0144 musz\u0105 dzia\u0142a\u0107 w pojedynczym egzemplarzu. Znowu, serwis messaging, jako fundament, powinien dostarcza\u0107 mechanizm wyboru lidera.<\/p>\n

    <\/p>\n

    Wyb\u00f3r lidera<\/h3>\n

    <\/p>\n

    W systemach rozproszonych wyb\u00f3r lidera to procedura wyznaczania jednego procesu, kt\u00f3ry odpowiada za planowanie rozproszonego przetwarzania jakiego\u015b obci\u0105\u017cenia. <\/p>\n

    <\/p>\n

    W systemach, kt\u00f3re nie s\u0105 sk\u0142onne do centralizacji, stosowane s\u0105 uniwersalne algorytmy i algorytmy oparte na konsensie, na przyk\u0142ad Paxos lub Raft.
    \nPoniewa\u017c messaging to broker i centralny element, to wie o wszystkich kontrolerach serwisu \u2013 kandydatach na lider\u00f3w. Messaging mo\u017ce wyznacza\u0107 lidera bez przeprowadzania g\u0142osowania.<\/p>\n

    <\/p>\n

    Wszystkie serwisy po starcie i po\u0142\u0105czeniu z punktem wymiany otrzymuj\u0105 wiadomo\u015b\u0107 systemow\u0105 #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. Je\u015bli LeaderPid<\/code> jest zgodny z pid<\/code> bie\u017c\u0105cego procesu, zostaje on wyznaczony liderem, a lista Servers<\/code> zawiera wszystkie w\u0119z\u0142y i ich parametry.
    \nW momencie pojawienia si\u0119 nowego i wy\u0142\u0105czenia dzia\u0142aj\u0105cego w\u0119z\u0142a klastra, wszystkie kontrolery us\u0142ug otrzymuj\u0105 #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> i #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> odpowiednio.<\/p>\n

    <\/p>\n

    Dzi\u0119ki temu wszystkie komponenty s\u0105 \u015bwiadome wszystkich zmian, a w klastrze w ka\u017cdym momencie czasu jest gwarantowany jeden lider.<\/p>\n

    <\/p>\n

    Po\u015brednicy<\/h2>\n

    <\/p>\n

    Aby zrealizowa\u0107 z\u0142o\u017cone rozproszone procesy przetwarzania oraz w zadaniach optymalizacji ju\u017c istniej\u0105cej architektury, wygodnie jest stosowa\u0107 po\u015brednik\u00f3w.
    \nAby nie zmienia\u0107 kodu us\u0142ug i rozwi\u0105zywa\u0107 na przyk\u0142ad problemy z dodatkowym przetwarzaniem, trasowaniem lub logowaniem wiadomo\u015bci, przed us\u0142ug\u0105 mo\u017cna w\u0142\u0105czy\u0107 proxy, kt\u00f3re wykona ca\u0142\u0105 dodatkow\u0105 prac\u0119.<\/p>\n

    <\/p>\n

    Klasycznym przyk\u0142adem optymalizacji pub-sub jest rozproszona aplikacja z rdzeniem biznesowym, generuj\u0105cym zdarzenia aktualizacji, na przyk\u0142ad zmian\u0119 ceny na rynku, oraz warstw\u0105 dost\u0119pu \u2014 N serwerami, kt\u00f3re oferuj\u0105 websocket API dla klient\u00f3w webowych.
    \nJe\u015bli podej\u015b\u0107 do tego \"wprost\", to obs\u0142uga klienta wygl\u0105da nast\u0119puj\u0105co:<\/p>\n

    <\/p>\n