Jeśli architektura mikrousług wymaga osobnej bazy danych na mikrousługę, jest to zbyt kosztowne i niemożliwe do zarządzania. Dlaczego tego potrzebujemy?

Czytam o mikrousługach i wydaje mi się, że nielogiczne jest tworzenie osobnej bazy danych dla każdej usługi tylko w celu uzyskania izolacji. Mogę to samo osiągnąć, korzystając tylko z usług internetowych i jednej bazy danych. Dlaczego tego potrzebujemy? Oddzielna baza danych nie podlega dyskusji. Czy jestem w błędzie? Czy możesz mi w tym pomóc?

Dlaczego tego potrzebujemy?

Ty nie.

Utworzenie osobnej bazy danych dla każdej usługi pomaga egzekwować granice domen, ale jest to tylko jedno podejście. Nic nie stoi na przeszkodzie, aby wszystkie Twoje usługi korzystały z tej samej bazy danych.

Dopóki twoje usługi zachowują się i nie robią nieoczekiwanych rzeczy na danych należących do innych usług, nic ci nie będzie.

Nie wiem, co czytasz, ale powinieneś mieć świadomość, że istnieje wiele różnych opinii na temat architektury mikrousług. Oto dobry post na blogu na ten temat.

Widziałem ludzi odnoszących się częściowo do tego pomysłu, trywialnie, ponieważ „każda mikrousługa powinna posiadać własną bazę danych i kontrolować ją, a żadna z dwóch usług nie powinna udostępniać bazy danych”. Pomysł jest solidny: nie udostępniaj jednej bazy danych między usługami, ponieważ wtedy napotykasz konflikty, takie jak konkurencyjne wzorce odczytu / zapisu, konflikty modelu danych, problemy z koordynacją itp.

Ale pojedyncza baza danych zapewnia nam wiele zabezpieczeń i udogodnień: transakcje ACID, jedno miejsce do patrzenia, dobrze zrozumiane (trochę?), Jedno miejsce do zarządzania itp.

Podróż do mikrousług jest właśnie taka: podróż . Będzie inaczej dla każdej firmy. Nie ma twardych i szybkich zasad, tylko kompromisy.

Najtrudniejsza część na temat mikrousług: Twoje dane

Jak odpowiada Dan Wilson, tak naprawdę nie potrzebujesz tego. Mikrousługi to nowa popularna rzecz i podobnie jak wszystkie nowe popularne rzeczy, ludzie używają ich w wielu miejscach, nawet jeśli nie zapewniają dużej wartości.

Mikrousługi pozwalają na niezależne wdrażanie i skalowanie rzeczy na poziomie „mikro”. Ta szczegółowość zapewnia wiele korzyści technicznych i jeszcze więcej korzyści nietechnicznych, ponieważ pozwala lepiej oddzielić zespoły programistów, wydać w razie potrzeby zamiast jednego dużego wydania, wypróbować nowe technologie lub procesy w izolacji itp. Posiadanie wspólnej bazy danych zabija wiele z tego powodu zależności od bazy danych. Jeśli nie możesz wdrożyć usługi bez martwienia się o dane innej usługi, straciłeś.

Oddzielna baza danych nie podlega dyskusji. Czy jestem w błędzie?

To powiedziawszy, również się mylisz.

Gdy pracujesz w chmurze, bazy danych są tanie. Zwykle za darmo! Jasne, serwer kosztuje, ale nie mówimy o pojedynczym serwerze na mikrousługę (przynajmniej nie na początku). Pojedynczy serwer z wieloma (logicznymi) bazami danych jest w porządku, pod warunkiem, że starasz się unikać zapytań między bazami danych (które wprowadzają zależności, które szkodzą „niezależnie wdrażalnemu i skalowalnemu”). Do diabła, zapytania między bazami danych są niemożliwe w niektórych usługach w chmurze, takich jak Azure SQL. Nie musisz nawet pilnie tam pracować ...

