Dlaczego mikrousługi mogą umrzeć, gdy monolit powróci ze zdwojoną siłą?

Przejście w kierunku mikrousług zaczęło nabierać tempa na początku 2010 roku, gdy firmy technologiczne dostrzegły ograniczenia architektur monolitycznych. Jednak wiele firm, np Amazon (Prime Video), InVision, Istio i Segment Wracając do architektury monolitycznej. W tym artykule omówimy, dlaczego wiele organizacji ponosi porażkę podczas przejścia na architekturę mikrousług.

Co to jest monolit?

Architektura monolityczna jest prosta: użytkownik żąda danych, a cała logika biznesowa i dane znajdują się w jednej usłudze. Jednak systemy monolityczne stoją przed wyzwaniami, takimi jak ograniczona skalowalność, trudności z wdrażaniem aktualizacji i podatność na pojedyncze punkty awarii.

Aby rozwiązać ten problem, wiele organizacji próbowało przejść na architektury oparte na mikrousługach, aby skorzystać z takich korzyści, jak abstrakcja i hermetyzacja, szybsze wdrażanie, łatwiejsza konserwacja i ściślejsze dostosowanie każdej usługi do własności zespołu.

Dlaczego mikrousługi?

W idealnej architekturze mikrousług każda domena biznesowa działa jak osobna, niezależna usługa z własną bazą danych. Taka konfiguracja zapewnia korzyści, takie jak lepsza skalowalność, elastyczność i odporność. Rozważ poniższy obrazek.

rzeczywistość

Jednak ostatnie trendy pokazują, że wiele firm odchodzi od tego i trzyma się architektury monolitycznej. Dzieje się tak dlatego, że taki poziom harmonii jest trudny do osiągnięcia w prawdziwym świecie. Rzeczywistość często wygląda tak jak na poniższym obrazku.

Wiadomo, że migracja do architektury mikrousług powoduje złożone interakcje między usługami, wywołania cykliczne, problemy z integralnością danych i szczerze mówiąc, całkowite pozbycie się monolitu jest prawie niemożliwe. Omówmy, dlaczego niektóre z tych problemów pojawiają się po przejściu na architekturę mikrousług.

Nieprawidłowe granice domeny

W idealnym scenariuszu pojedyncza usługa powinna obejmować jedną lub więcej całych domen biznesowych, tak aby każda domena stanowiła samodzielną usługę. Domeny nigdy nie należy dzielić na wiele usług, ponieważ może to prowadzić do współzależności między usługami. Poniższy diagram pokazuje, jak pojedyncza usługa może obejmować jedną lub więcej całych domen, aby zachować wyraźne granice.

W złożonych systemach rzeczywistych zdefiniowanie granic dziedzin może być wyzwaniem, zwłaszcza gdy dane były tradycyjnie konceptualizowane w specyficzny sposób. Poniższy diagram pokazuje, jak często wyglądają systemy w świecie rzeczywistym w architekturach mikrousług, gdy granice nie są z góry zdefiniowane lub inżynierowie dodają nowe usługi bez uwzględnienia granic domen.

Jeśli domeny nie są dobrze zdefiniowane, zwiększa się zależność od innych usług, powodując szereg problemów:

• Zależności cykliczne lub nadmierne wywołania: Gdy usługi są od siebie zależne, wymagają częstej wymiany danych.
• Problemy z integralnością danych: Podział pojedynczej domeny na usługi powoduje podział głęboko powiązanych danych na wiele usług.
• Niejasna własność zespołu: wiele zespołów może potrzebować współpracy w nakładających się domenach, co prowadzi do nieefektywności i zamieszania.

Głęboko powiązane dane i funkcjonalność

W architekturze monolitycznej klienci często omijają określone interfejsy i uzyskują bezpośredni dostęp do bazy danych, ponieważ hermetyzacja jest trudna do wdrożenia w pojedynczej bazie kodu. Może to skłonić programistów do stosowania skrótów, zwłaszcza jeśli interfejsy są niejasne lub wydają się skomplikowane. Z biegiem czasu tworzy to sieć klientów ściśle powiązaną z określonymi tabelami bazy danych i logiką biznesową.

W przypadku przejścia na architekturę mikrousług każdy klient musi zostać zaktualizowany, aby mógł współpracować z nowym interfejsem API usługi. Ponieważ jednak klienci są tak przywiązani do logiki biznesowej monolitu, podczas migracji należy dokonać refaktoryzacji ich logiki.

Rozwiązanie tych zależności bez przerywania istniejącej funkcjonalności wymaga czasu. Ze względu na złożoność pracy niektóre aktualizacje klientów są często opóźnione, co powoduje, że niektórzy klienci po migracji nadal korzystają z monolitycznych baz danych. Aby tego uniknąć, inżynierowie mogą tworzyć nowe modele danych w nowej usłudze, ale zachować istniejące modele w monolicie. Kiedy modele są głęboko połączone, powoduje to podział danych i funkcji pomiędzy usługami, co prowadzi do wielu połączeń między usługami i problemów z integralnością danych.

migracja danych

Migracja danych to jeden z najbardziej złożonych i ryzykownych elementów przejścia na mikroserwisy. Istotne jest dokładne i pełne przeniesienie wszystkich istotnych danych do nowych mikroserwisów. Wiele migracji zatrzymuje się na tym etapie ze względu na złożoność, ale pomyślna migracja danych jest kluczem do wykorzystania korzyści płynących z mikrousług. Typowe wyzwania obejmują:

• Integralność i spójność danych: Błędy podczas migracji mogą prowadzić do utraty lub niespójności danych.
• Objętość danych: Przesyłanie dużych ilości danych może wymagać dużej ilości zasobów i być czasochłonne.
• Przestoje i ciągłość działania: migracja danych może wymagać przestojów, co może zakłócić działalność biznesową. Ważna jest płynna zmiana przy minimalnym wpływie użytkownika.
• Testowanie i weryfikacja: wymagane są rygorystyczne testy, aby mieć pewność, że migrowane dane są dokładne, kompletne i dobrze działają w nowej usłudze.

wniosek

Architektura mikrousług może wydawać się atrakcyjna, ale przejście od monolitu stanowi wyzwanie. Wiele firm utknęło pośrodku, zwiększając złożoność systemu, powodując problemy z integralnością danych, zależności cykliczne i niejasną własność zespołu. Brak możliwości wykorzystania pełnych zalet mikroserwisów w świecie rzeczywistym powoduje, że wiele firm powraca do podejścia monolitycznego.

Supriya Lal jest kierownikiem technicznym grupy w organizacji Forum Handlowego kora,