JavaRush /Blog Java /Random-PL /Architektura mikroserwisowa: zalety i wady
Roman Beekeeper
Poziom 35

Architektura mikroserwisowa: zalety i wady

Opublikowano w grupie Random-PL
Mikrousługi to sposób na podzielenie dużej aplikacji na luźno powiązane moduły, które komunikują się ze sobą za pośrednictwem prostego interfejsu API.
Architektura mikrousług: zalety i wady - 1
Ostatnio tylko głupi ludzie nie rozmawiali o mikroserwisach. To staje się coraz bardziej popularne. Modułowy styl architektury wydaje się szczególnie dobrze pasować do środowisk opartych na chmurze i zyskuje coraz większą popularność. Zanim przejdziemy do szczegółów, spójrzmy na wszystko z lotu ptaka . Dlatego: Mikrousługi są sposobem na podzielenie dużego projektu na małe, niezależne i luźno powiązane moduły. Niezależne moduły odpowiadają za jasno określone i dyskretne zadania i komunikują się ze sobą poprzez proste i dostępne API. Innymi słowy, mikrousługi to po prostu inny styl architektoniczny do projektowania złożonych, głównie aplikacji internetowych. Ale co jest takiego złego w istniejących rozwiązaniach architektonicznych, takich jak SOA (architektura zorientowana na usługi)? Większość nowoczesnych rozwiązań dla przedsiębiorstw napisanych przy użyciu SOA wydaje się działać całkiem nieźle. To może być świetny moment, aby porozmawiać o niektórych wyzwaniach stojących obecnie przed branżą... Zacznijmy od prostego przykładu. Załóżmy, że muszę uruchomić klasyczną aplikację napisaną w Javie. Najpierw opracuję interfejs użytkownika, następnie warstwę logiki biznesowej, z kilkoma komponentami, które będą współdziałać z interfejsem użytkownika, a na koniec warstwę bazy danych, która będzie dostępna dla trwałej bazy danych. Teraz w związku z tym, że chcę uruchomić aplikację, utworzę plik WAR/EAR/JAR i zamontuję go na serwerze (takim jak JBoss, Tomcat lub WebLogic). Ponieważ odbywa się to wszystko w jednym, otrzymuję aplikację monolityczną, co oznacza, że ​​wszystkie komponenty znajdują się w jednym miejscu... Przykład na obrazku:
Architektura mikrousług: zalety i wady - 2
Najprawdopodobniej znasz już to podejście i stosowałeś je, ale pomysł jest taki, aby na tym przykładzie pokazać, z jakimi wyzwaniami będą musieli się zmierzyć programiści korzystający z tego rozwiązania architektonicznego. Aplikacja monolityczna: wyzwania i wyzwania
  • Wraz z rozwojem aplikacji rośnie także ilość napisanego kodu, co może przeciążać środowisko programistyczne za każdym razem, gdy trzeba go otworzyć. To zdecydowanie zmniejsza efektywność dewelopera.
  • Ponieważ wszystko trzeba zamontować w jednym miejscu, powoduje to, że przejście na inny język programowania lub przejście na inne technologie jest dużym problemem. Napisałeś np. aplikację w Javie, a po chwili wyszedł Kotlin i bardzo chciałeś go do niego przepisać, bo był promowany jako fajniejszy, lepszy, szybszy. Przy aplikacji monolitycznej nawet myślenie o refaktoryzacji będzie powodowało prawdziwy ból, nie mówiąc już o samym procesie. Obecnie istnieje wiele aplikacji stworzonych w ten sposób, a liczba linii kodu jest po prostu niesamowita.
  • Jeśli z jakiegoś powodu któryś ze składników przestanie działać , cała aplikacja również ulegnie awarii. Wyobraź sobie, że istnieje aplikacja internetowa posiadająca moduły takie jak autoryzacja, płatności, historia itp. I z jakiegoś powodu jeden z nich pęka. To po prostu szok dla biznesu i w efekcie dla deweloperów.
  • Skalowanie aplikacji monolitycznej można osiągnąć jedynie poprzez uruchomienie innej aplikacji tego samego typu. Ale co, jeśli potrzebujesz skalować tylko jeden komponent, a nie całą aplikację? Ile zasobów zostanie zmarnowanych?...
  • Może to mieć duży wpływ na proces rozwoju i proces instalacji aplikacji. Im większa aplikacja, tym ważniejsze jest, aby programiści mogli podzielić aplikację na mniejsze części robocze. Ponieważ wszystkie moduły w aplikacji monolitycznej są ze sobą połączone, programiści nie mogą pracować/montować tych modułów niezależnie od siebie. Ponieważ programiści są od siebie zależni, czas programowania wzrasta.
