Parent dla mikroserwisów

Parent dla mikroserwisów
Bambo
  • Rejestracja:ponad 10 lat
  • Ostatnio:8 miesięcy
  • Postów:779
0

Cześć. Załóżmy, że mamy dość spory system składający się z 50+ mikroserwisów napisanych w Javie opierających się na Spring Boot.
Czy w takim wypadku powinniśmy dziedziczyć każdy mikroserwis ze spring-boot-starter-parent czy też powinniśmy zrobić osobny projekt "patentowy", który dziedziczy z tego Spring, ale wnosi jakieś wspólne funkcjonalności, które są share'owane między mikroserwisami?

Dlaczego zastanawiam się nad drugą opcją.. bardzo dużo rzeczy dla tych mikroserwisów jest wspólna, jak np te same DTO, auto konfiguracje cache, security, klienty do różnych usług itp. Ponad to dzięki takiemu customowemu patentowi możemy centralnie zarządzać wersjami różnych bibliotek jak np sterownika psql czy czego tam używamy.

Z drugiej strony mikroserwisy powinny być niezależne, a taki wspólny customowy Parent je spina.

Reasumując. Czy taki Parent to dobry pomysł? Ewentualnie gdzie przebiega granica i które elementy powinny być po prostu wyniesione do osobnych, małych bibliotek?

Pozdrawiam

DA
  • Rejestracja:ponad 10 lat
  • Ostatnio:6 dni
  • Postów:176
5

Proponuję posiadanie jak najmniej wspólnych zależności. Obecnie zakładasz wspólną wersję springa dla wszystkich mikroserwisów. Dlaczego? Jeżeli projekt jest wystarczająco stary, używasz spring boota 2, i nagle wychodzi wersja 3. Podbicie major wersji to nie jest hop siup, jeden mikroserwis może być malutki, a drugi dużo większy, i podbicie wersji może zająć dość długo. Podbijając coś w parencie masz zatem dużą szansę na breaking changes w child projektach. Nie podbijając, blokujesz gotowe mikroserwisy. Niech każdy mikroserwis zarządza sam sobą.

Do DTOsów często stosuje się jeszcze osobne repozytorium, które może być publikowane jako osobny artefakt, i importowany przez zainteresowane serwisy. Security tak samo, osobna biblioteka.

Nie widzę potrzeby centralnego sterowania wersją psql - każdy mikroserwis i tak powinien mieć swoją osobną bazę danych. Niech jeden korzysta z Postgresa 9.6, a drugi z 9.7 - w czym problem? Trzeci może w ogóle nie potrzebować relacyjnego SQLa, a np MongoDB.

Im mniej zależności masz, tym lepiej. Polecam używanie renovate bota, który periodycznie wrzuca pull requesty z podbijaniem wersji bibliotek do najnowszych - to jest jeden z łatwiejszych patternów na zapewnienie "świeżości" zależności w projekcie. A każdy mikroserwis/zespół już niech zarządza swoimi zależnościami osobno.

ZI
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 9 godzin
  • Postów:230
6

Czyli macie mikroserwisy i chcecie z tego zrobic rozproszony monolit. Kciuk w gore =)

edytowany 1x, ostatnio: Ziemiak
PI
  • Rejestracja:ponad 9 lat
  • Ostatnio:4 miesiące
  • Postów:2787
0

Po prostu jakiś wydzielony projekt core z konfiguracjami oraz wydzielony projekt base-api z DTOsami i każdy z projektów (jeśli potrzebuje) ma zależność do tych projektów.

RequiredNickname
  • Rejestracja:prawie 5 lat
  • Ostatnio:około godziny
  • Postów:620
0

Kojarzę, że allegro stosuje takie podejście współdzielenia pewnych rzeczy między usługami z możliwością ich zastąpienia jeżeli zespół tak zadecyduje ale niestety nie mam linku do żadnego artykułu bo słyszałem o tym w ich podcaście ale myślę, że to dobry punkt zaczepienia by podrążyć a może nawet zagadać do jakiegoś tl'a na linkedin i podpytać o szczególy.

KE
Nabrdalik wspominał o tym tutaj (swoją drogą świetna prezentacja): https://www.youtube.com/watch?v=EnNXLNZe4nY - w skrócie - rób biblioteki, ale muszą być wersjonowane i nie mogą stać się wspólną zależnością.
RequiredNickname
oo spoko nie widziałem tego ;)
SL
  • Rejestracja:około 7 lat
  • Ostatnio:około 7 godzin
  • Postów:900
