Node js Microservices czy dobrze to rozumiem?

pytanie zadane 22 lipca 2020 w JavaScript przez HartRidg Nowicjusz (140 p.)

Cześć,

Zainteresowałem się ostatnio tematyką mikroserwisów ale co czytam jakiś artykuł czy film na youtube to każdy przedstawia to w trochę inny sposób i jestem lekko zdezorientowany.

Z tego co rozumiem to tworzę oddzielne serwery node.js każda do innego zadania z różnymi portami a na końcu tworzę jeden głównym serwer który obsługuje pozostałe i pozwala im na komunikację. Dobrze zrozumiałem?
Kolejną sprawą jest docker w każdym artykule jest wzmianka o nim i tu mam pytanie czy doker jest konieczny czy można sobie bez niego poradzić i do czego się przydaje w mikroserwisach?

1 odpowiedź

odpowiedź 22 lipca 2020 przez Comandeer Guru (601,930 p.)

Docker w teorii nie jest konieczny, ale w praktyce nie bardzo sobie wyobrażam tworzenie mikroserwisów bez niego. Docker pozwal odizolować konkretny mikroserwis od całej reszty. Jeśli sobie postawisz mikroserwisy bezpośrednio w systemie, to będą na siebie bezpośrednio wpływać. Dzięki Dockerowi to po prostu nie jest możliwe.

Co do jednego serwera, który koordynuje komunikację: to typowy single point of failure, a po to się robi mikroserwisy, żeby czegoś takiego uniknąć. W architekturze mikroserwisowej nigdy nie powinno być jednej usługi, której pad oznacza pad całego systemu. Zawsze powinna być redundancja i jeśli jeden serwis pada, to jest inny, mogący przejąć jego zadania.

komentarz 22 lipca 2020 przez Paweł Nąckiewicz Nałogowiec (48,990 p.)

Możesz podesłać jakiś link do projektu/artykułu/tutoriala który bardziej rozszerza Twoja wypowiedź. Chętnie zagłębiłbym się w ten temat

2	komentarz 22 lipca 2020 przez Comandeer Guru (601,930 p.) W sumie to polecam książkę: https://microservices.io/book – stanowi dość sensowne wprowadzenie do tematyki mikroserwisów.

komentarz 22 lipca 2020 przez Tomek Sochacki Ekspert (227,510 p.)

jeśli jeden serwis pada, to jest inny, mogący przejąć jego zadania.

nie do końca się zgodzę... pad całego systemu może i nie, ale np. większości funkcjonalności to już tak.. wyobrażmy sobie np. jeden serwis odpowiedzialny za auth userów. Gdy z jakiegoś powodu padną wszystkie dostępne instancje tej usługi to z dużym prawdopodobieństwem można powiedzieć, że większość corowych funkcjonalności aplikacji będzie niedostępna. Załóżmy np. drugi serwis odpowiedzialny np. za storowanie listy ofert w sklepie, pad tych dwóch usług rozkłada na łopatki aplikację...

Oczywiście zawsze robi się wszystko aby do tego nie doprowadzić, jakieś auto skalowanie instancji itp. itd. ale jak najbardziej w architekturze mikroserwisów problemy 1-2 usług mogą doprowadzić do awarii aplikacji. Wiadomo, powinno się robić wszystko aby tego unikać ale często nie jest to takie proste jak piszą w książkach...

i pytanie co rozumiesz przez przejęcie odpowiedzialności przez inny serwis? Po to są właśnie mikroserwisy, aby robiły dokładnie określone zadania, a nie wszystko :)

komentarz 22 lipca 2020 przez Comandeer Guru (601,930 p.)

i pytanie co rozumiesz przez przejęcie odpowiedzialności przez inny serwis? Po to są właśnie mikroserwisy, aby robiły dokładnie określone zadania, a nie wszystko :)

Chodzi mi o inną instancję tego samego serwisu – w tym sensie inny.

Jeśli ma się odpowiednio zrobioną redundancję i zarządzanie serwisami, to ryzyko, że jakiś faktycznie wyłoży się na amen jest naprawdę niskie i w większości przypadków powinno się samo ogarnąć. A jak się zrobi jeszcze alerty dla teamu, że coś się dzieje niepokojącego, to już wgl jest mała szansa, że wybuchnie pożar.

