• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Mikroserwisy / mikrousługi

Object Storage Arubacloud
0 głosów
340 wizyt
pytanie zadane 20 października 2023 w Inne języki przez reaktywny Nałogowiec (41,240 p.)
Nigdy nie zagłębiałem się w temat mikroserwisów i moja wiedza na ich temat jest bardzo powierzchowna.

Wiem, że służą one głównie poprawie skalowalności i wydajności serwisu. Ułatwiają też prowadzenie dużych i ogromnych projektów. Chodzi głównie o to żeby obliczenia, obciążenie jednego serwera rozłożyć na więcej  serwerów. I tu moja wiedza się kończy :D

Zakładam, że mamy aplikację web z n mikroserwisami. Rozumiem, że jak każdy taki mały serwis dostanie swój hardware (czy nawet wirtualne rdzenie) to działa szybciej niż jakby działał na jednym serwerze, ale co z bazą danych w takim rozproszonym systemie? Przecież prawie każdy mikroserwis musi mieć dostęp do (chyba) tej samej bazy danych, albo pewnej części wspólnych danych, które są niezbędne w wielu miejscach aplikacji, jak chociażby dane o zalogowanym użytkowniku, który obecnie odwiedza serwis.

Zawsze mówiło się, że wąskim gardłem prawie wszystkich aplikacji web są bazy danych. Operacje na DB są najwolniejsze (zwykle). Skoro większość z n serwisów będzie musiała mieć dostęp do tej samej DB, to czy to nie spowolni znacznie całej aplikacji web (całego "portalu")? Gdzie jest zysk na wydajności w mikroserwisach, skoro DB ma zazwyczaj największy udział w wydłużeniu odpowiedzi na żądania,

4 odpowiedzi

+3 głosów
odpowiedź 21 października 2023 przez marcin99b Szeryf (82,260 p.)
edycja 21 października 2023 przez marcin99b

Wiem, że służą one głównie poprawie skalowalności i wydajności serwisu. Ułatwiają też prowadzenie dużych i ogromnych projektów. Chodzi głównie o to żeby obliczenia, obciążenie jednego serwera rozłożyć na więcej  serwerów. I tu moja wiedza się kończy :D

Służą też poprawie efektywności i samopoczuciu zespołu, dużo prościej jest podbijać wersje bibliotek, języka, frameworka itp, jeśli masz mini aplikacje, niż jak masz wielki korpo monolit, którego samo włączenie trwa mnóstwo czasu i jest wyzwaniem... no i ten czas włączania, pracowałem w systemach w których po każdej zmianie kawałka kodu, musiałem tracić 5 minut na odpalenie systemu, po czym kilka do kilkunastu minut na wyklikanie tego co bym chciał. Nie mówiąc już o buildach w CI trwających wieczność.

Tylko że kluczowe tutaj jest, jak duży byłby nasz monolit, bo niektóre firmy mają całe projekty o rozmiarach pojedynczych mikroserwisów w korporacjach, to w takiej sytuacji nie ma sensu rozdrabnianie się na jeszcze większe mikro kawałki. Mikroserwisem powinien być niezależny obszar biznesowy, a nie wszystko co można nazwać modułem.

Docelowo zespół złożony z kilku programistów, powinien pracować nad jednym lub kilkoma mikroserwisami - niezależnymi projektami utrzymywanymi przez ten zespół.

Zakładam, że mamy aplikację web z n mikroserwisami. Rozumiem, że jak każdy taki mały serwis dostanie swój hardware (czy nawet wirtualne rdzenie) to działa szybciej niż jakby działał na jednym serwerze

Z tą wydajnością to jest jedno wielkie tak i nie, są w systemie obszary które mogą działać wolno i są takie które muszą być szybkie. Przykładowo dodawanie ogłoszeń może trwać kilka sekund, ale wyświetlanie i filtrowanie ich musi być natychmiastowe - taki książkowy przykład. W praktyce trzeba myśleć jeszcze o tym że komunikacja sieciowa zjada sporo mocy, bo trzeba to wszystko zserializować na jsony, przesłać po kablu, odebrać z kabla, przekierować do odpowiedniego sprzętu... po drodze zrobić mnóstwo innych rzeczy, później zdeserializować w docelowym projekcie... to nawet nie brzmi jak coś szybkiego, przekazanie adresu w ram, w ramach jednego procesu, jest dużo wydajniejsze.