0

Jest ok, jeśli zaprojektujesz wszystko tak, że deploy jednego serwisu nie wymaga koordynacji pomiędzy resztą serwisów. Niezależność nie musi być na poziomie kodu, ale bez niezależnego kodu jest dużo prościej zaliczyć wtopę

Tak czy owak taki super lib, który zawiera wszystko to zły pomysł. Ciężko wersjonować takie coś np. wydasz v2 biblioteki do obsługi bazy danych. Jeśli to wszystko jest w jednej bibliotece to nie jesteś w stanie przemigrować tylko część serwisów. Dużo lepiej jest zrobić osobną bibliotekę do każdego odzielnnego kontekstu

CO
  • Rejestracja:prawie 5 lat
  • Ostatnio:około 6 godzin
  • Postów:628
1
Bambo napisał(a):

Cześć. Załóżmy, że mamy dość spory system składający się z 50+ mikroserwisów napisanych w Javie opierających się na Spring Boot.
Czy w takim wypadku powinniśmy dziedziczyć każdy mikroserwis ze spring-boot-starter-parent czy też powinniśmy zrobić osobny projekt "patentowy", który dziedziczy z tego Spring, ale wnosi jakieś wspólne funkcjonalności, które są share'owane między mikroserwisami?

Dlaczego zastanawiam się nad drugą opcją.. bardzo dużo rzeczy dla tych mikroserwisów jest wspólna, jak np te same DTO, auto konfiguracje cache, security, klienty do różnych usług itp. Ponad to dzięki takiemu customowemu patentowi możemy centralnie zarządzać wersjami różnych bibliotek jak np sterownika psql czy czego tam używamy.

Z drugiej strony mikroserwisy powinny być niezależne, a taki wspólny customowy Parent je spina.

Reasumując. Czy taki Parent to dobry pomysł? Ewentualnie gdzie przebiega granica i które elementy powinny być po prostu wyniesione do osobnych, małych bibliotek?

Pozdrawiam

A czemu nie jakaś biblioteka na zasadzie dependencji? Stworzyć jakiś projekt javy, nazwać project-name-shared, wrzucić tam DTO, wspólne beany i dołączyć do każdego projektu tą bibliotekę? Bez ruszania spring-boot-parent, ta biblioteka nie powinna byc parantem tylko po prostu zależnością, której używa każdy mikroserwis

edytowany 1x, ostatnio: CoderOne
MA
z tym trzeba uważać, nie jest pożądane takie pzesadne dążenie do uwspólniania kodu. Dlaczego? zobacz tu: https://phauer.com/2016/dont-share-libraries-among-microservices/
CO
@marlukk: moim zdaniem nie ma jednego sensownego podejścia. Tu gdzie pracuje mikroserwisie są połączone kilkoma bibliotekami i nie ma z tym problemu. Z tym że te biblioteki są maksymalnie małe i zawierają rzeczy, które raczej się nie zmieniają. Jak ktoś pakuje wszystko do bibliotek to to może być spory problem, dopóki te libki są małe to moim zdaniem jest ok
CO
Dlatego np dto czy niektóre beanu spoko, ale jakieś tam wspólne wersję postgressa to do biblioteki się nie nadaje
MA
gdzieś widziałem chyba Nabrdalika który mówił, że jak w mikroserwisach chcesz coś nazwać "shared" to to już jest powód żebyś tego nie robił
Black007
  • Rejestracja:ponad 21 lat
  • Ostatnio:około 12 godzin
0

Ze swojego doświadczenia powiem że nie warto.
W byłej firmie mieliśmy takie "shared" komponenty i to same problemy.
Mieliśmy jeden model, po którym dziedziczyły modele konkretnych serwisów.
Teraz każda zmiana w tej bibliotece, pociągła za sobą konieczność podbijania jej wersji we wszystkich repozytoriach.
Generalnie w tym momencie masz mikro serwis ze wszystkimi jego "ułomnościami" i bez ani jednego "bonusu" za jego używanie


"Nie popełnia błędów tylko ten, kto nic nie robi"
CO
no ale to nie dbacie o kompatybilność wsteczną? ja też mam mikroserwisy z shared komponentami i zawsze robiło się po prostu wersjonowanie, czyli tymczasowa duplikacja kodu i przykladowo nowy model V2 z naniesionymi zmianami, po miesiącu gdy już model V1 nie był nigdzie używany to bezpiecznie kasowano go z kodu
Black007
Dbaliśmy i to było piekło
SL
  • Rejestracja:około 7 lat
  • Ostatnio:około 7 godzin
  • Postów:900
