Mikrousługi i przechowywanie danych

Zastanawiam się nad przeniesieniem monolitycznego interfejsu API REST na architekturę mikrousług i mam trochę wątpliwości co do przechowywania danych. Moim zdaniem niektóre z zalet mikrousług byłyby następujące:

• Skalowalny w poziomie - mogę uruchomić wiele nadmiarowych kopii mikrousług, aby poradzić sobie z obciążeniem i / lub spadkiem serwera.
• Luźno powiązane - Mogę zmieniać wewnętrzne implementacje mikrousług bez konieczności zmiany innych, a także mogę samodzielnie je wdrażać i zmieniać itp.

Mój problem dotyczy przechowywania danych. Widzę, że istnieje kilka opcji:

1. Pojedyncza usługa bazy danych współdzielona przez wszystkie mikrousługi - wydaje się, że całkowicie eliminuje to wszelkie korzyści wynikające z luźnego łączenia.
2. Lokalnie zainstalowana instancja bazy danych na każdej mikrousługie - nie widzę sposobu na skalowanie tego w poziomie, więc nie sądzę, że byłaby to opcja.
3. Każda mikrousługa ma własną usługę bazy danych - wydaje się to najbardziej obiecujące, ponieważ zachowuje zalety luźnego łączenia i skalowania w poziomie (przy użyciu nadmiarowych kopii bazy danych i / lub dzielenia na kilka)

Dla mnie trzecia opcja wydaje się być jedyną opcją, ale wydaje mi się niesamowicie ciężka i bardzo nadinżynieryjnym rozwiązaniem. Jeśli dobrze to rozumiem, to dla prostej aplikacji z 4-5 mikrousługami musiałbym uruchomić 16-20 serwerów - dwie rzeczywiste instancje mikrousług na mikrousługę (w przypadku awarii serwera i wdrożenia bez przestoju), oraz dwa wystąpienia usługi bazy danych na mikrousługę (w przypadku awarii serwera itp.).

To, szczerze mówiąc, wydaje się nieco niedorzeczne. 16-20 serwerów do obsługi prostego API, mając na uwadze, że realistyczny projekt prawdopodobnie będzie miał więcej niż 4-5 usług? Czy brakuje mi jakiegoś fundamentalnego pojęcia, które to wyjaśni?

Niektóre rzeczy, które mogą pomóc podczas odpowiadania:

• Jestem jedynym deweloperem tego projektu i będę w dającej się przewidzieć przyszłości.
• Korzystam z Node.js i MongoDB, ale interesują mnie odpowiedzi niezależne od języka - odpowiedź może być nawet taka, że ​​używam niewłaściwych technologii!

Spośród trzech opcji pierwsza (jedna, wspólna baza danych) i trzecia („usługa bazy danych”) są najczęstsze.

Pierwszy nazywa się bazą danych integracji . Zasadniczo nie jest to postrzegane jako dobre rozwiązanie w architekturze mikrousług. Dodaje sprzężenie do twoich usług. Ułatwia również jednej usłudze po prostu obejście innych usług i wysłanie zapytania bezpośrednio do bazy danych. Możesz utracić integralność lub sprawdzanie poprawności danych na poziomie aplikacji, które nie jest egzekwowane na poziomie bazy danych.

Trzeci pomysł nazywa się bazą danych aplikacji . I masz rację - pozwala wymusić luźne połączenie na poziomie interfejsu API między usługami i pozwala na łatwiejsze skalowanie usług na poziomie bazy danych. Ułatwia także zastąpienie bazowej technologii bazodanowej czymś odpowiednim dla każdej usługi, podobnie jak można zmienić technologię lub inne szczegóły implementacji każdej usługi. Bardzo elastyczny.

Proponuję jednak rozwiązanie pośrednie.

Zamiast stawiać usługę bazy danych dla każdej mikrousługi, stań na schemacie dla każdej usługi. W przypadku korzystania z wielu technologii baz danych może być konieczne podzielenie się nieco inaczej, ale pomysł polegałby na zminimalizowaniu liczby uruchomionych serwerów baz danych, ale bardzo ułatwiłby podział usługi na własny serwer bazy danych, jeśli i kiedy stanie się to konieczne. Dopóki zezwalasz tylko bazie danych na dostęp do własnego schematu, masz zalety bazy danych aplikacji, ale bez obciążania serwerów bazy danych dla każdej aplikacji lub usługi.

