Mikrousługi: jak obsługiwać relacje klucza obcego

Architektura mikrousług sugeruje, że każda usługa powinna obsługiwać własne dane. W związku z tym każda usługa (Usługa A) zależna od danych należących do innej usługi (usługa B) powinna uzyskiwać dostęp do takich danych nie poprzez bezpośrednie wywołania DB, ale za pośrednictwem interfejsu API udostępnianego przez drugą usługę (usługę B).

Co zatem sugerują najlepsze rozwiązania dotyczące mikrousług dotyczących sprawdzania ograniczeń klucza obcego.

Przykład: Opracowuję funkcję dostawy (mikrousługa 1) dla produktów, a niektóre produkty są dostępne tylko w określonych lokalizacjach, jak wspomniano w tabeli produktów, dostępnej tylko dla mikroserwisów produktów (mircoservice 2).

Jak się upewnić, że mikrousługa 1 (tj. Funkcja dostawy) nie przenosi zamówienia do lokalizacji bez obsługi. Mam to pytanie, ponieważ funkcja dostawy nie ma bezpośredniego dostępu do bazy danych produktów, więc nie ma ograniczeń obowiązujących na poziomie DB, gdy zamówienie dostawy jest składane w bazie danych dostaw (nie jest możliwe sprawdzenie, czy w bazie danych produktów istnieje dopasowanie klucza obcego lub stół).

Możliwe jest użycie udostępnionej bazy danych dla wielu mikrousług. Wzorce zarządzania danymi mikrousług można znaleźć pod tym linkiem: http://microservices.io/patterns/data/database-per-service.html . Nawiasem mówiąc, jest to bardzo przydatny blog dotyczący architektury mikrousług.

W Twoim przypadku wolisz używać bazy danych na wzorzec usługi. Dzięki temu mikrousługi są bardziej autonomiczne. W takiej sytuacji należy zduplikować niektóre dane w wielu mikrousługach. Możesz udostępniać dane za pomocą wywołań interfejsu API między mikrousługami lub możesz udostępniać je za pomocą komunikatów asynchronicznych. To zależy od Twojej infrastruktury i częstotliwości zmian danych. Jeśli nie zmienia się często, należy zduplikować dane ze zdarzeniami asynchronicznymi.

W Twoim przykładzie usługa dostawy może powielać lokalizacje dostawy i informacje o produkcie. Serwis produktowy zarządza produktami i lokalizacjami. Następnie wymagane dane są kopiowane do bazy danych usługi Delivery z komunikatami asynchronicznymi (można na przykład użyć rabbit mq lub apache kafka). Usługa dostawy nie zmienia danych produktu i lokalizacji, ale wykorzystuje te dane podczas wykonywania swojej pracy. Jeśli część danych produktu, która jest używana przez usługę dostawy, często się zmienia, powielanie danych za pomocą wiadomości asynchronicznych będzie bardzo kosztowne. W takim przypadku należy wykonywać wywołania interfejsu API między usługą Product i Delivery. Usługa dostawy prosi obsługę produktu o sprawdzenie, czy produkt można dostarczyć do określonej lokalizacji, czy nie. Usługa dostawy prosi obsługę produktów o identyfikator (nazwa, identyfikator itp.) Produktu i lokalizacji. Te identyfikatory mogą być pobierane od użytkownika końcowego lub są współużytkowane przez mikrousługi. Ponieważ bazy danych mikrousług są tutaj różne, nie możemy definiować kluczy obcych między danymi tych mikrousług.

Wywołania API mogą być łatwiejsze do wdrożenia, ale w tej opcji koszt sieci jest wyższy. Twoje usługi są również mniej autonomiczne, gdy wykonujesz wywołania 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ą wiadomości asynchronicznych dane wymagane do dostarczenia znajdują się w bazie danych mikrousługi dostarczania. Gdy usługa produktu nie działa, będziesz mógł dokonać dostawy.

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

Inną kwestią jest to, że tylko jeden komponent w twoim systemie jest właścicielem danych (dla operacji zmiany stanu), inne komponenty mogą CZYTAĆ, ale NIE PISAĆ, mogą mieć kopie danych lub możesz udostępniać model widoku, którego mogą użyć, aby uzyskać najnowszy stan przedmiotu.

Wprowadzenie integralności referencyjnej przywróci sprzężenie, zamiast tego chcesz użyć czegoś takiego jak Guidy dla kluczy podstawowych, zostaną one utworzone przez twórcę obiektu, a reszta dotyczy zarządzania ostateczną spójnością.

Zapoznaj się z przemówieniem Udi Dahana w NDC Oslo, aby uzyskać więcej informacji

Mam nadzieję że to pomoże

pierwsze rozwiązanie: skład API

 Implement a query by defining an API Composer, which invoking the
 services that own the data and performs an in-memory join of the
 results

drugie rozwiązanie: CQRS

Define a view database, which is a read-only replica that is designed to support that 
query. The application keeps the replica up to data by subscribing to Domain events 
published by the service that own the data.

Aktualizacja tej odpowiedzi w 2020 roku polega na użyciu narzędzia do przechwytywania danych zmian, takiego jak Debezium. Debezium będzie monitorować tabele bazy danych pod kątem zmian i przesyłać je strumieniowo do Kafka / Pulsar (inne potoki), a Twoi subskrybenci mogą następnie przechwytywać zmiany i synchronizować je.