0
Black007 napisał(a):

Ze swojego doświadczenia powiem że nie warto.
W byłej firmie mieliśmy takie "shared" komponenty i to same problemy.
Mieliśmy jeden model, po którym dziedziczyły modele konkretnych serwisów.
Teraz każda zmiana w tej bibliotece, pociągła za sobą konieczność podbijania jej wersji we wszystkich repozytoriach.
Generalnie w tym momencie masz mikro serwis ze wszystkimi jego "ułomnościami" i bez ani jednego "bonusu" za jego używanie

Wystarczy:

  • zwiększyć granulację bibliotek, żeby zminimalizować konieczność podbijania wersji
  • programować z głową, projektować rozszerzalny kod, na pewno nie wspólny model do dziedziczenia, bo dziedziczenie to największe powiązanie pomiędzy dwiema klasami

Do takiego stylu programowania trzeba programistów, którzy umieją into programowanie bibliotek. Niestety wiele osób nigdy nie miało doświadczenia z pisaniem tego typu kodu i wychodzą takie kwiatki

W takim stylu programowania pomaga też monorepo, bo po samym diffie idzie ogarnąć, czy zmiana nie wywraca całego świata do góry nogami

edytowany 2x, ostatnio: slsy
Riddle
Administrator
  • Rejestracja:prawie 15 lat
  • Ostatnio:3 minuty
  • Lokalizacja:Koszalin
  • Postów:10094
2
Bambo napisał(a):

Cześć. Załóżmy, że mamy dość spory system składający się z 50+ mikroserwisów napisanych w Javie opierających się na Spring Boot.
Czy w takim wypadku powinniśmy dziedziczyć każdy mikroserwis ze spring-boot-starter-parent czy też powinniśmy zrobić osobny projekt "patentowy", który dziedziczy z tego Spring, ale wnosi jakieś wspólne funkcjonalności, które są share'owane między mikroserwisami?

Nie ma to jak stworzyć mikroserwisy, żeby były niezależne od siebie; a potem dodac do nich zależność z dziedziczeniem (czyli najsilniejszą jaka jest).

To po co te mikroserwisy w ogóle?

edytowany 1x, ostatnio: Riddle
ZI
Ciekawe jak w to teraz AI wplatac bo tez modne :D Moze zeby AI zarzadzalo tymi wersjami bibliotek?
piotrpo
  • Rejestracja:ponad 7 lat
  • Ostatnio:17 dni
  • Postów:3277
1

Pomijając kwestie ideologiczne jak bardzo i w jaki sposób jeden mikroserwis powinien być niezależny od drugiego, to copy paste paru plików to max godzina roboty na sztukę, a rozwiązywanie problemów związanych z tymi splątaniami może zająć tygodnie.

ZI
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 9 godzin
  • Postów:230
1
slsy napisał(a):
  • zwiększyć granulację bibliotek, żeby zminimalizować konieczność podbijania wersji

Poszedlbym krok dalej i zwiekszyl granulacje do poziomu ze kazdy mikroserwis ma swoja i problem rozwiazany. Skoro juz idzie sie w mikroserwisy to robmy mikroserwisy a nie badziew gorszy od monolitu

Riddle
Administrator
  • Rejestracja:prawie 15 lat
  • Ostatnio:3 minuty
  • Lokalizacja:Koszalin
  • Postów:10094
2

Jeśli znajdujesz się w sytuacji, że mikroserwisy mają tyle wspólnych części, że potrzebujesz je wydzielać do "commonsów" to tak na prawdę to nigdy nie były mikroserwisy, tylko monolit pod przykrywką.

edytowany 1x, ostatnio: Riddle
marian pazdzioch
  • Rejestracja:ponad 6 lat
  • Ostatnio:29 minut
  • Postów:739
1

Pracuję przy gigantycznej odziedziczonej Java kobyle która ma dokładnie taki setup jak opisałeś.

Czyli: super-projekt (super w sensie Java dziedziczenia, nie jest on super) z którego wychodzą child-mikroserwisy... nawet nazwa się zgadza bo ma w sobie człon "starter".

Dokładnie też do tego jest użyty też: "możemy centralnie zarządzać wersjami różnych bibliotek jak np sterownika psql czy czego tam używamy".