Jednak jako solowy programista w tym momencie zakwestionowałbym całą koncepcję mikrousług - Martin Fowler pisze o Monolith First i Microservice Premium , Simon Brown mówi o modułowych monolitach , a DHH mówi o Majestic Monolith. Nie jestem pewien, jak dobrze twój monolit jest zorganizowany, ale przerób go i zorganizuj. Zidentyfikuj komponenty i dokonaj czystych separacji między nimi, aby łatwo wyodrębnić elementy do serwisu. To samo dotyczy struktury bazy danych. Skoncentruj się na dobrej, czystej architekturze opartej na komponentach, która może wspierać refaktoryzację do usług. Mikrousługi powodują znaczne obciążenie dla jednego programisty w zakresie tworzenia i obsługi operacji. Jednak gdy rzeczywiście zajdzie potrzeba skalowania części systemu, użyj systemów monitorowania i raportowania, aby zidentyfikować wąskie gardła, wyodrębnić usługę i skalować w razie potrzeby.

Każda mikrousługa ma własną usługę bazy danych - wydaje się to najbardziej obiecujące, ponieważ zachowuje zalety luźnego łączenia i skalowania w poziomie (przy użyciu nadmiarowych kopii bazy danych i / lub dzielenia na kilka)

Zgodzić się. Trzecia opcja jest naturalnym wyborem dla usług mikro. Jeśli mikrousługa ma być naprawdę niezależna (i nie jest częścią rozproszonego monolitu ), to normalne, że mają one bazę danych.

[...] dwie rzeczywiste instancje mikrousług na mikrousługę (w przypadku awarii serwera i do wdrożenia bez przestoju) oraz dwie instancje usługi bazy danych na mikrousługę (w przypadku awarii serwera itp.).

Masz rację co do liczby uruchomionych mikrousług, jeśli chcesz mieć bilans obciążenia. Jeśli planujesz mieć 4 mikrousługi, musisz przygotować co najmniej 2 wystąpienia każdej mikrousługi (łącznie 8), jak już wyjaśniłeś.

Ale dwie bazy danych na mikrousługę? To jest naprawdę wątpliwe. Nie znam szczegółów dotyczących problemu biznesowego, w którym wezmą udział twoje mikrousługi, ale nadmiarowość bazy danych to dość dużo w przypadku większości produktów / projektów. Polecę zacząć od jednej bazy danych z dobrą kopią zapasową i zminimalizować (przynajmniej początkowo) złożoność infrastruktury.

To, szczerze mówiąc, wydaje się nieco niedorzeczne. 16-20 serwerów do obsługi prostego API, mając na uwadze, że realistyczny projekt prawdopodobnie będzie miał więcej niż 4-5 usług? Czy brakuje mi jakiegoś fundamentalnego pojęcia, które to wyjaśni?

W przypadku prostego interfejsu API liczby te nie są zgodne. Zwróć uwagę, jeśli nie wpadniesz w jedną z pułapek „Mikrousługa Najpierw” .

Mikrousługi są formą architektury zorientowanej na usługi, być może w skrajności. Ich ogólnym celem jest ograniczenie sprzężenia i umożliwienie niezależnego programowania i wdrażania.

Mówiąc bardzo z grubsza pod względem architektonicznym, mikrousługi to termin, który stosuje się, powiedzmy, na poziomie logicznym. Mikrousługi są logicznie oddzielone od siebie. Z tej perspektywy mikrousługi powinny posiadać i zapewniać własne przechowywanie, które należy oddzielić od przechowywania innych mikrousług. W przypadku mikrousług ta niezależność przechowywania jest kluczem do ich modułowości i luźnego łączenia.