komentarz 22 lipca 2020 przez reaktywny Nałogowiec (41,090 p.)

@Paweł Nąckiewicz, strona Martina Fowlera jest znakomitym źródłem wiedzy na temat microservices. https://martinfowler.com/tags/microservices.html

Nie jedynym oczywiście, ale bardzo dobrym.

komentarz 22 lipca 2020 przez Tomek Sochacki Ekspert (227,510 p.)

Jak instancja to ok, to się zgadzam :)

Co do ryzyka... powiem Ci z własnego doswiadczenia ze niestety sporadycznie ale bywają takie sytuacje... czasami może zawinic nawet narzedzie do przeciwdzialania takim przypadkom jal auto skalery itp. Druga rzecz ze może zawieźć np. Baza, czasem może pójść jakiś nagly ruch ponad możliwości uslug, a wszystkie skalery itp tez dzialaja zawsze z jakimś opoznieniem... alerty racja czesto pozwalaja szybko podjąć dzialanie pod warunkiem oczywiscie ze masz odpowiednie metryki na alerty :)

Ale wydaje mi sie że na pewno łatwiej w razie czego przywracać do życia apke w mikroserwisach niż monolity gdzie jak pada to wszystko...

komentarz 22 lipca 2020 przez reaktywny Nałogowiec (41,090 p.)

@Comandeer, w sumie jest ona już przetłumaczona na polski, przez PWN, więc jakość tłumaczenia powinna być dobra.

https://helion.pl/ksiazki/mikroserwisy-wzorce-z-przykladami-w-jezyku-java-chris-richardson,a_0jbg.htm#format/d

komentarz 22 lipca 2020 przez Comandeer Guru (601,930 p.)

przez PWN

To właśnie wręcz gwarancja, że tłumaczenie będzie fatalne…

komentarz 22 lipca 2020 przez reaktywny Nałogowiec (41,090 p.)

Eeee tam, chyba nie masz racji :) Choć dokładnych statystyk nie posiadam :) Z tego co się orientuje Helion miał najwięcej wpadek w tłumaczeniach. PWN jednak ma nie tylko tłumaczy, ale też przeprowadza korektę.

Zaskoczyłeś mnie tym stwierdzeniem. Ale może to ja się mylę, niewykluczone.

komentarz 22 lipca 2020 przez adrian17 Ekspert (345,160 p.)

Ale wydaje mi sie że na pewno łatwiej w razie czego przywracać do życia apke w mikroserwisach niż monolity gdzie jak pada to wszystko...

A tylko przypomnę, że istnieje taki Erlang/Elixir, gdzie mimo że aplikacja może być niby-monolityczna, a jednocześnie odizolowana na (nie systemowe) "procesy" które są stworzone do niezależnego padania i płynnego wstawania bez ubijania całości - a wszystko bez stawiania osobnych kontenerów z aplikacjami i gadania dziwacznie niewygodnym i wolnym interfejsem IPC jakim jest HTTP.

Szkoda że ta platforma nie jest popularniejsza w "codziennym" webdevie, pewnie w dużym stopniu przez egzotykę języków :c

komentarz 22 lipca 2020 przez reaktywny Nałogowiec (41,090 p.)

Nie tylko egzotykę języków. Ale chyba głównie przez bezwładnosć korporacji i to, że mało dużych firm korzysta z tych rozwiązań (poza WhatsApp i przemysłem telekomunikacyjnym chyba nic więcej dużego nie znajdziesz).
Co cioekawe powstają nowe języki na maszynę BEAM, ostatnio czytałem o dwóch statycznie typowanych: GLEAM i jeszcze jakimś. Facebook też opracowywuje język pod maszynę wirtualną Erlanga, od kilku lat. Być może to będzie przełom.

komentarz 22 lipca 2020 przez Tomek Sochacki Ekspert (227,510 p.)

Nie tylko egzotykę języków. Ale chyba głównie przez bezwładnosć korporacji i to, że mało dużych firm korzysta z tych rozwiązań

duże firmy muszą patrzeć na wiele czynników wybierając rozwiązania technologiczne, a jednym z nich jest łatwość pozyskania z rynku ludzi do pracy... jak zrobisz mikroserwisy w Javie to znacznie łatwiej znajdziesz ludzi niż gdy wybierzesz jakiś egzotyczny język...