Mikrousługi: MonolithFirst?

Badam architektury mikrousług, próbując uzyskać ogólny przegląd wszystkich zalet i wad, kiedy i dlaczego itp. Wiele informacji, które czytam / oglądam, pochodzi z ThoughtWorks (Martin Fowler, Neal Ford, i in. glin).

Większość prac Martina Fowlera na ten temat ma kilka lat, kiedy Microservices (jako nazwa programowa, jeśli nie ogólna praktyka) była jeszcze młoda, dlatego biorę dużo ziarenka soli.

Jedna rzecz w szczególności to:

Kiedy słyszę historie o zespołach korzystających z architektury mikrousług, zauważyłem wspólny wzór.

• Prawie wszystkie udane historie o mikrousługach zaczęły się od monolitu, który stał się zbyt duży i został zerwany
• Prawie wszystkie przypadki, w których słyszałem o systemie, który został zbudowany od podstaw jako mikrousługa, spowodowały poważne kłopoty.

Ten wzór doprowadził wielu moich kolegów do argumentowania, że nie powinieneś rozpoczynać nowego projektu z mikrousługami, nawet jeśli masz pewność, że Twoja aplikacja będzie wystarczająco duża, aby była opłacalna. .

(zob .: https://martinfowler.com/bliki/MonolithFirst.html - podkreślenie ich)

Teraz, 3 lata później i przy mikrousługach bardziej powszechnym terminem, czy ogólnie można się zgodzić, że nowy system jest zazwyczaj lepiej obsługiwany, ponieważ na początku mają większe (niż-mikrousługi-ale-mniejsze-niż-monolit) usługi bardziej szczegółowe w ramach ewolucyjnej miary?

Czy też istnieje norma, aby rozpocząć projekt od zera za pomocą szczegółowej architektury mikrousług, w przeciwieństwie do powyższych stwierdzeń?

Wydaje się to rozsądnym ogólnym podejściem, ale ciekawy myśli społeczności.

Jeśli Twoja firma od jakiegoś czasu zajmuje się mikrousługami, niektóre elementy mogą już zostać zbudowane i po prostu musisz je włączyć. Przykładem może być uwierzytelnianie jako usługa lub przechowywanie danych obiektów blob. W takim przypadku zdefiniowałeś już granice i ponownie używasz kodu w nowej aplikacji. To dobra rzecz.

W przypadku nowego kodu, w którym nie masz pewności, gdzie powinna być granica, utwórz ją w jednej usłudze. Jeśli zachowasz modułowość, w razie potrzeby możesz oddzielić od niej mikrousługi. Zwłaszcza, gdy znajdziesz fragmenty swojej usługi, które muszą być skalowane inaczej niż pozostałe.

Zaletą mikrousług jest to, że można dodawać instancje w celu skalowania pracy wykonywanej na żądanie. Jeśli niektóre z twoich prac pojawiają się w seriach, sensowne może być rozdzielenie ich na własne mikrousługi.

Ogólnie:

• Jeśli masz już wbudowane mikrousług, użyj ich ponownie
• Jeśli budujesz coś nowego, najpierw spraw, aby pomysł zadziałał
• Podczas budowania staraj się zachować modułowość, aby niektóre usługi można było łatwo rozbić
• Gdy budujesz, jeśli część Twojej usługi musi być w stanie skalować na żądanie w innym tempie, podziel ją na własną usługę

Zbyt często słyszymy przydatne wskazówki od inteligentnych ludzi o dobrej reputacji, takich jak Martin Fowler, a następnie przekształcamy je w twardą doktrynę, od której nie można się w żaden sposób wywrócić.

Musisz wziąć takie oświadczenia w duchu ich znaczenia. Martin Fowler próbuje ocalić ludzi przed porażeniem poprzez analizę i każe im zbudować coś, co działa najpierw. Zawsze możesz to rozdzielić później, gdy dowiesz się więcej o tym, jak naprawdę działa Twoja aplikacja.

Naj natychmiastowe cenne korzyści mikrousług można osiągnąć poprzez prostą modularyzację kodu. Możesz izolować grupy funkcji na moduły, używając dowolnego systemu modułów (maven, npm, nuget, cokolwiek). Każdy moduł może służyć jednemu celowi, mieć własne repozytorium, używać własnego schematu DB, zarządzać własną konfiguracją, mieć własne zaległości funkcji i harmonogram wydań. Nadal można je rozmieścić razem na monolicie. Jest to bardzo łatwe do opanowania obciążenie ogólne i daje pewne dobre korzyści. Większy narzut związany jest z oddzielaniem wdrożeń, co jest naprawdę cenne tylko wtedy, gdy masz wystarczająco dużo skali, aby tego wymagać. Jeśli kod jest już modułowy, migracja będzie łatwiejsza, gdy przyjdzie czas.

Moim zdaniem, korzystne może być najpierw opracowanie monolitu (lub lepiej: opracowanie części aplikacji jako monolitu).

Zdarzają się przypadki, gdy nie masz pewności co do domeny i granic problemu (np. Tworzę witrynę zarządzania statkiem, czy potrzebuję usługi statku ORAZ usługi floty, czy usługa statku jest wystarczająca?), Aw takich przypadkach monolit może być łatwiejszy do opracowania.

Powinieneś przestać to robić, jeśli chcesz wprowadzić różne technologie do mieszanki (np. Twoje istniejące części są napisane w C #, ale nowy problem wymaga uczenia maszynowego, najlepiej najlepiej z pythonem), dobrze rozumiesz domeny w twojej projektu lub waszych monolitów do ocynkowania, np. wszyscy po prostu budują ten monolit i odrzucają pojęcie oddzielnych usług.

Jestem pewien, że MF zadało kilka pytań na temat tego artykułu.

Podejrzewam, że:

Monolit z problemami związanymi z konserwacją lub skalowalnością został ulepszony poprzez podział na mikrousługi. Taki projekt prawie zawsze będzie „udany”, ponieważ nawet rozbicie małego odcinka może przynieść wymierne korzyści i możesz narysować linię pod nim, kiedy będziesz szczęśliwy.

To, czy twój pół monolit + kolejka komunikatów i kilka procesów roboczych liczy się jako „architektura Microservice”, jest argumentem, aby upuścić pub, ale na pewno będziesz to tak nazywać , gdy mówisz o projekcie.

Z drugiej strony, każdy nowy projekt, niezależnie od wybranej architektury, wiąże się z ryzykiem niespełnienia oczekiwań, więc naturalnie można oczekiwać mniejszej skuteczności. Co więcej, jeśli zacząłeś dążyć do stworzenia od podstaw „najlepszej praktyki architektury mikrousługowej”, być może zapuszczasz się w nowe technologie i trudniejsze fragmenty mikrousług.

Musimy również pamiętać, że MF pisze z dużej perspektywy OOP. Jest naturalnie sceptyczny wobec bardziej nowoczesnego podejścia rozproszonego.

W dzisiejszych czasach spodziewałbym się, że każde duże rozwiązanie biznesowe będzie zawierało element mikrousług, a tylko głupiec poleciłby ci stworzenie jednej gigantycznej aplikacji na monolit, chyba że dystrybuujesz jedną aplikację w stylu pulpitu.

Z mojego (ogromnego) doświadczenia widziałem, że wiele innych projektów kończy się niepowodzeniem z powodu problemów ludzi niż problemów technologicznych. Niestety, ludzie nie lubią ponosić porażki, dlatego często mylnie zgłaszają przyczyny niepowodzenia i obwiniają technologię.

W mojej domenie, finanse, większość nowych projektów korzysta obecnie z architektur mikrousług i wydaje się, że jest to zwycięska architektura z punktu widzenia całkowitego kosztu posiadania (TCO). Wydaje się, że projekty te nie zawodzą tak często, a kiedy to robią, podane powody często nie wymieniają architektury aplikacji jako problemu.