Skalowanie monolitów vs. skalowanie mikrousług

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?

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ą.

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.

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.