Widziałem nawet mikrousługi, w których współużytkowały bazę danych, ale każda usługa ma swój własny schemat. Ponownie musisz być ostrożny, unikając zapytań przekraczających granice danych.

Wiele miejsc nie jest aż tak pracowitych. Mają deweloperów na poziomie podstawowym lub osoby, które nie doceniają podejścia opartego na mikrousługach, mają słabe kierownictwo zespołu lub wywierają presję na osi czasu, co powoduje, że ludzie wybierają skróty.

Posiadanie osobnej bazy danych jest najczystszym sposobem wymuszenia oddzielenia, które umożliwia niezależność usługi, ale nie jest to jedyny sposób. I to nie jest tak drogie - zwłaszcza, gdy porównasz go z czasem / wynagrodzeniem spędzonym na próbach egzekwowania granic danych we wspólnej bazie danych.

Dlaczego tego potrzebujemy?

Ogromną zaletą mikrousług - a przede wszystkim SOA - jest wysoki poziom abstrakcji elementów wewnętrznych - nie tylko implementacja, ale także stosowane technologie. Na przykład, jeśli system zostanie opracowany w formie pięciu mikrousług przez pięć zespołów, jeden zespół może zdecydować się na przejście na zupełnie inny stos technologiczny (na przykład ze stosu Microsoft do LAMP), nawet nie pytając innych zespołów o opinię.

Spójrz na Amazon AWS lub Twilio. Czy wiesz, czy ich usługi są implementowane w Javie czy Ruby? Czy używają Oracle, PostgreSQL, Cassandra lub MongoDB? Z ilu maszyn korzystają? Czy troszczysz się o to; innymi słowy, czy te wybory technologiczne wpływają na sposób korzystania z tych usług? ... A co ważniejsze, jeśli zostaną przeniesione do innej bazy danych, czy musiałbyś odpowiednio zmienić aplikację kliencką?

Co się stanie, jeśli dwie usługi korzystają z tej samej bazy danych? Oto niewielka część problemów, które mogą się pojawić:

• Zespół opracowujący usługę 1 chce przejść z SQL Server 2012 do SQL Server 2016. Jednak zespół 2 polega na przestarzałej funkcji, która została usunięta w SQL Server 2016.

• Usługa 1 to ogromny sukces. Hostowanie bazy danych na dwóch komputerach (master i failover) nie jest już opcją. Ale skalowanie klastra do wielu komputerów wymaga strategii takich jak sharding. Tymczasem zespół 2 jest zadowolony z obecnej skali i nie widzi powodu, aby przejść do czegokolwiek innego.

• Usługa 1 powinna przejść na UTF-8 jako domyślne kodowanie. Usługa 2 jest jednak zadowolona, ​​używając Code Page 1252 Windows Latin 1.

• Usługa 1 decyduje się dodać użytkownika o określonej nazwie. Jednak ten użytkownik już istnieje, utworzony kilka miesięcy temu przez drugi zespół.

• Usługa 1 wymaga wielu różnych funkcji. Usługa 2 jest wysoce krytycznym komponentem i musi utrzymywać funkcje bazy danych na minimalnym poziomie, aby zmniejszyć ryzyko ataków.

• Usługa 1 wymaga 15 TB miejsca na dysku; szybkość nie jest ważna, więc zwykłe dyski twarde są idealnie w porządku. Usługa 2 wymaga maksymalnie 50 GB, ale musi uzyskać do niej jak najszybszy dostęp, co oznacza, że ​​dane powinny być przechowywane na dysku SSD.

• ...

Każdy mały wybór wpływa na wszystkich. Każda decyzja musi być podejmowana wspólnie przez osoby z każdego zespołu. Należy pójść na kompromis. Porównaj to z pełną swobodą robienia wszystkiego, co chcesz w kontekście SOA.

jest zbyt [...] niemożliwy do zarządzania.