Nie twierdzę że to jest dobre podejście, po prostu widzę że świat Javy już do takiego doszedł lata temu.

edytowany 2x, ostatnio: marian pazdzioch
Riddle
Administrator
  • Rejestracja:prawie 15 lat
  • Ostatnio:3 minuty
  • Lokalizacja:Koszalin
  • Postów:10094
0
marian pazdzioch napisał(a):

Pracuję przy gigantycznej odziedziczonej Java kobyle która ma dokładnie taki setup jak opisałeś.

Czyli: super-projekt (super w sensie Java dziedziczenia, nie jest on super) z którego wychodzą child-mikroserwisy... nawet nazwa się zgadza bo ma w sobie człon "starter".

Dokładnie też do tego jest użyty też: "możemy centralnie zarządzać wersjami różnych bibliotek jak np sterownika psql czy czego tam używamy".

Nie twierdzę że to jest dobre podejście, po prostu widzę że świat Javy już do takiego doszedł lata temu.

Tylko że to nie ma sensu, bo cały powód dodania mikroserwisów jest taki że mają być jaknajmniej zależne od siebie :D

marian pazdzioch
Ty, jaki sens ma cytowanie całego mojego posta jak pisze ZARAZ pod moim?
Potat0x
  • Rejestracja:ponad 8 lat
  • Ostatnio:19 dni
  • Postów:370
0

Skoro jest tyle mikroserwisów, to pewnie mają jakiś wspólny kod związany z samą "infrastrukturą" (mam tu na myśli np. service discovery), który można by wydzielić do wspólnej parenta i myślę, że to jest ok. To przecież nie wprowadza wzajemnych zależności pomiędzy serwisami, a zmniejszy ilość kodu do utrzymania.

Jednak jeśli chodzi pakowanie do takiego parenta rzeczy typu DTO lub centralnie sterowanie wersjami bibliotek, to unikałbym.

edytowany 1x, ostatnio: Potat0x
KE
  • Rejestracja:ponad 6 lat
  • Ostatnio:około 2 godziny
  • Postów:684
4

Wspólny parent (jeśli mówimy o Mavenie) może być dobrym rozwiązaniem, ale tylko wtedy, jeśli serwisy bazujące na jego różnych wersjach nadal są niezależne.

Przykład: w parencie mamy ważną libkę w wersji 1. Wychodzi wersja 2 - prosta sprawa - wydajemy nową wersję parenta, w systemie nie ma prawa się nic zmienić, dalej wszystkie serwisy korzystają ze starego. Później bierzemy jeden serwis i podbijamy parenta do nowej wersji, lecimy z testami, wdrażamy tylko to. Cały system powinien nadal działać.

Więc to nie jest tak, że podbicie w parencie natychmiast wymusza aktualizacje w każdym projekcie, no chyba że ktoś leci na prodzie na snapshotach i latestach, ale to jest sam sobie winien :P

PR
  • Rejestracja:prawie 4 lata
  • Ostatnio:około 5 godzin
  • Postów:222
0

Parent taki jak mówi @kelog i dodatkowo aktualny template, każdy zespół nie będzie chciał rozwiązywać tych samych problemów od nowa.

KE
  • Rejestracja:ponad 6 lat
  • Ostatnio:około 2 godziny
  • Postów:684
0
Productionserver napisał(a):

Parent taki jak mówi @kelog i dodatkowo aktualny template, każdy zespół nie będzie chciał rozwiązywać tych samych problemów od nowa.

W takim parencie (dalej idąc przykładem Mavena i Springa) fajnie jakby się znalazły:

  • zależności "oczywiste" typu podstawowy Spring, jakieś commonsy, lomboki, junity etc.
  • zależności do infrastruktury, typu libki do Postgresa, Kafki, chmury etc. plus ich domyślne konfiguracje (czyli np. baza domyślnie na localhost:5432/nazwa_projektu)
  • bardzo podstawowe configi powyższych, czyli np. endpointy do metryk, domyślne pule wątków do weba i baz, pattern logowania, konfigi tracingu czy zipkina etc.

Tylko tak jak pisałem, to wszystko każdy mikroserwis może wciągnąć i np. wyexcludować sobie coś, jak mu nie pasuje. Dalej są niezależne. W ogóle serwis nie musi używać tego parenta, ale wtedy zespół jest odpowiedzialny za swoje samoróbki :)

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.