Skalowanie monolitów vs. skalowanie mikrousług

15

Jednym z typowych argumentów przemawiających za wykorzystaniem mikrousług jest lepsza skalowalność. Ale zastanawiam się, czy ten argument jest naprawdę ważny.

Powiedzmy, że mieliśmy aplikację składającą się z 10 mikrousług, z których 9 ma każde dwa wystąpienia (dla nadmiarowości) i jedno z 4 wystąpieniami do obsługi obciążenia (skalowalność). Argument pro-mikroserwisowy polega na tym, że możesz skalować to miroservice niezależnie od innych usług.

Powiedzmy jednak, że wszystkie 10 mikrousług były modułami w jednym monolicie i że wdrożono kilka (np. 22 jak suma z góry) instancji tego monolitu. System powinien być w stanie poradzić sobie z obciążeniem dla jednej części krytycznej, ponieważ jest wystarczająca liczba takich przypadków. Jeśli instancje zawierają logikę programu, niepotrzebną, jedynym minusem byłoby to, że plik binarny i ilość potrzebnej pamięci RAM byłyby nieco większe. Ale z drugiej strony różnica nie powinna być zbyt duża w większości przypadków - przynajmniej nie w porównaniu z resztą stosu (pomyśl o Spring Boot). Zaletą skalowanego monlitu byłby prostszy system bez (większości) błędów systemu rozproszonego.

Czy coś brakuje?

deamon
źródło
3
Ile mówisz o monolicie? Ponieważ myślę, że może to być coś więcej niż „nieco większa” pamięć RAM. Nie wspominając już o czasie wdrażania - usunięcie błędu może zająć 22 wdrożenia zamiast 4. Ale może twój monolit jest mały i wdrożenia nie zajmują dużo czasu, migracje baz danych nie zajmują dużo czasu i tak dalej.
Thomas Owens
Nie liczyłem linii kodu, ale monolit miałby kilka tysięcy linii kodu (nie gigantyczny system). Punktem wyjścia do rozważań było to, że rozmiar rzeczywistego kodu aplikacji jest niewielki w porównaniu do dużych frameworków, takich jak Spring i Hibernacja. Liczba wdrożeń może być mniejsza niż w przypadku mikrousług, ponieważ gdybyś miał 2 instancje, miałbyś już podstawową redundancję, a więcej byłoby skalowalności.
deamon
@deamon Należy pamiętać, że przy metodzie monolitycznej nie ma części kodu, które są całkowicie martwe w każdej instancji, tylko rzadko używany kod. Teraz sam kod może zużywać tylko niewielką ilość pamięci, ale jeśli używa wielu obiektów buforowanych w pamięci, ilość ta może znacznie wzrosnąć.
Frank Hopkins,
Zwróć uwagę, że narzut podstawowy związany z „uruchamianiem kodu” niekoniecznie jest tak duży, jak możesz to wiedzieć z aplikacji Java, w których często cały plik JVM jest częścią obrazu usługi.
Frank Hopkins,

Odpowiedzi:

21

Celem mikrousług nie jest zmniejszenie obciążenia procesora. W rzeczywistości z powodu narzutu związanego z komunikacją i powtarzaniem funkcji, które kiedyś były globalnym kodem narzędziowym, zwykle nieco zwiększa obciążenie procesora.

Celem zniesienia monolitu jest o wiele więcej, aby móc w ogóle utrzymać, wdrożyć i uruchomić złożony system funkcjonalności . Gdy twój system osiągnie określony rozmiar, kompilowanie, testowanie, wdrażanie itp., Monolit staje się po prostu zbyt drogi, aby był wykonalny przy zachowaniu przyzwoitej dostępności. Za pomocą mikrousług można uaktualnić, ponownie uruchomić lub przywrócić system fragmentaryczny.

Nie pomylcie się, nie piszemy mikrousług, ponieważ z natury jest to lepsze rozwiązanie luźnego parowania rzeczy na zdalnych interfejsach. W rzeczywistości utrata silnego typu i sprawdzanie spójności, które mógłby zapewnić monolit, jest często poważną wadą. Robimy to, ponieważ musimy, ponieważ złożoność jest lepsza od nas i wykorzystujemy sytuację optymalną.

