Zagadnienia dotyczące danych dotyczące mikrousług

W tym artykule opisano zagadnienia dotyczące zarządzania danymi w architekturze mikrousług. Każda mikrousługa zarządza własnymi danymi, więc integralność danych i spójność danych stanowią krytyczne wyzwania.

Dwie usługi nie powinny współdzielić magazynu danych. Każda usługa zarządza własnym prywatnym magazynem danych, a inne usługi nie mogą uzyskać do niego bezpośredniego dostępu. Ta reguła zapobiega przypadkowemu sprzężeniu między usługami, co ma miejsce, gdy usługi współużytkuje te same schematy danych bazowych. Jeśli schemat danych ulegnie zmianie, zmiana musi być skoordynowana dla każdej usługi, która opiera się na tej bazie danych. Izolowanie magazynu danych każdej usługi ogranicza zakres zmian i zachowuje elastyczność niezależnych wdrożeń. Każda mikrousługa może również mieć unikatowe modele danych, zapytania lub wzorce odczytu i zapisu. Udostępniony magazyn danych ogranicza możliwość optymalizacji magazynu danych dla określonej usługi przez każdy zespół.

Takie podejście naturalnie prowadzi do powstania poliglotycznej trwałości, co oznacza użycie wielu technologii przechowywania danych w ramach jednej aplikacji. Jedna z usług może wymagać możliwości odczytu schematu bazy danych dokumentów. Inna usługa może wymagać integralności referencyjnej zapewnianej przez system zarządzania relacyjnymi bazami danych (RDBMS). Każdy zespół może wybrać najlepszą opcję dla swojej usługi.

Wyzwania

Rozproszone podejście do zarządzania danymi wprowadza kilka wyzwań. Po pierwsze, redundancja może wystąpić w magazynach danych. Ten sam element danych może pojawić się w wielu miejscach. Na przykład dane mogą być przechowywane w ramach transakcji, a następnie przechowywane w innym miejscu na potrzeby analizy, raportowania lub archiwizowania. Zduplikowane lub partycjonowane dane mogą prowadzić do problemów z integralnością i spójnością danych. Gdy relacje danych obejmują wiele usług, tradycyjne techniki zarządzania danymi nie mogą wymuszać tych relacji.

Tradycyjne modelowanie danych jest zgodne z regułą jednego faktu w jednym miejscu. Każda jednostka jest wyświetlana dokładnie raz w schemacie. Inne jednostki mogą się do niego odwoływać, ale nie duplikować. Główną zaletą tradycyjnego podejścia jest to, że aktualizacje występują w jednym miejscu, co zapobiega problemom ze spójnością danych. W architekturze mikrousług należy wziąć pod uwagę sposób propagacji aktualizacji między usługami i zarządzania spójnością ostateczną, gdy dane pojawiają się w wielu miejscach bez silnej spójności.

Podejścia do zarządzania danymi

W przypadku wszystkich przypadków nie działa żadne pojedyncze podejście. Rozważ następujące ogólne wskazówki dotyczące zarządzania danymi w architekturze mikrousług:

• Zdefiniuj wymagany poziom spójności dla każdego składnika i w miarę możliwości preferuj spójność ostateczną. Zidentyfikuj obszary w systemie, w których potrzebna jest silna spójność lub atomowość, a także spójność, izolacja i trwałość transakcji (ACID). Zidentyfikuj obszary, w których spójność ostateczna jest akceptowalna. Aby uzyskać więcej informacji, zobacz Używanie taktycznego projektowania opartego na domenie (DDD) dla mikrousług.

• Użyj pojedynczego źródła prawdy, jeśli potrzebujesz silnej spójności. Jedna usługa może reprezentować źródło prawdy dla danej jednostki i uwidocznić ją za pośrednictwem interfejsu API. Inne usługi mogą przechowywać własną kopię danych lub podzbiór danych, które ostatecznie są zgodne z podstawowymi danymi, ale nie są uważane za źródło prawdy. Na przykład w systemie handlu elektronicznego, który ma usługę zamówień klienta i usługę rekomendacji, usługa rekomendacji może nasłuchiwać zdarzeń z usługi zamówienia. Jeśli jednak klient zażąda zwrotu kosztów, usługa zamówienia, a nie usługa rekomendacji, ma pełną historię transakcji.

