Mikrousługi: MonolithFirst?

9

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.

Jleach
źródło

Odpowiedzi:

2

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.

Berin Loritsch
źródło
13

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.

nerwowy
źródło
Wygląda na to, że zdrowy sposób postępowania z najlepszymi praktykami kodowania jest pomieszany z odrobiną ulepszonego zarządzania bazą kodów, ale nie wystarcza, by „nie trzeba aktualizować całego monolitu na ścieżce drobnej aktualizacji usługi”, czyli tam, gdzie spodziewam się tendencji mikrousług świecić. W każdym razie dobra rada, dzięki.
jleach
1
Całkowicie zgadzam się z odpowiedzią. Dobrze zbudowany i prawidłowo zmodularyzowany monolit zapewnia większość (choć nie wszystkie) korzyści, jakie mają mikrousługi. Z drugiej strony mikrousługi mają swoje własne dość duże problemy.
Milos Mrdovic
@jleach Jedną z cech dobrej modularyzacji jest niezależne wdrażanie. Jeśli musisz ponownie skompilować i ponownie wdrożyć cały monolit w celu drobnej aktualizacji modułu, robisz coś złego.
Milos Mrdovic
2
To dobre podejście. Nie buduj mikrousług ze względu na robienie mikrousług. Architekturę mikrousług należy używać do rozwiązywania problemów, ale mają one również szereg własnych problemów, więc jeśli nie jesteś gotowy / świadomy tych kompromisów, powinieneś bardzo ostrożnie opracowywać mikrousługę od podstaw.
Lie Ryan,
1
@MilosMrdovic, nawet z podejściem modułowym, nadal możesz uzyskać pewną wydajność we wdrażaniu, ponieważ nie musisz ponownie testować całego monolitu, tylko aktualizowany moduł. Jeśli moduł przejdzie przez wszystkie bramki jakości, możesz go zbudować i wysłać. Następnie twój monolit musi tylko zaktualizować swoją wersję zależności i ponownie wdrożyć. Nie będziesz musiał odbudowywać żadnych innych modułów.
jiggy
2

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.

Christian Sauer
źródło
1
„Iw takich przypadkach mikrousługę można łatwiej opracować” - czy miałeś na myśli rozmawiać o monolitach ?
amon
@amon Dziękuję, poprawiłem zdanie - mój syn przerwał mi 34235 razy, więc byłem zdezorientowany;)
Christian Sauer
Chociaż zgadzam się z twoim pierwszym zdaniem, myślę, że powinieneś wziąć pod uwagę, że nawet twój monolit powinien już być „modułowy” w środku, w przeciwnym razie po prostu nie będziesz w stanie niczego oddzielić bez upadku wszystkiego.
Walfrat,
@Walfrat Zwykle się zgadzam, ale pokusa do ponownego użycia istniejącego kodu jest znacznie większa (i trudniejsza do zmiażdżenia) w monolicie. Np. „Ojej, ktoś zdefiniował WidgetId, po prostu użyję go ponownie w moim FormId”: Ponadto nie można łatwo użyć innego języka / db do projektu, co naprawdę sprzyja myśleniu „wszyscy muszą używać wspólnych narzędzi”
Christian Sauer
1

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.

Ewan
źródło
Dzięki. Jeśli MF jest nieco stronnicze, czy jest ktoś, kogo pracę mogę studiować po przeciwnej stronie, aby uzyskać głębię perspektywy?
jleach
Nie polecałbym „celebrytów” jako źródła wiedzy. Jest ok na kilka anegdot i zabawną rozmowę, ale z mojego doświadczenia wynika, że ​​szczegół ten decyduje o sukcesie i porażce.
Ewan
0

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.

Inżynier oprogramowania
źródło
Mikrousługi faktycznie rozwiązują wiele problemów organizacyjnych. Jeśli każda usługa ma właściciela, wiesz, jak się udławić, gdy coś nie działa.
jiggy
@ jiggy: jeśli kod jest dobrze zmodularyzowany, niekoniecznie musisz podzielić go na wiele usług, aby wiedzieć, kogo zadławić.
Lie Ryan,
@ Ryan, jeśli ktoś myśli, że mikrousługi i modularyzacja są synonimami, to zupełnie nie rozumie tego.
Inżynier oprogramowania