Mikrousługi i baza danych łączy

Question

Dla ludzi, którzy dzielą monolityczne aplikacje na mikroserwisy, radzicie sobie z problemem rozdzielania bazy danych. Typowe aplikacje, nad którymi pracowałem, powodują dużą integrację bazy danych ze względu na wydajność i prostotę.

Jeśli masz dwie tabele, które są logicznie różne (ograniczone konteksty, jeśli chcesz), ale często przetwarzasz dane zbiorcze na dużych woluminach tych danych, to w monolicie możesz uniknąć orientacji obiektowej i zamiast tego używanie standardowej funkcji JOIN bazy danych do przetwarzania danych w bazie danych przed zwróceniem zagregowanego widoku z powrotem do warstwy aplikacji.

Jak uzasadnić podział takich danych na mikroserwisy, w których prawdopodobnie będzie wymagane "dołączenie" danych za pośrednictwem interfejsu API, a nie bazy danych.

Przeczytałem książkę Microservices Sama Newmana, aw rozdziale poświęconym podziałowi monolitu podaje on przykład "łamania relacji z kluczowymi kluczami", w którym przyznaje, że robienie połączenia przez API będzie wolniejsze - ale on idzie powiedzieć, czy twoja aplikacja jest wystarczająco szybka, czy ma to znaczenie, że jest wolniejsza niż wcześniej?

Wydaje się to trochę dziwne? Jakie są doświadczenia ludzi? Jakich technik używałeś, aby połączenia API działały w akceptowalny sposób?

Answer 1

• Gdy wydajność lub opóźnienie nie ma znaczenia zbyt wiele (tak, nie zawsze są potrzebne) to perfekcyjnie po prostu użyć prosty Apis spokojny dla zapytań dodatkowe dane potrzebne. Jeśli chcesz wykonać wiele połączeń do różnych mikroserwisów i zwrócić jeden wynik, możesz użyć wzoru: API Gateway.

• Jest całkiem dobrze mieć nadmiarowość w środowiskach Polyglot persistence. Możesz na przykład użyć kolejki wiadomości do swoich mikroserwisów i wysyłać zdarzenia "aktualizuj" za każdym razem, gdy coś zmienisz. Inne mikroserwisy będą słuchać wymaganych zdarzeń i zapisywać dane lokalnie. Dlatego zamiast wysyłać zapytania, przechowujesz wszystkie wymagane dane w odpowiedniej pamięci dla konkretnych usług mikroserwisowych.

• Pamiętaj też o buforowaniu :) Możesz użyć narzędzi takich jak Redis lub Memcached, aby uniknąć zbyt częstego wysyłania zapytań do innych baz danych.

Answer 2

Usługa może mieć replikowane kopie tylko niektórych danych referencyjnych z innych usług.

Biorąc pod uwagę, że podczas próby byłaby monolityczną bazę do microservices (w przeciwieństwie do przerobienia) Chciałbym

• utworzyć schemat db za usługę
• create wersjonowanym * Wyświetlenia ** w tym schemacie do wystawiać dane z tego schematu do innych usług
• zrobienia przyłącza przed tymi readonly poglądów

to pozwoli Ci niezależnie modyfikować dane stołu/strucutre bez zerwania inne aplikacje.

Zamiast używać widoków, mogę również rozważyć użycie wyzwalaczy do replikowania danych z jednego schematu do innego.

* widoki można przedłużyć. Jeśli wymagana jest zmiana zerwania, utwórz v2 tego samego widoku i usuń starą wersję, gdy nie jest już wymagana. ** lub wartości z tabeli lub sprocs.

Answer 3

W Microservices tworzysz diff. czytaj modele, na przykład dla: jeśli masz dwie różnice. ograniczony kontekst i ktoś chce przeszukać oba dane, a następnie ktoś musi wysłuchać zdarzeń z kontekstu ograniczonego i stworzyć widok specyficzny dla aplikacji.

W tym przypadku będzie więcej miejsca, ale nie będą potrzebne żadne połączenia ani połączenia.

Answer 4

CQRS --- Command Query Aggregation Pattern to odpowiedź na pytanie, jak na Chris Richardson. Niech każda mikroserwis aktualizuje swój własny model danych i generuje zdarzenia, które aktualizują zmaterializowany widok, który ma wymagane dane sprzężenia z wcześniejszych mikroserwisów. Ten MV może być dowolnym NoSql DB lub Redis lub elastycznym wyszukiwaniem, który jest zoptymalizowany pod kątem zapytań. Techniki te prowadzą do ostatecznej spójności, która zdecydowanie nie jest zła i pozwala uniknąć sprzężeń po stronie aplikacji w czasie rzeczywistym. Mam nadzieję, że te odpowiedzi.