{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Wyb\u00f3r stylu architektonicznego (cz\u0119\u015b\u0107 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107, Habr. W OTUS w\u0142a\u015bnie otwarto nab\u00f3r na now\u0105 edycj\u0119 kursu. \u201eArchitektura Oprogramowania\u201d<\/a><\/noindex>. Przed rozpocz\u0119ciem kursu chcia\u0142bym podzieli\u0107 si\u0119 z Wami moim autorskim artyku\u0142em.<\/i><\/b><\/p>\n

<\/p>\n

Wprowadzenie<\/h2>\n

\nWyb\u00f3r stylu architektonicznego jest jednym z podstawowych decyzji technicznych przy budowie systemu informacyjnego. W tej serii artyku\u0142\u00f3w proponuj\u0119 om\u00f3wi\u0107 najpopularniejsze style architektoniczne budowy aplikacji i odpowiedzie\u0107 na pytanie, kiedy kt\u00f3ry styl architektoniczny jest najbardziej preferowany. W procesie przedstawiania postaram si\u0119 przeprowadzi\u0107 logiczny ci\u0105g, kt\u00f3ry wyja\u015bnia rozw\u00f3j styl\u00f3w architektonicznych od monolit\u00f3w do mikrosystem\u00f3w.
\n<\/a><\/noindex><\/p>\n

Historia<\/h2>\n

\nJe\u015bli spr\u00f3bujesz zapyta\u0107 deweloper\u00f3w: \u201ePo co s\u0105 mikrous\u0142ugi?\u201d, otrzymasz r\u00f3\u017cnorodne odpowiedzi. Us\u0142yszysz, \u017ce mikrous\u0142ugi poprawiaj\u0105 skalowalno\u015b\u0107, u\u0142atwiaj\u0105 zrozumienie kodu, zwi\u0119kszaj\u0105 odporno\u015b\u0107 na awarie, a czasami us\u0142yszysz, \u017ce pozwalaj\u0105 \u201eoczy\u015bci\u0107 kod\u201d. Przyjrzyjmy si\u0119 historii, aby zrozumie\u0107, jaki cel przy\u015bwieca\u0142 pojawieniu si\u0119 mikrous\u0142ug.<\/p>\n

M\u00f3wi\u0105c kr\u00f3tko, mikrous\u0142ugi w naszym obecnym rozumieniu powsta\u0142y w nast\u0119puj\u0105cy spos\u00f3b: w 2011 roku James Lewis, analizuj\u0105c prace r\u00f3\u017cnych firm, zwr\u00f3ci\u0142 uwag\u0119 na pojawienie si\u0119 nowego wzorca \u201emicro-app\u201d, kt\u00f3ry optymalizowa\u0142 SOA z punktu widzenia przyspieszenia wdra\u017cania us\u0142ug. Nieco p\u00f3\u017aniej, w 2012 roku, na szczycie architektonicznym wzorzec zosta\u0142 przemianowany na mikrous\u0142ug\u0119. Tak wi\u0119c pierwotnym celem wprowadzenia mikrous\u0142ug by\u0142a poprawa tzw. time to market<\/b>.<\/p>\n

Na \u201efali hype'u\u201d mikrous\u0142ugi by\u0142y popularne w 2015 roku. Wed\u0142ug niekt\u00f3rych bada\u0144, \u017cadna konferencja nie odbywa\u0142a si\u0119 bez wyk\u0142adu na temat mikrous\u0142ug. Co wi\u0119cej, niekt\u00f3re konferencje by\u0142y po\u015bwi\u0119cone wy\u0142\u0105cznie mikrous\u0142ugom. Obecnie wiele projekt\u00f3w rozpoczyna si\u0119 od zastosowania tego stylu architektonicznego, a je\u015bli projekt zawiera mn\u00f3stwo kodu Legacy, to na pewno nast\u0119puje aktywna migracja do mikrous\u0142ug.<\/p>\n

Pomimo powy\u017cszego, wci\u0105\u017c stosunkowo niewielka liczba deweloper\u00f3w potrafi zdefiniowa\u0107 poj\u0119cie \u201emikrous\u0142ugi\u201d. Ale o tym porozmawiamy nieco p\u00f3\u017aniej\u2026<\/p>\n

Monolit<\/h2>\n

\nStyl architektoniczny, kt\u00f3ry jest przeciwstawiany mikrous\u0142ugom, to monolit (lub \u201ewszystko w jednym\u201d). My\u015bl\u0119, \u017ce nie ma sensu t\u0142umaczy\u0107, czym jest monolit, dlatego od razu wymieni\u0119 wady tego stylu architektonicznego, kt\u00f3re zainicjowa\u0142y dalszy rozw\u00f3j styl\u00f3w architektonicznych: rozmiar, sp\u00f3jno\u015b\u0107, wdra\u017canie, skalowalno\u015b\u0107, niezawodno\u015b\u0107 i sztywno\u015b\u0107. Poni\u017cej proponuj\u0119 zapozna\u0107 si\u0119 z ka\u017cd\u0105 z tych wad osobno.<\/p>\n

Wymiary<\/h3>\n

\nMonolit jest bardzo du\u017cy. Zazwyczaj komunikuje si\u0119 z ogromn\u0105 baz\u0105 danych. Aplikacja staje si\u0119 zbyt du\u017ca, aby m\u00f3g\u0142 j\u0105 zrozumie\u0107 pojedynczy programista. Z monolitem mog\u0105 dobrze pracowa\u0107 tylko ci, kt\u00f3rzy sp\u0119dzili du\u017co czasu nad tym kodem, podczas gdy nowicjusze sp\u0119dz\u0105 du\u017co czasu na pr\u00f3bach zrozumienia monolitu i nie ma pewno\u015bci, \u017ce im si\u0119 to uda. Zazwyczaj przy pracy z monolitem zawsze jest jaki\u015b \u201ewzgl\u0119dny\u201d starszy programista, kt\u00f3ry zna monolit w miar\u0119 dobrze i pilnuje m\u0142odszych programist\u00f3w przez rok lub p\u00f3\u0142tora. Oczywi\u015bcie, taki wzgl\u0119dny senior staje si\u0119 jedynym punktem awarii, a jego odej\u015bcie mo\u017ce doprowadzi\u0107 do upadku monolitu. <\/p>\n

Powi\u0105zanie<\/h3>\n

\nMonolit to \u201edu\u017ca kula b\u0142ota\u201d (big ball of mud), zmiany w kt\u00f3rym mog\u0105 prowadzi\u0107 do nieprzewidywalnych konsekwencji. Wprowadzenie zmian w jednym miejscu mo\u017ce uszkodzi\u0107 monolit w innym (to w\u0142a\u015bnie to \u201epodrapa\u0142em ucho, a *@ odpad\u0142o\u201d). Wynika to z tego, \u017ce komponenty w monolicie maj\u0105 bardzo skomplikowane i, co najwa\u017cniejsze, nieoczywiste zale\u017cno\u015bci.<\/p>\n

Rozmieszczenie<\/h3>\n

\nWdra\u017canie monolitu, ze wzgl\u0119du na skomplikowane zale\u017cno\u015bci mi\u0119dzy jego komponentami, to d\u0142ugi proces z w\u0142asnym rytua\u0142em. Taki rytua\u0142 zazwyczaj nie jest do ko\u0144ca sformalizowany i przekazywany jest \u201ez ust do ust\u201d. <\/p>\n

Skalowalno\u015b\u0107<\/h3>\n

\nModu\u0142y monolitu mog\u0105 mie\u0107 konfliktuj\u0105ce potrzeby dotycz\u0105ce zasob\u00f3w, przez co konieczne jest szukanie kompromisu z punktu widzenia sprz\u0119tu. Wyobra\u017a sobie, \u017ce tw\u00f3j monolit sk\u0142ada si\u0119 z us\u0142ug A i B. Us\u0142uga A jest wymagaj\u0105ca pod wzgl\u0119dem wielko\u015bci dysku twardego, a us\u0142uga B \u2014 pod wzgl\u0119dem pami\u0119ci operacyjnej. W takim przypadku albo maszyna, na kt\u00f3r\u0105 instalowany jest monolit, musi spe\u0142nia\u0107 wymagania obu us\u0142ug, albo b\u0119dziesz musia\u0142 r\u0119cznie, sztucznie wy\u0142\u0105czy\u0107 jedn\u0105 z us\u0142ug.<\/p>\n

Inny przyk\u0142ad (bardziej klasyczny): us\u0142uga A jest znacznie bardziej popularna ni\u017c us\u0142uga B, wi\u0119c chcesz, aby by\u0142o 100 us\u0142ug A, a 10 us\u0142ug B. Znowu s\u0105 dwa warianty: albo wdra\u017camy 100 pe\u0142noprawnych monolit\u00f3w, albo na niekt\u00f3rych z nich r\u0119cznie musimy wy\u0142\u0105czy\u0107 us\u0142ugi B. <\/p>\n

Niezawodno\u015b\u0107<\/h3>\n

\nPoniewa\u017c wszystkie us\u0142ugi s\u0105 razem, je\u015bli monolit upada, to wszystkie us\u0142ugi padaj\u0105 jednocze\u015bnie. W rzeczywisto\u015bci, mo\u017ce to nie by\u0107 takie z\u0142e, przynajmniej nie b\u0119dzie cz\u0119\u015bciowych awarii w systemie rozproszonym, ale z drugiej strony, z powodu b\u0142\u0119du w funkcjonalno\u015bci, z kt\u00f3rej korzysta 0,001% u\u017cytkownik\u00f3w, mo\u017cesz straci\u0107 wszystkich u\u017cytkownik\u00f3w swojego systemu. <\/p>\n

Sztywno\u015b\u0107<\/h3>\n

\nZe wzgl\u0119du na rozmiar monolitu, trudno jest przej\u015b\u0107 na nowe technologie. W zwi\u0105zku z tym, osobnym zadaniem staje si\u0119 utrzymanie tego samego, warunkowego seniora. Wybrany na pocz\u0105tku projektu stos technologiczny mo\u017ce sta\u0107 si\u0119 przeszkod\u0105 w rozwoju produktu. <\/p>\n

Podsumowanie<\/h2>\n

\nNast\u0119pnym razem porozmawiamy o tym, jak ludzie pr\u00f3bowali rozwi\u0105za\u0107 wskazane problemy, przechodz\u0105c do komponent\u00f3w i SOA.<\/p>\n

\"Wyb\u00f3r<\/a><\/noindex><\/p>\n

\n

Czytaj dalej:<\/h4>\n

<\/p>\n