{"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\/pl\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Wygodne wzorce architektoniczne","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107, Habr!<\/p>\n

<\/p>\n

W \u015bwietle bie\u017c\u0105cych wydarze\u0144 zwi\u0105zanych z koronawirusem szereg us\u0142ug internetowych zacz\u0119\u0142o otrzymywa\u0107 zwi\u0119kszone obci\u0105\u017cenie. Na przyk\u0142ad, jedna z sieci handlowych w Wielkiej Brytanii po prostu wstrzyma\u0142a stron\u0119 z zam\u00f3wieniami online,<\/a><\/noindex>poniewa\u017c nie wystarczy\u0142o mocy obliczeniowej. I nie zawsze mo\u017cna przyspieszy\u0107 serwer, po prostu dodaj\u0105c mocniejszy sprz\u0119t, jednak\u017ce zapytania klient\u00f3w nale\u017cy przetwarza\u0107 (w przeciwnym razie odejd\u0105 do konkurencji).<\/p>\n

<\/p>\n

W tym artykule kr\u00f3tko opisz\u0119 popularne praktyki, kt\u00f3re pozwol\u0105 stworzy\u0107 szybki i odporne na awarie us\u0142ugi. Wybra\u0142em jednak tylko te schematy rozwoju, kt\u00f3re teraz s\u0105 \u0142atwe do wykorzystania.<\/strong>Dla ka\u017cdego punktu ju\u017c masz gotowe biblioteki, lub masz mo\u017cliwo\u015b\u0107 rozwi\u0105zania problemu za pomoc\u0105 platformy chmurowej.<\/p>\n

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

Skalowanie horyzontalne<\/h1>\n

<\/p>\n

Najprostszy i najbardziej znany punkt. Og\u00f3lnie rzecz bior\u0105c, najcz\u0119\u015bciej wyst\u0119puj\u0105 dwa schematy rozk\u0142adu obci\u0105\u017cenia \u2014 skalowanie horyzontalne i wertykalne. W pierwszym przypadku<\/a><\/noindex> pozwalasz us\u0142ugom dzia\u0142a\u0107 r\u00f3wnolegle, w ten spos\u00f3b rozk\u0142adaj\u0105c obci\u0105\u017cenie mi\u0119dzy nimi. W drugim<\/a><\/noindex> zamawiasz mocniejsze serwery lub optymalizujesz kod.<\/p>\n

<\/p>\n

Na przyk\u0142ad we\u017amiemy abstrakcyjne chmurowe miejsce na pliki, czyli jaki\u015b odpowiednik OwnCloud, OneDrive itd.<\/p>\n

<\/p>\n

Standardowy obrazek takiego schematu znajduje si\u0119 poni\u017cej, jednak\u017ce tylko pokazuje z\u0142o\u017cono\u015b\u0107 systemu. Musimy jako\u015b zsynchronizowa\u0107 us\u0142ugi. Co si\u0119 stanie, je\u015bli u\u017cytkownik zapisze plik na tablecie, a nast\u0119pnie chce go zobaczy\u0107 na telefonie?<\/p>\n

<\/p>\n

\"Wygodne
\nR\u00f3\u017cnica mi\u0119dzy podej\u015bciami: przy skalowaniu wertykalnym jeste\u015bmy gotowi zwi\u0119ksza\u0107 moc w\u0119z\u0142\u00f3w, podczas gdy przy skalowaniu horyzontalnym \u2014 dodajemy nowe w\u0119z\u0142y, aby roz\u0142o\u017cy\u0107 obci\u0105\u017cenie.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Segregacja odpowiedzialno\u015bci za polecenia i zapytania<\/a><\/noindex> to do\u015b\u0107 wa\u017cny wzorzec, poniewa\u017c umo\u017cliwia r\u00f3\u017cnym klientom nie tylko \u0142\u0105czenie si\u0119 z r\u00f3\u017cnymi us\u0142ugami, ale tak\u017ce uzyskiwanie tych samych strumieni zdarze\u0144. Jego korzy\u015bci nie s\u0105 tak oczywiste dla prostych aplikacji, jednak jest on niezmiernie wa\u017cny (i prosty) dla obci\u0105\u017conego serwisu. Jego istota: przychodz\u0105ce i wychodz\u0105ce strumienie danych nie powinny si\u0119 krzy\u017cowa\u0107. To znaczy, \u017ce nie mo\u017cesz wys\u0142a\u0107 zapytania i oczekiwa\u0107 odpowiedzi, zamiast tego wysy\u0142asz zapytanie do us\u0142ugi A, jednak otrzymujesz odpowied\u017a w us\u0142udze B.<\/p>\n

<\/p>\n

Pierwsz\u0105 zalet\u0105 tego podej\u015bcia jest mo\u017cliwo\u015b\u0107 przerwania po\u0142\u0105czenia (w najszerszym tego s\u0142owa znaczeniu) w trakcie realizacji d\u0142ugiego zapytania. Dla przyk\u0142adu we\u017amy bardziej standardow\u0105 sekwencj\u0119:<\/p>\n

<\/p>\n

    \n
  1. Klient wys\u0142a\u0142 zapytanie do serwera.<\/li>\n
  2. Serwer rozpocz\u0105\u0142 d\u0142ug\u0105 obr\u00f3bk\u0119.<\/li>\n
  3. Serwer odpowiedzia\u0142 klientowi wynikiem.<\/li>\n<\/ol>\n

    <\/p>\n

    Wyobra\u017amy sobie, \u017ce w punkcie 2 dosz\u0142o do przerwania po\u0142\u0105czenia (czy to sie\u0107 zosta\u0142a prze\u0142\u0105czona, czy u\u017cytkownik przeszed\u0142 na inn\u0105 stron\u0119, przerywaj\u0105c po\u0142\u0105czenie). W takim przypadku serwerowi b\u0119dzie trudno wys\u0142a\u0107 odpowied\u017a do u\u017cytkownika z informacj\u0105, co dok\u0142adnie zosta\u0142o przetworzone. Stosuj\u0105c CQRS, sekwencja b\u0119dzie nieco inna:<\/p>\n

    <\/p>\n

      \n
    1. Klient zapisa\u0142 si\u0119 na aktualizacje.<\/li>\n
    2. Klient wys\u0142a\u0142 zapytanie do serwera.<\/li>\n
    3. Serwer odpowiedzia\u0142 'zapytanie przyj\u0119te'.<\/li>\n
    4. Serwer odpowiedzia\u0142 wynikiem za po\u015brednictwem kana\u0142u z punktu '1'.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Wygodne<\/p>\n

      <\/p>\n

      Jak wida\u0107, schemat jest nieco bardziej skomplikowany. Co wi\u0119cej, intuicyjne podej\u015bcie request-response tutaj nie wyst\u0119puje. Jednak jak wida\u0107, przerwanie po\u0142\u0105czenia podczas przetwarzania zapytania nie prowadzi do b\u0142\u0119du. Co wi\u0119cej, je\u015bli u\u017cytkownik rzeczywi\u015bcie pod\u0142\u0105czy\u0142 si\u0119 do us\u0142ugi z kilku urz\u0105dze\u0144 (na przyk\u0142ad z telefonu kom\u00f3rkowego i tabletu), mo\u017cna zorganizowa\u0107 tak, aby odpowied\u017a przychodzi\u0142a na oba urz\u0105dzenia.<\/p>\n

      <\/p>\n

      Co ciekawe, kod przetwarzania przychodz\u0105cych wiadomo\u015bci staje si\u0119 w pewnym sensie jednolity (nie w 100%) zar\u00f3wno dla zdarze\u0144, na kt\u00f3re wp\u0142ywa sam klient, jak i dla pozosta\u0142ych zdarze\u0144, w tym tych od innych klient\u00f3w.<\/p>\n

      <\/p>\n

      Jednak w rzeczywisto\u015bci zyskujemy dodatkowe korzy\u015bci zwi\u0105zane z tym, \u017ce jednostronny strumie\u0144 mo\u017cna przetwarza\u0107 w stylu funkcyjnym (u\u017cywaj\u0105c RX i analogii). A to ju\u017c jest powa\u017cna zaleta, poniewa\u017c zasadniczo aplikacj\u0119 mo\u017cna uczyni\u0107 w pe\u0142ni reaktywn\u0105, z zastosowaniem podej\u015bcia funkcyjnego. Dla du\u017cych program\u00f3w mo\u017ce to znacznie zaoszcz\u0119dzi\u0107 zasoby na rozw\u00f3j i wsparcie.<\/p>\n

      <\/p>\n

      Je\u015bli po\u0142\u0105czymy to podej\u015bcie z poziomym skalowaniem, zyskujemy mo\u017cliwo\u015b\u0107 wysy\u0142ania zapyta\u0144 do jednego serwera, a odbierania odpowiedzi od innego. W ten spos\u00f3b klient mo\u017ce sam wybiera\u0107 wygodn\u0105 dla siebie us\u0142ug\u0119, a system wewn\u0119trzny wci\u0105\u017c b\u0119dzie m\u00f3g\u0142 prawid\u0142owo przetwarza\u0107 zdarzenia.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Jak wiesz, jedn\u0105 z g\u0142\u00f3wnych cech systemu rozproszonego jest brak wsp\u00f3lnego czasu i wsp\u00f3lnej sekcji krytycznej. Dla jednego procesu mo\u017cna wprowadzi\u0107 synchronizacj\u0119 (na tych samych mutexach), w kt\u00f3rej masz pewno\u015b\u0107, \u017ce nikt inny nie wykonuje tego kodu. Jednak w systemie rozproszonym takie rozwi\u0105zanie jest niebezpieczne, poniewa\u017c wi\u0105\u017ce si\u0119 z dodatkowymi kosztami, a ca\u0142y urok skalowalno\u015bci zostaje zniweczony \u2014 wszyscy komponenty b\u0119d\u0105 czeka\u0142y na jeden.<\/p>\n

      <\/p>\n

      St\u0105d wynika wa\u017cny fakt \u2014 szybkiego systemu rozproszonego nie mo\u017cna synchronizowa\u0107, poniewa\u017c wtedy zmniejszymy wydajno\u015b\u0107. Z drugiej strony cz\u0119sto potrzebna jest okre\u015blona sp\u00f3jno\u015b\u0107 komponent\u00f3w. W tym celu mo\u017cna zastosowa\u0107 podej\u015bcie z sp\u00f3jn\u0105 form\u0105 ko\u0144cow\u0105<\/a><\/noindex>, gdzie gwarantuje si\u0119, \u017ce w przypadku braku zmian danych po pewnym czasie po ostatniej aktualizacji (\u201ew ko\u0144cu\u201d) wszystkie zapytania b\u0119d\u0105 zwraca\u0107 ostatni\u0105 zaktualizowan\u0105 warto\u015b\u0107.<\/p>\n

      <\/p>\n

      Wa\u017cne jest, aby rozumie\u0107, \u017ce w klasycznych bazach danych stosuje si\u0119 do\u015b\u0107 cz\u0119sto surow\u0105 sp\u00f3jno\u015b\u0107<\/a><\/noindex>, gdzie ka\u017cdy w\u0119ze\u0142 ma te same informacje (takie wyniki cz\u0119sto osi\u0105ga si\u0119, gdy transakcja uznawana jest za zako\u0144czon\u0105 dopiero po odpowiedzi drugiego serwera). Istniej\u0105 pewne ust\u0119pstwa ze wzgl\u0119du na poziomy izolacji, jednak og\u00f3lna zasada pozostaje ta sama \u2014 mo\u017cesz \u017cy\u0107 w ca\u0142kowicie sp\u00f3jnym \u015bwiecie.<\/p>\n

      <\/p>\n

      Jednak wr\u00f3\u0107my do pierwotnego zadania. Je\u015bli cz\u0119\u015b\u0107 systemu mo\u017ce by\u0107 zbudowana z sp\u00f3jn\u0105 form\u0105 ko\u0144cow\u0105<\/a><\/noindex>, to mo\u017cna zbudowa\u0107 nast\u0119puj\u0105cy schemat.<\/p>\n

      <\/p>\n

      \"Wygodne<\/p>\n

      <\/p>\n

      Wa\u017cne cechy tego podej\u015bcia:<\/p>\n

      <\/p>\n