2017-07-02 89 views
13

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).

Odpowiedz

8

Możliwe jest korzystanie ze wspólnej bazy danych dla wielu mikrousług. Możesz znaleźć wzorce zarządzania danymi mikroserwisów pod tym linkiem: http://microservices.io/patterns/data/database-per-service.html. Przy okazji jest to bardzo przydatny blog dla architektury mikroserwisów.

W twoim przypadku wolisz używać bazy danych według wzorca usługi. To sprawia, że ​​mikroserwisy są bardziej autonomiczne. W tej sytuacji powinieneś powielić niektóre swoje dane pomiędzy wieloma mikroserwisami. Możesz udostępniać dane za pomocą wywołań API pomiędzy mikrousługami lub udostępniać je z asynchronicznym przesyłaniem wiadomości. To zależy od twojej infrastruktury i częstotliwości zmiany danych. Jeśli nie zmienia się często, powinieneś duplikować dane za pomocą zdarzeń asynchronicznych.

W tym przykładzie usługa dostawy może powielać lokalizacje dostaw i informacje o produktach. Usługa produktu pozwala zarządzać produktami i lokalizacjami. Następnie wymagane dane są kopiowane do bazy danych usługi dostawy z asynchronicznymi wiadomościami (na przykład można użyć królika mq lub apache kafka). Usługa dostawy nie zmienia danych o produkcie i lokalizacji, ale wykorzystuje dane podczas wykonywania swojej pracy. Jeśli część danych produktu, która jest używana przez usługę dostawy, często się zmienia, duplikowanie danych za pomocą asynchronicznego przesyłania wiadomości będzie bardzo kosztowne. W takim przypadku należy nawiązywać połączenia między usługą a dostawą. Usługa dostawy wymaga usługi produktu, aby sprawdzić, czy produkt może być dostarczony do określonej lokalizacji, czy też nie. Usługa dostawy pyta o usługę produktu z identyfikatorem (nazwa, identyfikator itp.) Produktu i lokalizacji. Te identyfikatory mogą być pobierane od użytkownika końcowego lub dzielone między mikroserwisy. Ponieważ bazy danych mikroserwisów są tutaj różne, nie możemy zdefiniować kluczy obcych między danymi tych mikroserwisów.

Połączenia api mogą być łatwiejsze do wdrożenia, ale koszt sieci jest wyższy w tej opcji. Również twoje usługi są mniej autonomiczne, gdy wykonujesz połączenia api. Ponieważ w twoim przykładzie, gdy usługa produktu nie działa, usługa dostawy nie może wykonać swojej pracy. W przypadku duplikowania danych za pomocą przesyłania asynchronicznego wymagane dane do dostarczenia znajdują się w bazie danych Mikrourządzenia dostarczania. Gdy usługa produktu nie działa, będzie można dokonać dostawy.

+0

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

+0

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. –

4

Podczas dystrybucji kodu w celu uzyskania zredukowanego sprzężenia, chcesz uniknąć udostępniania zasobów, a dane są zasobami, których chcesz uniknąć.

Inną kwestią jest to, że tylko jeden składnik w systemie jest właścicielem danych (w przypadku operacji zmiany stanu), inne komponenty mogą ODCZYTAĆ, ale NIE PISZĄ, mogą mieć kopie danych lub można udostępnić model widoku, którego mogą użyć do uzyskać najnowszy stan obiektu.

Wprowadzenie więzów integralności przywróci sprzężenie, zamiast tego chcesz użyć czegoś takiego jak Guido do kluczy podstawowych, zostaną one utworzone przez twórcę obiektu, reszta polega na zarządzaniu ostateczną konsystencją.

Spójrz na Udi Dahan za talk in NDC Oslo for a more details

nadzieję, że to pomaga