[Patres]

#programowanie #mikroserwisy #java
Czy jak w projekcie używacie mikroserwisów to czy każdy z nich ma osobną bazę danych? Słyszałem, że tak to powinno wyglądać, ale nie bardzo potrafię sobie wyobrazić w jaki sposób ma to działa jak mikroserwisy są w jakimś tam stopniu ze sobą powiązane. Na przykład:

1. Jeden serwis odpowiedzialny za płatności, a druga za zamówienia. Ale w zamówieniach mam relacje do płatności, więc w zamówieniach będę miał tabele ORDERTAB i kolumnie PAYMENTID bez klucza obcego? Bo mikroserwis payment jest odpowiedzialny za płatności więc w osobnej bazie danych mam tabele PAYMENTTAB.
2. Mam aplikację do generowania planu lekcji. Większość aplikacji opiera się na dodawaniu nauczycieli, sal itp. oraz na wyświetlaniu tego planu. Jednak generowanie planu lekcji jest bardzo zasobożerne, więc wydzielam z tego mikroserwis i odpowiednia to skaluje. To jak mam stworzyć osobną bazę danych do takiego mikroserwisu. I tu i tu muszę mieć tabele TEACHERTAB itp.

tl;dr Czy faktycznie stosuje się zawsze osobną bazę danych per mikroserwis? Rozumiem, że w serwisach które nie są ze sobą połączone domenowo jest to logiczne, ale co w takich przypadkach jak powyżej?

[Priya]

@Patres:
1. Tak, można użyć jakiegoś globalnego identyfikatora.
2. Tak, ale nie będą mieć takich samych danych, bo działają w innym kontekście. Przykładowo tabela 'Teacher' w serwisie do generowania planu lekcji będzie miała identyfikator i jakieś godziny dostępności, a w drugiej tabeli będzie ten sam identyfikator i jego dane personalne, kontaktowe itp.

Jak mikroserwisy współdzielą te same źródło danych, to masz do czynienia zwykle z big-ball-of-mud i ktoś źle wydzielił

[repostuje]

Czy jak w projekcie używacie mikroserwisów to czy każdy z nich ma osobną bazę danych? Słyszałem, że tak to powinno wyglądać, ale nie bardzo potrafię sobie wyobrazić w jaki sposób ma to działa jak mikroserwisy są w jakimś tam stopniu ze sobą powiązane. Na przykład:

@Patres: są różne podejścia i każde ma swoje wady i zalety. Decyzja o sposobie podzielenia storage (czy to bazy danych, czy storage blokowego czy nosql) nie

[j.....6]

Jak mikroserwisy współdzielą te same źródło danych, to masz do czynienia zwykle z big-ball-of-mud i ktoś źle wydzielił granice takich serwisów.

@Priya: Możesz to rozwinąć?

[Saly]

Możesz to rozwinąć?

@jaca_66: bazy są problematyczne dlatego logikę najczęściej dzieli się pomiędzy serwis a bazę w taki sposób, żeby było najwygodniej. Jak chcesz, żeby baza była używana przez wiele serwisów to musisz dużą część logiki umieścić w bazie, żeby żaden serwis niczego nie popsuł. Pisanie logiki w bazie pod postacią triggerów i procedur jest bardzo upierdliwe (upierdliwy SQL, słaba testowalność, wersjonowanie, cachowanie) i większość ludzi, która spotkała się z

[Priya]

@jaca_66: Jeżeli dwa serwisy współdzielą to samo źródło danych to:
- mają ukrytą zależność, którą jest baza danych. Rodzi to problemy w przypadku deploymentu: w idealnym rozwiązaniu serwisy powinny móc być deployowane niezależnie. Jeżeli współdzielą bazę i zmienię schemat, to musze w tym samym czasie podbić wersję w innym serwisie, żeby korzystał z nowego schematu.
- Wspólna baza danych może ograniczać skalowalność
- Jeżeli dwa serwisy współdzielą te same dane,

[Patres]

@Priya:

2. Tak, ale nie będą mieć takich samych danych, bo działają w innym kontekście. Przykładowo tabela 'Teacher' w serwisie do generowania planu lekcji będzie miała identyfikator i jakieś godziny dostępności, a w drugiej tabeli będzie ten sam identyfikator i jego dane personalne, kontaktowe itp.

Jak mikroserwisy współdzielą te same źródło danych, to masz do czynienia zwykle z big-ball-of-mud i ktoś źle wydzielił granice takich serwisów.

Dzięki! Tylko w tym

[j.....6]

@Saly: @Priya: @Patres: dzieki!!

[Priya]

@Patres: ten współdzielony identyfikator nie może być oparty o sekwencyjnosc, najczęściej się jakiegoś uuid uzywa. Zapisując dane w jednym serwisie musisz mieć gwarancję, że zostaną też zapisane dane w innym serwisie. Można to zrobić bez klucza - poszukaj hasła eventual consistency.