Mikrousługi a architektura monolityczna [zamknięte]

83

Poczytałem trochę o mikroserwisach i jestem trochę zaintrygowany, wydaje się, że to ciekawa koncepcja. Ale zastanawiam się, jakie są zalety i wady korzystania z mikrousług w porównaniu z architekturą monolityczną i odwrotnie.

Kiedy mikrousługi są lepsze i gdzie lepiej iść z architekturą monolityczną.

user902383
źródło
6
Martin Fawler napisał obszerny artykuł na ten temat. Gorąco zachęcam do przeczytania tego: martinfowler.com/articles/microservices.html
Kaj
Przeczytaj ten artykuł o architekturze mikroserwisów: medium.com/startlovingyourself/ ...
Bhagwati Malav
Tyle, że mikroserwis to fragment całego systemu aplikacji działający niezależnie jako serwer lub proces usługi i jest uruchamiany na klastrze serwerów. Więc jeśli błąd wystąpił w tej usłudze, jest on izolowany, a cały system nie zepsuje się całkowicie, to jest jedna zaleta oprócz współbieżności, którą możesz uzyskać.
LEMUEL ADANE

Odpowiedzi:

76

Chociaż jestem stosunkowo nowy w świecie mikrousług, postaram się odpowiedzieć na Twoje pytanie tak kompletnie, jak to możliwe.

Korzystając z architektury mikrousług, zwiększysz odsprzęganie i separację problemów. Ponieważ zbytnio dzielisz swoją aplikację.

Powoduje to, że Twoja baza kodu będzie łatwiejsza w zarządzaniu (każda aplikacja jest niezależna od innych, aby zapewnić nieprzerwane działanie). Dlatego jeśli zrobisz to dobrze , w przyszłości łatwiej będzie dodać nowe funkcje do swojej aplikacji. Podczas gdy w przypadku architektury monolitycznej może to być bardzo trudne, jeśli twoja aplikacja jest duża (i możesz założyć, że w pewnym momencie tak będzie).

Również wdrażanie aplikacji jest łatwiejsze , ponieważ niezależne mikrousługi są budowane osobno i wdrażane na oddzielnych serwerach. Oznacza to, że możesz tworzyć i wdrażać usługi, kiedy tylko chcesz, bez konieczności przebudowywania reszty aplikacji.

Ponieważ różne usługi są małe i wdrażane osobno, jest oczywiste, że łatwiej jest je skalować , z tą zaletą, że można skalować określone usługi aplikacji (z monolitem skalujesz całą „rzecz”, nawet jeśli jest to tylko określona część w ramach aplikacja, która jest nadmiernie obciążana).

Jednak w przypadku aplikacji, które nie mają stać się zbyt duże, aby można było nimi zarządzać w przyszłości. Lepiej jest zachować architekturę monolityczną. Ponieważ architektura mikrousług wiąże się z poważnymi trudnościami. Stwierdziłem, że łatwiej jest wdrażać mikrousługi, ale jest to prawdą tylko w porównaniu z dużymi monolitami. Korzystając z mikrousług, masz dodatkową złożoność dystrybucji usług na różne serwery w różnych lokalizacjach i musisz znaleźć sposób na zarządzanie tym wszystkim. Budowanie mikrousług pomoże Ci na dłuższą metę, jeśli Twoja aplikacja stanie się duża, ale w przypadku mniejszych aplikacji po prostu łatwiej jest pozostać monolitycznym.

Kaj
źródło
21
Z mojego doświadczenia (i pracowałem nad obydwoma rodzajami baz kodu) jest to, że monolit jest znacznie prostszy: baza kodu jest znacznie łatwiejsza w zarządzaniu (jest jej znacznie mniej!), Łatwiej jest dodawać funkcje (wystarczy je dodać jedno miejsce i nie musisz definiować międzyprocesowych interfejsów API dla wszystkiego), a wdrażanie jest dużo łatwiejsze (wdrażasz tylko na jednym zestawie serwerów, a nie na pół tuzina typów). Odpowiedź @ Paulo jest znacznie bardziej kompletna!
Ben Hoyt,
„Również wdrażanie aplikacji jest łatwiejsze, ponieważ niezależnie budujesz niezależne mikrousługi i wdrażasz je na oddzielnych serwerach. Oznacza to, że możesz tworzyć i wdrażać usługi w dowolnym momencie bez konieczności przebudowywania reszty aplikacji”. - Jeśli masz kilka typów wdrożeń dla różnych usług, ogólnie rzecz biorąc, wdrażanie jest trudniejsze, a nie łatwiejsze. Mając jedną konfigurację CI w porównaniu z wieloma, jest łatwiejsza w utrzymaniu.
Michael
Najlepszy przypadek podziału monolitu na wiele usług, gdy istnieją całkowicie niezależne funkcjonalności. Jeśli nie pozbyłeś się najpierw zależności, możesz napotkać najgorszy przypadek - rozproszony monolit (ścisłe sprzężenie - trywialna zmiana = zmiana każdej usługi). Zobacz więcej szczegółów: Kryterium podziału
mikrousług
Ta odpowiedź nie jest neutralna, ponieważ można tworzyć aplikacje modułowe bez mikrousług. Baza kodu nie jest mniejsza, ponieważ wymusza się API usługi zamiast innej formy umowy, usługi EJB lub Corba również dopuszczają modułowość. Z drugiej strony, rzekoma prostota wdrożenia samodzielnego pliku binarnego, który zawiera serwer aplikacji, odbywa się kosztem elastyczności i jest obciążona rozdziałem ról między programistami i inżynierami ds. Produkcji / wsparcia.
Jose Manuel Gomez Alvarez
160

