{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Mikroserwisy: co to jest, po co to i kiedy je wdra\u017ca\u0107","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Chcia\u0142em napisa\u0107 artyku\u0142 na temat architektury mikrous\u0142ug od d\u0142u\u017cszego czasu, jednak za ka\u017cdym razem powstrzymywa\u0142y mnie dwa momenty \u2014 im bardziej zag\u0142\u0119bia\u0142em si\u0119 w temat, tym bardziej wydawa\u0142o mi si\u0119, \u017ce to, co wiem, jest oczywiste, a to, czego nie wiem, nadal wymaga zg\u0142\u0119biania. Z drugiej strony uwa\u017cam, \u017ce jest ju\u017c o czym rozmawia\u0107 w szerszym gronie. Tak wi\u0119c, alternatywne opinie s\u0105 mile widziane.
\n<\/a><\/noindex><\/p>\n

Prawo Conwaya oraz zwi\u0105zek mi\u0119dzy biznesem, organizacj\u0105 a systemem informacyjnym<\/h2>\n

\nPozw\u00f3lcie, \u017ce po raz kolejny zacytuj\u0119:<\/p>\n

\u201eKa\u017cda organizacja, kt\u00f3ra projektuje jakikolwiek system (w szerokim sensie), otrzyma projekt, kt\u00f3rego struktura kopiuje struktur\u0119 zespo\u0142\u00f3w w tej organizacji\u201d
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

Moim zdaniem, to prawo bardziej odnosi si\u0119 do celowo\u015bci organizacji biznesowej ni\u017c bezpo\u015brednio do systemu informacyjnego. Wyja\u015bni\u0119 to na przyk\u0142adzie. Za\u0142\u00f3\u017cmy, \u017ce mamy do czynienia z wystarczaj\u0105co stabiln\u0105 mo\u017cliwo\u015bci\u0105 biznesow\u0105 z takim cyklem \u017cycia, kt\u00f3ry uzasadnia organizacj\u0119 przedsi\u0119wzi\u0119cia (to nie jest liter\u00f3wka, ale bardzo podoba mi si\u0119 ten termin, kt\u00f3ry 'po\u017cyczy\u0142em'). Oczywi\u015bcie, \u017ce system wspieraj\u0105cy ten biznes b\u0119dzie organizacyjnie i procesowo odpowiada\u0107 temu biznesowi.<\/p>\n

Orientacja biznesowa system\u00f3w informacyjnych<\/h2>\n

\n\"Mikroserwisy:
\n
\nWyja\u015bni\u0119 to na przyk\u0142adzie. Za\u0142\u00f3\u017cmy, \u017ce mamy mo\u017cliwo\u015b\u0107 zorganizowania biznesu zwi\u0105zane z sprzeda\u017c\u0105 pizz. W wersji V1 (nazwijmy j\u0105 przedinformatyczn\u0105) firma stanowi\u0142a pizzeri\u0119, punkt odbioru i us\u0142ug\u0119 dostawy. Ta wersja by\u0142a d\u0142ugowieczna w warunkach niskiej zmienno\u015bci otoczenia. Nast\u0119pnie nadesz\u0142a wersja 2 \u2014 bardziej zaawansowana, potrafi\u0105ca wykorzysta\u0107 system informacyjny w swojej podstawie dla biznesu o architekturze monolitycznej. I tutaj, moim zdaniem, pojawia si\u0119 straszna niesprawiedliwo\u015b\u0107 wobec monolit\u00f3w \u2014 jakoby architektura monolityczna nie odpowiada\u0142a modelowi domeny biznesowej<\/b>Gdyby tak by\u0142o, system w og\u00f3le nie m\u00f3g\u0142by dzia\u0142a\u0107 - w sprzeczno\u015bci z tym samym prawem Conwaya i zdrowym rozs\u0105dkiem. Nie, architektura monolityczna w pe\u0142ni odpowiada modelowi biznesowemu na tym etapie rozwoju firmy \u2014 mam na my\u015bli etap, gdy system jest ju\u017c stworzony i wdro\u017cony. Ciekawym faktem jest to, \u017ce niezale\u017cnie od podej\u015bcia architektonicznego, zar\u00f3wno architektura zorientowana na us\u0142ugi wersji 3, jak i architektura mikroserwisowa wersji N b\u0119d\u0105 dzia\u0142a\u0107 r\u00f3wnie dobrze. Gdzie jest haczyk?<\/p>\n

Wszystko p\u0142ynie, wszystko si\u0119 zmienia, czy mikroserwisy to spos\u00f3b na walk\u0119 z z\u0142o\u017cono\u015bci\u0105?<\/h2>\n

\n Zanim przejdziemy dalej, rozwa\u017cmy niekt\u00f3re nieporozumienia dotycz\u0105ce architektury mikroserwisowej.<\/p>\n

Zwolennicy wykorzystania podej\u015bcia mikroserwisowego cz\u0119sto m\u00f3wi\u0105, \u017ce podzia\u0142 monolitu na mikroserwisy upraszcza podej\u015bcie do programowania poprzez zmniejszenie bazy kodu poszczeg\u00f3lnych us\u0142ug. Moim zdaniem to stwierdzenie to kompletna bzdura. Naprawd\u0119, czy oczywista interakcja w ramach monolitu i jednolitego kodu wydaje si\u0119 skomplikowana? Gdyby tak rzeczywi\u015bcie by\u0142o, wszystkie projekty by\u0142yby od razu budowane jako mikroserwisy, podczas gdy praktyka pokazuje, \u017ce migracja z monolitu do mikroserwis\u00f3w jest znacznie bardziej powszechna. Z\u0142o\u017cono\u015b\u0107 nigdzie nie znika, po prostu przenosi si\u0119 z poszczeg\u00f3lnych modu\u0142\u00f3w do interfejs\u00f3w (czy to szyn danych, RPC, API i innych protoko\u0142\u00f3w) oraz system\u00f3w orkiestruj\u0105cych. I to jest trudne! <\/p>\n

Zalet\u0105 korzystania z heterogenicznego staku r\u00f3wnie\u017c jest w\u0105tpliwa. Nie zamierzam dyskutowa\u0107, \u017ce jest to mo\u017cliwe, ale w rzeczywisto\u015bci rzadko spotykane (Z przodu \u2014 musi to mie\u0107 miejsce \u2014 ale raczej jako konsekwencja, a nie zaleta).<\/p>\n

Cykl \u017cycia produktu i cykl \u017cycia us\u0142ugi<\/h2>\n

\nSp\u00f3jrz jeszcze raz na diagram powy\u017cej. Nieprzypadkowo zaznaczy\u0142em skracaj\u0105cy si\u0119 cykl \u017cycia poszczeg\u00f3lnych wersji biznesu \u2014 w dzisiejszych warunkach to w\u0142a\u015bnie przyspieszenie przej\u015bcia biznesu mi\u0119dzy wersjami decyduje o jego sukcesie. Sukces produktu okre\u015bla szybko\u015b\u0107 weryfikacji hipotez biznesowych w nim<\/b>. I tutaj, moim zdaniem, tkwi kluczowa zaleta architektury mikroserwisowej. Ale przejd\u017amy do sedna. <\/p>\n

Przejd\u017amy do kolejnego etapu ewolucji system\u00f3w informacyjnych \u2014 do architektury zorientowanej na us\u0142ugi SOA. W pewnym momencie wydzielili\u015bmy w naszym produkcie d\u0142ugowieczne us\u0142ugi<\/b> \u2014 d\u0142ugowieczne w tym sensie, \u017ce podczas przej\u015bcia mi\u0119dzy wersjami produktu istniej\u0105 szanse, \u017ce cykl \u017cycia us\u0142ugi b\u0119dzie d\u0142u\u017cszy ni\u017c cykl \u017cycia danej wersji produktu. Logiczne by\u0142oby ich w og\u00f3le nie zmienia\u0107 \u2014 dla nas wa\u017cna jest szybko\u015b\u0107 przechodzenia do nast\u0119pnej wersji<\/b>. Niestety, musimy wprowadza\u0107 ci\u0105g\u0142e zmiany w us\u0142ugach \u2014 i tutaj przydaj\u0105 si\u0119 wszystkie praktyki DevOps, konteneryzacja i wszystko, co przyjdzie nam do g\u0142owy. Ale to wci\u0105\u017c nie s\u0105 mikroserwisy! <\/p>\n

Mikroserwisy jako \u015brodek do walki ze z\u0142o\u017cono\u015bci\u0105\u2026 zarz\u0105dzaniem konfiguracj\u0105<\/h2>\n

\n I tutaj mo\u017cemy w ko\u0144cu przej\u015b\u0107 do decyduj\u0105cej roli mikroserwis\u00f3w \u2014 to podej\u015bcie upraszczaj\u0105ce zarz\u0105dzanie konfiguracj\u0105 produktu. M\u00f3wi\u0105c dok\u0142adniej, funkcja ka\u017cdego mikroserwisu opisuje w\u0142a\u015bnie funkcj\u0119 biznesow\u0105 w produkcie zgodnie z modelem domenowym \u2014 a to s\u0105 ju\u017c rzeczy, kt\u00f3re \u017cyj\u0105 nie w kr\u00f3tkowiecznej wersji, ale w d\u0142ugowiecznej mo\u017cliwo\u015bci biznesowej. Przej\u015bcie do nast\u0119pnej wersji produktu odbywa si\u0119 dos\u0142ownie niezauwa\u017calnie \u2014 zmieniasz\/dodajesz jeden mikroserwis, a mo\u017ce po prostu schemat ich interakcji i nagle znajdujesz si\u0119 ju\u017c w przysz\u0142o\u015bci, zostawiaj\u0105c za sob\u0105 p\u0142acz\u0105cych konkurent\u00f3w, kt\u00f3rzy wci\u0105\u017c skacz\u0105 mi\u0119dzy wersjami swoich monolit\u00f3w. Teraz wyobra\u017a sobie, \u017ce masz wystarczaj\u0105co du\u017c\u0105 liczb\u0119 mikroserwis\u00f3w z wcze\u015bniej okre\u015blonymi interfejsami i mo\u017cliwo\u015bciami biznesowymi. Przyjdziesz i zbudujesz struktur\u0119 swojego produktu z gotowych mikroserwis\u00f3w \u2014 po prostu rysuj\u0105c diagram, na przyk\u0142ad. Gratulacje \u2014 masz teraz platform\u0119 \u2014 i teraz mo\u017cesz stworzy\u0107 sobie biznes na wskro\u015b. Marzenia, marzenia. <\/p>\n

Wnioski<\/h2>\n

<\/p>\n