Z perspektywy architektonicznej skalowanie w poziomie ma zastosowanie na niższym poziomie, bliższym implementacji, powiedzmy, na poziomie fizycznym. Na tym poziomie wdrażamy mikrousługę i możemy wewnętrznie dekomponować tę pojedynczą mikrousługę na składnik bezstanowy, który jest skalowalny poziomo, i na stanowy element, który jest wspólny dla wszystkich składników bezstanowych.  Ale nie mylmy samej bezpaństwowej części z samą mikrousługą.

Kiedy mówimy o poszczególnych mikrousługach, jesteśmy na poziomie logicznym, mówiąc o interfejsach API i oddzielnych obowiązkach oraz oddzielnych cyklach programowania / wdrażania. A kiedy mówimy o skalowaniu poziomym, to na poziomie fizycznym mówimy o implementacji (pojedynczej) mikrousługi i jej rozkładzie na bezstanowe i stanowe komponenty.

Wdrażając wiele mikrousług, mamy możliwość ponownego wykorzystania technologii bazy danych dla składników stanowych:

• osobna baza danych dla mikrousług
• wspólna baza danych z:
  • oddzielny / prywatny schemat dla mikrousług
  • osobne / prywatne tabele na mikrousługę

Zobacz więcej tutaj .

Pojedyncza usługa bazy danych współdzielona przez wszystkie mikrousługi - wydaje się, że całkowicie eliminuje to wszelkie korzyści wynikające z luźnego łączenia.

Zgadzam się, jeśli masz na myśli udostępnianie wierszy i kolumn tabel, to tak naprawdę nie byłoby mikrousług.

Jeśli potrafimy oddzielić - w naszych procesach myślowych - logiczne pojęcie mikrousług od bardziej fizycznego pojęcia stanowych i bezpaństwowych elementów mikrousług, możemy łatwiej osiągnąć luźne sprzężenie oferowane przez mikrousługi, zachowując wydajność wspólnego bazy danych.

Zasadniczo na temat mikrousług i stanowej trwałości napisano sporo, patrz także tutaj .

Cóż, przeczytałem wszystkie posty w tym wątku i mogę powiedzieć, że nie rozumiem pytania: łączy mikrousługę (MS) z usługami z usługą dostępu do danych (usługa DB) z bazami danych i serwerami ...

Jeśli MS jest niezależnym (możliwym do wdrożenia) komponentem rozwiązującym jedno najprostsze zadanie w sposób bezstanowy, JAKIEJ bazy danych potrzebuje? Jeśli bardziej złożone zadanie do rozwiązania, które wymaga więcej niż jednego najprostszego zadania podrzędnego (MS?) Do wspólnego rozwiązania, czy nadal jest to MS? W SOA nazywa się to usługą orkiestracji. Wdraża „proces” i koordynuje wywołanie MS, dlatego musi zachować swój stan (wszystkie orkiestracje / organizatorzy / kompozytorzy / itd. Są stanowe) i potrzebuje osobistego magazynu danych: nikt inny nie może temperować stanu orkiestratora.

Nie mówimy jednak o bazie danych, ale o dostępie do bazy danych MS / Service, a to zupełnie inna sprawa. MS może potrzebować niektórych danych zebranych w firmie (nie w aplikacji, w której działa) i nie może poprosić o dane innego MS za pośrednictwem interfejsu API / interfejsu. To najczęstszy i najbardziej realistyczny scenariusz. A inne państwo członkowskie z tej samej lub innej aplikacji może potrzebować tych danych, a nawet je zmieniać. Tak, konkurują o dane, jak zawsze przed pojawieniem się SM.

Dlaczego rozbijamy „drzwi”, które są dobrze znane i otwarte? Jaka jest różnica w tym względzie między stwardnieniem rozsianym a zwykłym upartym przedmiotem? Dlaczego potrzebujemy indywidualnej bazy danych dla MS, jeśli musi ona (dla celów elastyczności i kompozycyjności) skorzystać z usługi dostępu do danych (DAS)? Nie zapominaj, że DAS chroni MS z zadaniem biznesowym przed świadomością fizycznej łączności z bazą danych. To luźne połączenie i elastyczność, którą MS powinno zachować, aby swobodnie uczestniczyć w wielu aplikacjach bez kotwiczenia bazy danych.