Jednocześnie jesteśmy gotowi rozważyć i zrozumieć znaczenie mikrousług, a mianowicie, w jaki sposób można je wykorzystać, aby przywrócić elastyczność utraconą w stylu SOA. Bóg Mikrousługi na ratunek Jedną z najważniejszych cech każdego rozwiązania architektonicznego jest skalowalność. Kiedy po raz pierwszy uczyłem się mikroserwisów, zobaczyłem, że wszystko jest bardzo podobne do cytatów z książki „Sztuka skalowalności”. To świetny początek i miejsce do dyskusji. W tej książce zdefiniowano tzw. model „Scalability Cube”, który opisuje trójwymiarowy system skalowalności:
Architektura mikrousług: zalety i wady - 3
Jak widać, oś X opisuje „skalowanie poziome” (które, jak widzieliśmy, jest również dostępne dla architektur monolitycznych), oś Y reprezentuje skalowanie w sensie oddzielenia różnych komponentów usługi . Ideę osi Z rozumie się wtedy, gdy dane są dzielone, a aplikacja wysyła żądania dokładnie tam, gdzie dane się znajdują. Oznacza to, że nie wszystkie znajdują się w jednym miejscu. Idea osi Y jest tą, na której skupimy się bardziej szczegółowo. Oś ta reprezentuje rozkład funkcjonalny . W tej strategii różne funkcje można uznać za niezależne usługi. Dlatego montując całą aplikację dopiero wtedy, gdy wszystko jest już gotowe, programiści mogą montować poszczególne usługi niezależnie od siebie i nie czekać, aż inni zakończą pracę nad ich modułami. Nie tylko skróci to czas programowania, ale także zapewni elastyczność w zakresie zmian i ponownego okablowania bez konieczności martwienia się o resztę komponentów aplikacji. Porównajmy ten diagram z poprzednim monolitycznym:
Architektura mikrousług: zalety i wady - 4
Mikrousługi: Korzyści Korzyści płynące z mikrousług wydają się wystarczające, aby przekonać deweloperów korporacyjnych, takich jak Amazon, Netflix, Ebay, do rozpoczęcia stosowania tego podejścia. W przeciwieństwie do monolitycznych aplikacji architektonicznych, mikrousługi:
  • Poprawia izolację awarii komponentów: duże aplikacje mogą nadal działać efektywnie nawet w przypadku awarii pojedynczego modułu.
  • Eliminuje zaangażowanie aplikacji w jeden stos technologii: jeśli chcesz wypróbować nowy stos technologii w jakiejś usłudze, śmiało. Zależności będą znacznie lżejsze niż w przypadku monolitu, a także znacznie łatwiej będzie wszystko przywrócić. Im mniej kodu w jednej aplikacji, tym łatwiej jest pracować.
  • Dzięki temu nowym pracownikom znacznie łatwiej jest zrozumieć funkcjonalność usługi.
Mikrousługi: cechy montażu i wirtualizacji Teraz rozumiemy, czym są mikrousługi. Największą zaletą jest to, że jest on montowany przez więcej niż jedno archiwum WAR/EAR/JAR. Ale jak to jest zainstalowane? Najlepszy sposób na zamontowanie mikrousług wewnątrz kontenerów. Kontener to w pełni skonfigurowany wirtualny system operacyjny ze skonfigurowanym niezbędnym środowiskiem, co pomaga izolować dostęp do zasobów systemu sprzętowego, na którym zainstalowany jest kontener. Najbardziej znanym rozwiązaniem na rynku jest oczywiście Docker . Maszyny wirtualne z IaaS (infrastruktura jako usługa) takie jak AWS również mogą się sprawdzić przy montowaniu mikroserwisów, jednak stosunkowo lekkie mikroserwisy mogą nie wykorzystywać wszystkich zasobów znajdujących się w maszynie wirtualnej, co może obniżyć opłacalność użytkowania. Możesz także zamontować swoje mikrousługi za pomocą pakietu OSGI (Open Service Gateway Initiative). W tym przypadku wszystkie mikrousługi będą działać w jednej maszynie JVM, ale wiąże się to z koniecznością znalezienia kompromisu między kontrolą a izolacją. Mikrousługi: wady To, że „to wszystko jest fajne” i „nie widzieliśmy tego wcześniej” nie oznacza, że ​​nie ma wad. Poniżej znajduje się lista możliwych obszarów problemów, jakie niesie ze sobą architektura mikrousług:
  • Tworzenie systemów rozproszonych może być trudne. Rozumiem przez to, że wszystkie komponenty są teraz niezależnymi usługami - należy bardzo ostrożnie obsługiwać żądania przechodzące pomiędzy modułami. Może zaistnieć sytuacja, w której jeden moduł nie odpowiada, co zmusza Cię do napisania dodatkowego kodu, aby uniknąć awarii systemu. Może to być trudniejsze, jeśli połączenia zdalne są wrażliwe na opóźnienia .
  • Wiele baz danych i zarządzanie transakcjami może być prawdziwym problemem.
  • testowanie aplikacji mikroserwisowych może być kłopotliwe. Korzystając z aplikacji monolitycznej wystarczy uruchomić na serwerze archiwum WAR/EAR/JAR i upewnić się, że jest ono podłączone do bazy danych. W przypadku mikrousług każda usługa musi zostać uruchomiona przed rozpoczęciem testowania.
  • Montaż aplikacji może być trudny. Mogą wymagać koordynacji wielu usług, które mogą nie być tak łatwe do zamontowania jak kontener WAR.
.... Oczywiście, stosując odpowiednie narzędzia i podejście, można uniknąć tych wad. Ale oni sami wymagają wsparcia i nie rozwiązują całkowicie wszystkich problemów. Artykuł został przetłumaczony ze strony CloudAcademy . Darmowe tłumaczenie. Każdy może wyrazić swoje przemyślenia w komentarzach. Na pewno zostaną przeczytane. Artykuł oryginalny Moje konto Github
Komentarze
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION