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.
źródło
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.
źródło
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.
źródło
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.
źródło