Mikrousługi a architektura monolityczna [zamknięte]

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ą.

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.

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ą.

@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ń.