• Stosowanie wzorców transakcji w celu zachowania spójności między usługami. Użyj wzorców takich jak Nadzorca agenta harmonogramu i Transakcja kompensacyjna aby utrzymać spójność danych między wieloma usługami. Aby uniknąć częściowej awarii między wieloma usługami, może być konieczne zapisanie dodatkowego elementu danych, który przechwytuje stan jednostki pracy obejmującej wiele usług. Na przykład zachowaj element roboczy w trwałej kolejce, gdy transakcja wieloetapowa jest w toku.

• Przechowuj tylko dane wymagane przez usługę. Usługa może potrzebować tylko podzestawu informacji o jednostce domeny. Na przykład w ramach powiązanego kontekstu wysyłki musisz wiedzieć, który klient jest powiązany z określoną dostawą. Nie potrzebujesz jednak adresu rozliczeniowego klienta, ponieważ kontekst powiązany z kontami zarządza tymi informacjami. Staranne analizy domeny i podejście DDD mogą wymuszać tę zasadę.

• Zastanów się, czy usługi są spójne i luźno powiązane. Jeśli dwie usługi stale wymieniają informacje ze sobą i tworzą rozmowne interfejsy API, może być konieczne ponowne rysowanie granic usługi. Połącz dwie usługi lub zrefaktoryzuj ich funkcjonalność.

• Użyj stylu architektury opartej na zdarzeniach. W tym stylu architektury usługa publikuje zdarzenie, gdy wystąpią zmiany w jej modelach publicznych lub jednostkach. Inne usługi mogą rejestrować się na te wydarzenia. Na przykład inna usługa może używać zdarzeń do konstruowania zmaterializowanego widoku danych, które są bardziej odpowiednie do wykonywania zapytań.

  • Opublikuj schemat zdarzeń. Usługa, która jest właścicielem zdarzeń, powinna opublikować schemat w celu zautomatyzowania serializacji i deserializacji zdarzeń. Takie podejście pozwala uniknąć ścisłego sprzężenia między wydawcami i subskrybentami. Rozważ użycie schematu JSON lub struktury, takiej jak Protobuf lub Avro.

  • Zmniejszanie wąskich gardeł zdarzeń na dużą skalę. Na dużą skalę zdarzenia mogą stać się wąskim gardłem w systemie. Rozważ użycie agregacji lub dzielenia na partie w celu zmniejszenia całkowitego obciążenia.

Przykład: wybieranie magazynów danych dla aplikacji dostarczania dronów

W poprzednich artykułach z tej serii opisano usługę dostarczania dronów jako działający przykład. Aby uzyskać więcej informacji na temat scenariusza i odpowiedniej architektury, zobacz Projektowanie architektury mikrousług.

Aby podsumować, ta aplikacja definiuje kilka mikrousług do planowania dostaw za pomocą drona. Gdy użytkownik planuje nową dostawę, żądanie klienta zawiera informacje o dostawie, takie jak lokalizacje odbioru i wysyłki, oraz informacje o pakiecie, takie jak rozmiar i waga. Te informacje definiują jednostkę pracy.

Różne usługi zaplecza używają różnych części informacji w żądaniu i mają różne profile odczytu i zapisu.

Usługa dostarczania

Usługa dostarczania przechowuje informacje o każdej dostawie, która jest obecnie zaplanowana lub w toku. Nasłuchuje zdarzeń z dronów i śledzi stan dostaw w toku. Wysyła również zdarzenia domeny z aktualizacjami stanu dostarczania.

