Dane z innego mikroserwisu w widoku

Mam mikroserwis A z użytkownikami, w innym mikroserwisie B potrzebuję powiedzmy nazwy użytkownika bo chcę wyświetlić listę obiektów z autorem.
W jaki sposób pobierać autorów? Za każdym żądaniem do B, musiałbym pytać A o odpowiednie nazwy? Albo trzymać w B snapshot użytkowników?

Tak. Snapshot to lepsze rozwiązanie, bo mikroserwisy są bardziej niezależne od siebie i awaria jednego to nie koniec świata. Z drugiej strony ludzie często chcą mieć ciastko (mikroserwisy) i zjeść ciastko (brak redundancji)

Oczywiście rozwiazaniem jest też monolit lub mniejsza granulacja

Tylko w przypadku snapshota masz kwestię jego aktualności. Albo zakładasz, że jest odświeżany co jakiś czas i bierzesz na klatę, że mogą się pojawić lekkie rozjazdy, albo robisz na bieżąco aktualizowanie przy każdej zmianie. Ale to po pierwsze - może się rozjechać, jeśli komunikacja padnie, albo drugi mikroserwis się wyłoży, to jedziesz na kopii, która może być niekatualna. A po drugie - wtedy wymaga każda zmiana przesłania info o aktualizacji. I teraz masz do zastanowienia się (nie znam twojego scenariusza, więc ciężko jednoznacznie ocenić) co jest większym problemem/kompiikacją/generuje większe obciążenie - czasami odpytanie drugiego serwisu o dane użytkownika (albo inne dane, które będą potrzebne) czy częste przesyłanie notyfikacji o zmianie/aktualizowanie i synchronizowanie baz między sobą. Pytanie jest takie - co się dzieje częściej oraz która operacja jest bardziej obciążająca.

My tego nie wiemy, więc ciężko jest to ocenić.

Jeszcze przyszła mi do głowy inna opcja - to, co ma być wspólne, trzymać w osobnym serwisie. Wtedy nie trzeba niczego synchronizować: serwis A ma dane (np. o zamówieniach), serwis B ma inne (np. dot. płatności), a dane wspólne trzymamy w serwisie C. Tylko w takim rozwiązaniu to w wypadku padnięcia C, A i B także leżą. Tak czy siak - nie znając szczegółów, ciężko coś więcej sensownego powiedzieć. Aczkolwiek w kontekście mikroserwisów niekoniecznie to jest dobra porada, bo tutaj priorytetem jest ich niezależność i samodzielność, także raczej bym szedł w trzymanie kopii danych z serwisu A na B oraz jakiś sensowny system synchronizacji/powiadomień o zmianach tych danych i ewentualnie plan awaryjny w wypadku niedostępności serwisu A. Nie wiem na ile to sa kluczowe dane, czy jeśli podstawisz coś nieaktualnego to będzie problem. W sensie - czy w razie braku możliwości komunikacji, lepszą opcją jest wstawienie danych, których nie jesteś na 100% pewien, czy wstrzymanie się z działaniem i np. pokazanie informacji że chwilowo mamy przerwę techniczną albo coś w tym stylu.

cyclicgraph napisał(a):

Za każdym żądaniem do B, musiałbym pytać A o odpowiednie nazwy? Albo trzymać w B snapshot użytkowników?

No tak, nie masz innej opcji. Takie działanie w zasadzie dostajesz z samej definicji mikroserwisów.

Jeśli Ci to nie pasuje, to trzeba by się zastanowić czy faktycznie potrzebujesz mikroserwisów?

to co powiedzieli poprzednicy plus jest jeszcze opcja snapshotowania tylko tego co aktualnie się potrzebuje czyli jakieś cache mniej lub bardziej wbudowane. W zasadzie wszystko zależy od tego jak dużo jest requestów i jak często dane się zmieniają. BTW jeśli masz mikroserwisy w tej samej lokalizacji i nie strzelasz cały czas o to samo i nie prowadzisz skomplikowanych analiz to właśnie request do drugiego mikroservicu jest domyślnym standardowym rozwiązaniem. Dopiero jak zaczynają się problemy wydajnościowe to się myśli nad innymi rozwiązaniami

Zawsze możesz mieć orkiestrator serwis C co ogarnie między A i B

Skoro potrzebujesz przy obiekcie informacji o autorze, to być może odpowiedź z B jest zbyt uboga i lista obiektów nie zawiera danych potrzebnych do prezentacji.
W efekcie B musi dopytywać A przy każdym żądaniu / utrzymywać lokalny snapshot, co może sugerować, że granica odpowiedzialności albo model odczytu nie są dobrze zaprojektowane.

To tak jakbym wyciągał fakturę i dla pozycji zamówienia chciałbym sięgnąć do katalogu produktów (po jakimś identyfikatorze), żeby zobaczyć jaki kolor ma np. zamówiony samochód.
Po co miałbym to robić? Spróbuj się zastnaowić czy na etapie tworzenia obiektów, nie da się tej informacji przekazywać w ramach realizowanego procesu, tak żeby nie było później potrzeby sięgania do serwisu A (mimo, że technicznie źródłem tej informacji może być serwis A).

No ale to zależy od tego jaki jest cel. Jeśli użytkownik ma zawsze widzieć najświeższe dane, to snapshot raczej odpada, trzeba albo odpytywać bezpośrednio (oby tylko nie o każdego oddzielnie), albo zrobić gateway czy tam serwis c, który by odpytywał.

W zasadzie to najczęściej robi się snapshot, bo tu chodzi o niezawodność i odporność na awarie, jeśli cel jest inny to są lepsze podejścia niż mikroserwisy.

Tak btw, dziwi mnie trochę te parcie na rozproszenie, za wszelką cenę bo to modne, na siłę. Są scenariusze, gdzie monolit sprawdzi się lepiej, a sztuczny podział ma mikroserwisy tylko komplikuje niepotrzebnie architekturę

Jeśli priorytet to zawsze najświeższe dane to lepszy będzie monolit modularny, a nawet klasyczny zwykły monolit po prostu.