Architektura mikroserwisów sugeruje, że każda usługa powinna obsługiwać własne dane. Stąd każda usługa (usługa A) zależna od danych należących do innych usług (usługa B) powinna uzyskiwać dostęp do takich danych nie poprzez bezpośrednie wywołania DB, lecz poprzez api dostarczone przez drugą usługę (usługa B).Microservices: jak radzić sobie z kluczowymi relacjami obcymi
Co więc najlepsze praktyki mikroserwisów sugerują na temat sprawdzania ograniczeń klucza obcego.
Przykład: Opracowuję funkcję dostawy (mikroserwis 1) dla produktów, a niektóre produkty można dostarczać tylko do niektórych lokalizacji wymienionych w tabeli produktów dostępnej tylko dla produktów mikroserwisowych (mircoservice 2).
Jak upewnić się, że mikroserwis 1 (tzn. Funkcja dostarczania) nie przyjmuje zamówienia do lokalizacji, która nie jest obsługiwana. Mam to pytanie, ponieważ funkcja dostarczania nie może bezpośrednio uzyskać dostępu do bazy danych produktów, więc nie ma ograniczeń obowiązujących na poziomie DB, gdy zamówienie dostawy jest umieszczone w bazie danych dostawy (brak sprawdzenia, czy istnieje możliwość znalezienia klucza obcego w bazie danych produktów lub tabela).
Wielką odpowiedź. Korzystam z wywołań interfejsu API, ale wymaga też sortowania i dzielenia stron na strony danych z innej usługi. Czy znasz najlepsze podejście do tej sprawy? – tranceholic
Powinieneś dodać parametry związane z stronicowaniem i sortowaniem do api. Wtedy odpowiedzialność za uzyskanie właściwej strony z właściwą kolejnością będzie podejmowana przez konsumentów api. Istnieją pewne technologie używane do definiowania API takiego jak GraphQL. O ile mi wiadomo, te technologie mają już funkcje sortowania i stronicowania. Jeśli nie korzystasz z tego rodzaju technologii, możesz po prostu pobrać parametry od klienta i użyć ich do zwrócenia danych posortowanych na stronach. –