Kilian Foth
źródło
2
Zgoda. Powód przejścia na architekturę mikrousług jest głównie polityczny. Obciążenie rozproszone, oddzielenie jest konsekwencją, a nie przyczyną. Prawdziwą korzyścią z mikrousług jest SDLC i zarządzanie. Ponadto architektura jest logiczną odpowiedzią na potrzebę, która w większości przypadków wynika ze strategii rynkowej firmy. Czas wprowadzenia produktu na rynek jest krótszy niż architektura monolityczna, więc firma może przyjmować nowe strategie, płynnie i szybko przechodzić od jednej do drugiej
Laiv
6
Dlatego ktoś nie powinien przejść bezpośrednio do mikrousług dla średnich i małych aplikacji. Narzuty i dodatkowa złożoność systemu mogą bardzo dobrze kosztować więcej czasu, pieniędzy i jakości niż system monolityczny w tych skalach.
T. Sar
»Robimy to, ponieważ musimy, ponieważ złożoność jest lepsza od nas i wykorzystujemy sytuację nieoptymalną.« Tak. Dla mnie to gwoździe!
Thomas Junk
Muszę się nie zgodzić z ostatnią częścią odpowiedzi. mikrousług są z natury lepsze niż monolit, ponieważ wykorzystują więcej niż jeden komputer
Ewan
1
@ewan Możesz używać więcej niż jednego komputera z monolitami.
deamon
3

Masz w większości rację. Jeśli masz szybkie usługi, które są ładowane równo, równie dobrze możesz zainstalować je wszystkie na wszystkich urządzeniach. To nie jest tak „miłe” jak posiadanie pudełka na usługę, ale oszczędza pieniądze.

Jednak. gdy tylko pojawi się brak równowagi, powiedzmy, że usługa 5 zajmuje 100% procesora przez 2 minuty, chcesz przenieść tę usługę do własnego pudełka, aby nie blokowała wszystkich innych usług, jeśli jest uruchomiona.

Jeśli połączenia z serwisem 5 przekroczą limit czasu z powodu obciążenia, tylko niektóre funkcje aplikacji zawiodą zamiast wszystkich.

Teraz możesz zrobić to samo z dobrze zmodularyzowanym monolitem. Zainstaluj wszystkie usługi, ale tylko kieruj ruchem usługi 5 do jednej z nich. Podczas gdy usługa nie kieruje ruchu 5 do innych skrzynek.

Ale zwykle monolity ze swej natury nie są luźną kolekcją usług, które są instalowane na tym samym urządzeniu. Będą w pamięci wywołania między modułami, które spowodują awarię aplikacji.

Ewan
źródło
1

Istotą mikrousług są 1) rozdzielenie problemów i 2) rozłożenie obciążenia. Zasadniczo uwalnia nas to do stworzenia najlepszej usługi w czarnej skrzynce z technologiami specyficznymi dla tego zadania. Nasze usługi mogą być poliglotyczne - to jest napisane w różnych językach programowania na różnych stosach. Różne zespoły mogą pracować nad każdą usługą, nie wiedząc, jak inne działają poza umową dotyczącą interfejsu API. To, ogólnie rzecz biorąc, pozwala na znacznie prostszą bazę kodu dla każdej usługi, która jest łatwiejsza do debugowania, zrozumienia i poprawiania wydajności.

Lewis A Sellers
źródło
Częściowo się zgadzam. Nie chodziło mi o argumenty za mikrousługami w ogóle, ale o skalowalność. W moim konkretnym przypadku wszystkie mikrousługi są napisane na przykład w tej samej technologii. Tak więc chociaż dla każdej z nich można byłoby zastosować inną technologię, po prostu tak nie jest. Chciałem sprawdzić, czy nie umknie mi ważny punkt dotyczący skalowalności.
deamon