Jest to bardzo ważne pytanie, ponieważ kilka osób zostaje zwabionych przez cały szum wokół mikrousług i trzeba rozważyć kompromisy. Jakie są więc zalety i wyzwania mikrousług (w porównaniu z modelem monolitycznym)?

Korzyści

  • Możliwość wdrażania: większa elastyczność we wdrażaniu nowych wersji usługi dzięki krótszym cyklom kompilacji, testowania i wdrażania. Ponadto elastyczność w stosowaniu konfiguracji zabezpieczeń, replikacji, trwałości i monitorowania specyficznych dla usługi.
  • Niezawodność : błąd mikrousługi wpływa na samą mikrousługę i jej konsumentów, podczas gdy w modelu monolitycznym błąd usługi może spowodować uszkodzenie całego monolitu.
  • Dostępność : wdrożenie nowej wersji mikrousługi wymaga krótkich przestojów, podczas gdy wdrożenie nowej wersji usługi w monolicie wymaga zwykle wolniejszego restartu całego monolitu.
  • Skalowalność : każdą mikrousługę można skalować niezależnie przy użyciu pul, klastrów, siatek. Charakterystyka wdrożenia sprawia, że ​​mikrousługi doskonale pasują do elastyczności chmury.
  • Modyfikowalność : większa elastyczność w korzystaniu z nowych ram, bibliotek, źródeł danych i innych zasobów. Ponadto mikrousługi są luźno powiązanymi, modułowymi komponentami dostępnymi tylko za pośrednictwem ich umów, a zatem mniej podatnymi na przekształcenie się w wielką kulę błota.
  • Zarządzanie : wysiłek związany z tworzeniem aplikacji jest podzielony na mniejsze zespoły, które pracują bardziej niezależnie.
  • Autonomia projektowa : zespół ma swobodę stosowania różnych technologii, struktur i wzorców do projektowania i wdrażania każdej mikrousługi oraz może niezależnie zmieniać i ponownie wdrażać każdą mikrousługę

Wyzwania

  • Możliwość rozmieszczania : jest znacznie więcej jednostek wdrożeniowych, więc istnieją bardziej złożone zadania, skrypty, obszary transferu i pliki konfiguracyjne do nadzorowania w celu wdrożenia. (Z tego powodu ciągłe dostarczanie i DevOps są wysoce pożądane w przypadku projektów mikrousług).
  • Wydajność : usługi prawdopodobnie będą musiały komunikować się przez sieć, podczas gdy usługi w monolicie mogą korzystać z połączeń lokalnych. (Z tego powodu projekt powinien unikać „gadatliwych” mikrousług).
  • Modyfikowalność : zmiany w umowie z większym prawdopodobieństwem będą miały wpływ na konsumentów rozmieszczonych gdzie indziej, podczas gdy w modelu monolitycznym konsumenci z większym prawdopodobieństwem będą znajdować się w monolicie i zostaną wdrożeni razem z usługą. Ponadto mechanizmy zwiększające autonomię, takie jak ostateczna spójność i wywołania asynchroniczne, zwiększają złożoność mikrousług.
  • Testowalność : testy integracji są trudniejsze do skonfigurowania i uruchomienia, ponieważ mogą obejmować różne mikrousługi w różnych środowiskach wykonawczych.
  • Zarządzanie : nakład pracy związany z zarządzaniem operacjami wzrasta, ponieważ istnieje więcej komponentów wykonawczych, plików dziennika i interakcji punkt-punkt do nadzorowania.
  • Użycie pamięci : kilka klas i bibliotek jest często replikowanych w każdym pakiecie mikrousług, a ogólny ślad pamięci wzrasta.
  • Autonomia w czasie wykonywania: w monolicie ogólna logika biznesowa jest połączona. W przypadku mikrousług logika jest rozłożona na mikrousługi. Tak więc, jeśli wszystko inne jest równe, jest bardziej prawdopodobne, że mikrousługa będzie współdziałać z innymi mikrousługami w sieci - ta interakcja zmniejsza autonomię. Jeśli interakcja między mikrousługami wiąże się ze zmianą danych, potrzeba ustanowienia granic transakcyjnych dodatkowo zagraża autonomii. Dobrą wiadomością jest to, że aby uniknąć problemów z autonomią środowiska uruchomieniowego, możemy zastosować techniki, takie jak spójność ostateczna, architektura sterowana zdarzeniami, CQRS, pamięć podręczna (replikacja danych) i wyrównywanie mikrousług z kontekstami ograniczonymi DDD. Techniki te nie są nieodłączne dla mikrousług, ale zostały zasugerowane przez praktycznie każdego autora, którego czytałem.