W kilku przypadkach można zaoszczędzić na sprzęcie w mniej istotnych obszarach, ale raczej traci się finansowo a nie oszczędza. Ta oszczędność płynie bardziej z pracowników, którzy mają potężne wypłaty - to co napisałem wyżej, mając mikroserwisy dużo zmian da się wprowadzać sprawniej i praca potrafi iść szybciej (pod warunkiem że są dobrze zaprojektowane), zaoszczędzoną kase można władować w mocniejszy sprzęt i jeszcze wyjdzie sie na plus.

ale co z bazą danych w takim rozproszonym systemie

Mikroserwisy powinniśmy traktować jako niezależne produkty, a zespoły jako niezależne firmy, które współpracują ze sobą. Każdy mikroserwis powinien mieć swoją bazę danych, w której tylko on może wprowadzać zmiany. Korzyścią jest to, że jakiś typ z innego zespołu który średnio ogarnia naszą wizje, nie popsuje nam danych. Jeśli zmusimy inne zespoły do tego, żeby korzystały z naszej bazy jedynie za pomocą naszego api, to zawsze będą przechodzić przez nasze walidacje i zawsze dane będą sformatowane w prawidłowy sposób. Łatwiej też będzie zmienić strukture bazy danych, bo już nie używa jej połowa firmy, tylko jeden projekt z jednego zespołu, nie trzeba się martwić o to że rozbijając coś na więcej/mniej tabel, rozwalimy komuś projekt... i wracamy do tego co pisałem wyżej, proste zmiany są proste i nie wymagają wielu miesięcy negocjacji z połową firmy.

komentarz 23 października 2023 przez reaktywny Nałogowiec (41,240 p.)
Dzięki za wpis! Skomplikowana sprawa.
+2 głosów
odpowiedź 21 października 2023 przez kubaapk Nałogowiec (44,270 p.)
Co do baz danych.

Pomijąc wszelkie sprawy wydajnościowe to jeśli masz jedną bazę danych z której korzystają wszystkie mikroserwisy to tracisz główną zaletę - autonomiczność usług i wszystko masz związane poprzez bazę danych - bez sensu i robi Ci się z tego po prostu rozproszony monolit, bo jeśli masz dostęp ze wszystkich usług do jednej i tej samej bazy danych to prędzej czy później zaczną się haki przez sql i fajrant. Każdy mikroserwis powinen mieć w sobie wszystko co jest mu potrzebne do prawidłowego działania, dane które są mu potrzebne to albo pobiera przez publiczne api z innego serwisu (i później możesz to sobie cachować jeśli jest taka możliwość) albo integrujesz się poprzez zdarzenia i kolejki i aktualizujesz dane lokalnie w serwisie (tutaj poczytaj o eventual consistency). Generalnie shared database jest takie se, jak już to chociaż warto jakoś to logicznie odseparować poprzez schemy, żeby później można to było łatwo wyciągnąć.

A co do autoryzacji i uwierzytelniania to możesz to sobie ograć centralnie poprzez API Gateway i sprawdzasz tam sobie polityki czy inne credentiale i dopiero później puszczasz ruch do usług niżej, możesz też uwierzytelniać się na poziomie każdej z usług osobno, no to zależy jakie są wymagania.
komentarz 23 października 2023 przez reaktywny Nałogowiec (41,240 p.)
Dzięki za wpis! Widać, ze siedzisz w temacie.
+2 głosów
odpowiedź 21 października 2023 przez Ehlert Ekspert (213,090 p.)

Skalowalność można uzyskać bez mikroserwisów. Separuje się daną część i możesz ją uruchamiać niezależnie w tylu instancjach, ilu potrzebujesz. Taki worker może komunikować się z monolitem przez bazę danych, kolejkę itp.

Architektura mikroserwisów mamy kiedy poszczególne elementy systemu są niezależnymi jednostkami wdrożeniowymi i posiadają wartość biznesową, a nie tylko techniczną.

Poza tym mikroserwisy niosą za sobą mnóstwo wyzwań:

  • Service Discovery
  • Całkowita automatyzacja (IaaC) 
  • Rozproszona autoryzacja
  • Komunikacja asynchroniczna
  • Eventual consistency
  • Podział odpowiedzialności tak aby nie spotkać się z problemem rozproszonych transakcji
  • Odpowiedni podział zespołów

 