Użytkownicy często sprawdzają stan dostawy podczas oczekiwania na jego pakiet. Dlatego usługa dostarczania wymaga magazynu danych, który podkreśla przepustowość (odczyt i zapis) zamiast długoterminowego przechowywania. Usługa dostarczania nie wykonuje złożonych zapytań ani analiz. Pobiera tylko najnowszy stan dla określonej dostawy. Zespół usługi dostarczania wybrał usługę Azure Managed Redis, aby uzyskać wysoką wydajność odczytu i zapisu. Informacje przechowywane w usłudze Azure Managed Redis są krótkotrwałe. Po zakończeniu dostawy usługa historii dostarczania staje się systemem ewidencji.

Usługa śledzenia historii dostaw

Usługa historii dostarczania nasłuchuje zdarzeń statusu dostawy z usługi dostarczania. Przechowuje te dane w magazynie długoterminowym. Te dane historyczne obsługują dwa scenariusze, z których każdy ma różne wymagania dotyczące magazynu.

Pierwszy scenariusz agreguje dane analizy danych w celu zoptymalizowania firmy lub poprawy jakości usług. Usługa historii dostarczania nie wykonuje rzeczywistej analizy danych. Pozyskuje tylko dane i przechowuje je. W tym scenariuszu magazyn musi być zoptymalizowany pod kątem analizy danych w dużych zestawach danych i używać podejścia schema-on-read, aby uwzględnić różne źródła danych. Usługa Azure Data Lake Storage jest dobrym rozwiązaniem w tym scenariuszu, ponieważ jest to system plików Apache Hadoop zgodny z rozproszonym systemem plików Hadoop (HDFS). Jest ona również dostrojona pod kątem wydajności scenariuszy analizy danych.

Drugi scenariusz umożliwia użytkownikom wyszukiwanie historii dostarczania po zakończeniu dostarczania. Usługa Data Lake Storage nie obsługuje tego scenariusza. Aby uzyskać optymalną wydajność, przechowuj dane szeregów czasowych w usłudze Data Lake Storage w folderach podzielonych według daty. Jednak ta struktura sprawia, że pojedyncze wyszukiwania oparte na identyfikatorach są nieefektywne. Jeśli nie znasz również znacznika czasu, wyszukiwanie identyfikatorów wymaga skanowania całej kolekcji. Aby rozwiązać ten problem, usługa historii dostarczania przechowuje również podzbiór danych historycznych w usłudze Azure Cosmos DB w celu szybszego wyszukiwania. Rekordy nie muszą pozostawać w usłudze Azure Cosmos DB na czas nieokreślony. Starsze dostawy można archiwizować po upływie określonego czasu, na przykład miesiąca, wykonując okazjonalny proces wsadowy. Archiwizowanie danych może obniżyć koszty usługi Azure Cosmos DB i zachować dostępne dane na potrzeby raportowania historycznego z usługi Data Lake Storage.

Aby uzyskać więcej informacji, zobacz Dostosowywanie usługi Data Lake Storage pod kątem wydajności.

Usługa pakietu

Usługa pakietu przechowuje informacje o wszystkich pakietach. Magazyn danych usługi pakietu musi spełniać następujące wymagania:

• Długoterminowe przechowywanie
• Wysoka przepływność zapisu w celu obsługi dużej liczby pakietów
• Proste zapytania według identyfikatora pakietu bez złożonych sprzężeń lub ograniczeń integralności referencyjnej

Dane pakietu nie są relacyjne, więc baza danych zorientowana na dokumenty działa dobrze. Usługa Azure DocumentDB może osiągnąć wysoką przepływność przy użyciu kolekcji podzielonych na fragmenty. Zespół ds. usług pakietowych ma doświadczenie w pracy ze stosem technologii MEAN, który obejmuje MongoDB, Express.js, AngularJS i Node.js, dlatego wybiera wdrożenie usługi Azure DocumentDB. Ten wybór umożliwia im korzystanie z istniejącego środowiska bazy danych MongoDB przy jednoczesnym uzyskaniu korzyści z w pełni zarządzanej usługi platformy Azure o wysokiej wydajności.

Powiązane zasoby

• Wzorce projektowe dla mikrousług
• Używanie analizy domen do modelowania mikrousług
• Projektowanie architektury mikrousług
• Projektowanie interfejsów API dla mikrousług
• Projektowanie architektury mikrousług