Kiedy zrozumiemy te kompromisy , jest jeszcze jedna rzecz, którą musimy wiedzieć, aby odpowiedzieć na drugie pytanie: co jest lepsze, mikrousługi czy monolit? Musimy znać niefunkcjonalne wymagania (wymagania atrybutów jakości) aplikacji. Kiedy zrozumiesz, na przykład, jak ważna jest wydajność w porównaniu ze skalowalnością, możesz rozważyć kompromisy i podjąć świadomą decyzję projektową.

Paulo Merson
źródło
Hej, interesująca odpowiedź. Zastanawiałem się, czy występy były aż tak różne, czy nie. Ponieważ mikrousługi wymagają wymiany sieciowej, gdy nie jest to monolityczne. Jeśli jednak masz milion żądań, to nawet jeśli masz wymiany sieciowe, przetwarzanie zostanie podzielone przez mikrousługi, w których monolit musi obsługiwać pełne przetwarzanie żądań, prawda? Jeśli weźmiemy proste uwierzytelnianie, wykorzystałoby ono część całego bloku, w której mikrousługi po prostu dałyby część. Czy zatem perf monolityczne spada tak bardzo w porównaniu z mikrousługami, gdy rośnie ilość żądań?
Emixam
4
Nie do końca rozumiem komentarz, ale chodzi o porównanie wydajności tej samej funkcjonalności zaimplementowanej i wdrożonej jako zestaw mikrousług z zestawem komponentów w ramach tego samego monolitu. Wszystko inne jest równe, w tym przypadku wydajność (w szczególności czas odpowiedzi) wydaje się być lepsza w podejściu monolitycznym ze względu na możliwość wywołań lokalnych w przeciwieństwie do połączeń zdalnych wymaganych przez mikrousługi.
Paulo Merson,
1
Długie łańcuchy wywołań obejmujące wiele mikrousług to anty-wzorzec, którego należy unikać i można to zrobić w określony sposób. Dlatego czas odpowiedzi nie powinien się pogorszyć dzięki mikrousługom. Tylko, prawdopodobnie użyjesz więcej sprzętu do obsługi tego samego obciążenia. Dodatkowy koszt sprzętu przynosi jednak rzeczy, których nie można uzyskać tak łatwo w przypadku monolitów (jeśli prawidłowo wykonujesz mikrousługi): lepsze właściwości skalowania w poziomie, wyższa odporność i niezawodność oraz znacznie krótsze cykle wydawania.
user625488
11

@Luxo jest na miejscu. Chciałbym tylko zaproponować niewielką zmianę i przedstawić perspektywę organizacyjną. Mikrousługi nie tylko pozwalają na rozdzielenie aplikacji, ale mogą również pomóc na poziomie organizacyjnym. Na przykład organizacja byłaby w stanie podzielić się na wiele zespołów, z których każdy może rozwijać się na zestawie mikrousług, które zespół może zapewnić.

Na przykład w większych sklepach, takich jak Amazon, możesz mieć zespół ds. Personalizacji, zespół e-commerce, zespół usług infrastrukturalnych itp. Jeśli chcesz skorzystać z mikrousług, Amazon jest tego bardzo dobrym przykładem. Jeff Bezos zobowiązał zespoły do ​​komunikowania się z usługami innego zespołu, jeśli potrzebują dostępu do współdzielonej funkcjonalności. Zobacz tutaj krótki opis.

Ponadto inżynierowie z Etsy i Netflix również przeprowadzili małą debatę w czasach, gdy mikrousługi kontra monolit na Twitterze. Debata jest trochę mniej techniczna, ale może również dostarczyć kilku spostrzeżeń.

Will C
źródło