1
komentarz 23 października 2023 przez reaktywny Nałogowiec (41,240 p.)
Dzięki za wpis! Te kilka dodatkowych punktów jeszcze bardziej uświadomiło mi, że to nie jest trywialny temat. Dzięki!
+1 głos
odpowiedź 20 października 2023 przez jankustosz1 Nałogowiec (35,940 p.)
Wyobraź sobie, że masz aplikację monolityczną, bez żadnych dodatkowych mikroserwisów. Na początku może wydawać się to rozwiązanie idealne i pewnie takie będzie, ale z czasem zacznie wychodzić wiele problemów.

1) Kod napisany w aplikacji jest mało modułowy. Chcesz zrobić aplikację korzystającą z części operacji wykonywanych przez monolit. Musisz w takim przypadku zrobić pod tą aplikację dedykowane endpointy które będzie trzeba utrzymywać. Zaśmieca się trochę przez to kod. Pisząc modułowe mikroserwisy kod jest dużo bardziej schludny i lepiej spełnia zasady SOLID np. otwarty na rozszerzenia, zamknięty na modyfikacje.
2) W końcu serwis będzie na tyle duży, że skalowanie go vertykalnie będzie coraz trudniejsze. Nie dostawisz chyba drugiego procesora do komputera. Dużo taniej i efektywniej jest skalować horyzontalnie (dostawiając kolejne komputery)
3) Co do bazy danych to rzeczywiście są z tym różne problemy. Podobno bazy danych nierelacyjne np. MongoDB dużo łatwiej jest skalować horyzontalnie. W przypadku baz SQL też się da, ale jest to dużo trudniejsze. Musisz podzielić dane na jakieś części. Np. na jednym serwerze trzymasz tylko klientów do literki 'K', a na drugim od literki 'L', albo np. ze względu na region. Możliwe że mówię tutaj bzdury, więc jak ktoś wie lepiej to niech mnie poprawi
komentarz 20 października 2023 przez reaktywny Nałogowiec (41,240 p.)

Odnośnie baz danych (bo to było moje główne pytanie), chodzi mi o to, że jak zarejestruje się nowy użytkownik lub skasujemy użytkownika (to są tylko przykłady), to wiele mikroserwisów (modułów) musi o tym wiedzieć, a żeby wiedziały o tym fakcie muszą korzystać z jednej DB, albo mieć swoją bazę przypisaną do pojedynczego modułu, ale wtedy informacje o nowym użytkowniku (czy skasowaniu, modyfikacji danych etc. użytkownika) trzeba rozprowadzić do wszystkich baz danych, które tych danych potrzebują do działania. To nie tylko komplikuje cały projekt, ale też wprowadza sporo dodatkowego ruchu wewnętrznego.

To co piszesz to chyba bardziej pasuje do koncepcji load balancing, czyli podziału ruchu / obciążenia serwera na większą liczbę serwerów pracujących niezależnie, a mniej do architektury mikroserwisów (??).

komentarz 22 października 2023 przez jankustosz1 Nałogowiec (35,940 p.)

Jak jeden serwer nie wyrabia można zrobić np. 3 taki same i wystawić load balancera który będzie równomiernie rozdzielać requesty na te 3 serwery.

Odnośnie baz danych (bo to było moje główne pytanie), chodzi mi o to, że jak zarejestruje się nowy użytkownik lub skasujemy użytkownika (to są tylko przykłady), to wiele mikroserwisów (modułów) musi o tym wiedzieć, a żeby wiedziały o tym fakcie muszą korzystać z jednej DB

Nie muszą o tym wiedzieć i nie muszą korzystać z tylko jednej DB. Mikroserwisy najlepiej jak są bezstanowe i przy zapytaniach odpytują bazy danych. W tym przypadku, jak jeden mikroserwis usunie z bazy danych, trzymającej użytkowników o nickach zaczynających się od literki 'L' i późniejszych, użytkownika Marcin to inne mikroserwisy jak dostaną zapytanie o Marcina odpytają ten serwer bazy danych i stwierdzą, że on nie istnieje. Dochodzi jeszcze kwestia cachowania, ale to sam nie wiem jak idealnie możnaby rozwiązać.

komentarz 23 października 2023 przez reaktywny Nałogowiec (41,240 p.)
Dzięki za wpis!

Podobne pytania

+1 głos
1 odpowiedź 298 wizyt
pytanie zadane 20 marca 2023 w JavaScript przez icytower Bywalec (2,110 p.)
0 głosów
2 odpowiedzi 501 wizyt
pytanie zadane 9 kwietnia 2022 w PHP przez Piotr Zakrzewski Obywatel (1,260 p.)

92,753 zapytań

141,671 odpowiedzi

320,385 komentarzy

62,100 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...