Więc robisz to źle. Przypuszczam, że wdrażasz ręcznie .

Nie tak należy to robić. Musisz zautomatyzować wdrażanie maszyn wirtualnych (lub kontenerów Docker), na których działa baza danych. Po ich zautomatyzowaniu wdrożenie dwóch lub dwudziestu serwerów lub dwóch tysięcy serwerów nie różni się bardzo.

Magiczną cechą izolowanych baz danych jest to, że są one wyjątkowo łatwe w zarządzaniu . Czy próbowałeś zarządzać ogromną bazą danych wykorzystywaną przez dziesiątki zespołów? To koszmar. Każdy zespół ma określone prośby, a jak tylko go dotkniesz, wpłynie to na kogoś. Po połączeniu bazy danych z aplikacją zakres staje się bardzo wąski, co oznacza, że ​​jest o wiele mniej rzeczy do przemyślenia.

Jeśli ogromna baza danych wymaga wyspecjalizowanych administratorów systemu, bazy danych, które są używane tylko przez jeden zespół, mogą być zasadniczo zarządzane przez ten zespół (DevOps też o tym chodzi), uwalniając czas administratorów systemu.

to jest zbyt kosztowne

Określ koszt.

Koszty licencjonowania zależą od bazy danych. W erze przetwarzania w chmurze jestem pewien, że wszyscy główni gracze przeprojektowali swoje licencje, aby uwzględnić kontekst, w którym zamiast jednej ogromnej bazy danych istnieje wiele małych. Jeśli nie, możesz rozważyć przeniesienie do innej bazy danych. Nawiasem mówiąc, istnieje wiele otwartych źródeł.

Jeśli mówisz o mocy przetwarzania, zarówno maszyny wirtualne, jak i kontenery są przyjazne dla procesora i nie byłbym bardzo przekonany, że jedna ogromna baza danych zużywa mniej procesora niż wiele małych wykonujących tę samą pracę.

Jeśli problemem jest pamięć, maszyny wirtualne nie są dla Ciebie dobrym wyborem. Pojemniki są. Będziesz mógł rozciągać tyle, ile chcesz, wiedząc, że nie zużyją więcej pamięci RAM niż potrzeba. Chociaż całkowite zużycie pamięci będzie wyższe dla wielu małych baz danych w porównaniu do dużej pojedynczej bazy danych, przypuszczam, że różnica nie będzie zbyt ważna. YMMV.

W zależności od tego, co uważasz za „drogie”.

Baza danych niekoniecznie musi być drogim komercyjnym serwerem bazy danych (zdaniem Oracle), niekoniecznie musi być sprawą wymagającą dużej ilości zasobów. W zależności od wymagań możesz używać bazy danych SQLite, a nawet systemu plików jako trwałego magazynu danych.

Wszystkie te usługi mogą również współdzielić jedną instancję bazy danych / serwer i mieć tylko izolowane schematy na usługę.

Kluczowym argumentem jest to, że usługa musi posiadać i kontrolować swoje dane. Jak to osiągnąć, jest kwestią wyboru i szczegółów technicznych.

Najlepszym sposobem, w jaki usługa może posiadać i kontrolować swoje dane, jest posiadanie własnej „osobistej” bazy danych. Pozwala to na pełną swobodę wyboru technologii i ewolucji schematów danych. Jedynym sposobem, w jaki każda inna usługa może uzyskać dostęp do danych należących do usługi, jest prośba o dane z usługi. W ten sposób, jeśli konieczna jest zmiana wewnętrznej reprezentacji danych, można ją łatwo zmienić i żadne inne usługi nie ulegną awarii.

Podsumowując. Posiadanie bazy danych na usługę niekoniecznie jest drogie, ani nie jest konieczne. Jest to po prostu decyzja, którą musisz podjąć w pewnym momencie podczas opracowywania mikrousług. Każdy wybór ma swoje implikacje i ograniczenia. Przestudiuj je i dokonaj własnego wyboru.