Cześć, Habr. W OTUS właśnie otwarto nabór na nową edycję kursu. . Przed rozpoczęciem kursu chciałbym podzielić się z Wami moim autorskim artykułem.
Wprowadzenie
Wybór stylu architektonicznego jest jednym z podstawowych decyzji technicznych przy budowie systemu informacyjnego. W tej serii artykułów proponuję omówić najpopularniejsze style architektoniczne budowy aplikacji i odpowiedzieć na pytanie, kiedy który styl architektoniczny jest najbardziej preferowany. W procesie przedstawiania postaram się przeprowadzić logiczny ciąg, który wyjaśnia rozwój stylów architektonicznych od monolitów do mikrosystemów.
Historia
Jeśli spróbujesz zapytać deweloperów: „Po co są mikrousługi?”, otrzymasz różnorodne odpowiedzi. Usłyszysz, że mikrousługi poprawiają skalowalność, ułatwiają zrozumienie kodu, zwiększają odporność na awarie, a czasami usłyszysz, że pozwalają „oczyścić kod”. Przyjrzyjmy się historii, aby zrozumieć, jaki cel przyświecał pojawieniu się mikrousług.
Mówiąc krótko, mikrousługi w naszym obecnym rozumieniu powstały w następujący sposób: w 2011 roku James Lewis, analizując prace różnych firm, zwrócił uwagę na pojawienie się nowego wzorca „micro-app”, który optymalizował SOA z punktu widzenia przyspieszenia wdrażania usług. Nieco później, w 2012 roku, na szczycie architektonicznym wzorzec został przemianowany na mikrousługę. Tak więc pierwotnym celem wprowadzenia mikrousług była poprawa tzw. time to market.
Na „fali hype'u” mikrousługi były popularne w 2015 roku. Według niektórych badań, żadna konferencja nie odbywała się bez wykładu na temat mikrousług. Co więcej, niektóre konferencje były poświęcone wyłącznie mikrousługom. Obecnie wiele projektów rozpoczyna się od zastosowania tego stylu architektonicznego, a jeśli projekt zawiera mnóstwo kodu Legacy, to na pewno następuje aktywna migracja do mikrousług.
Pomimo powyższego, wciąż stosunkowo niewielka liczba deweloperów potrafi zdefiniować pojęcie „mikrousługi”. Ale o tym porozmawiamy nieco później…
Monolit
Styl architektoniczny, który jest przeciwstawiany mikrousługom, to monolit (lub „wszystko w jednym”). Myślę, że nie ma sensu tłumaczyć, czym jest monolit, dlatego od razu wymienię wady tego stylu architektonicznego, które zainicjowały dalszy rozwój stylów architektonicznych: rozmiar, spójność, wdrażanie, skalowalność, niezawodność i sztywność. Poniżej proponuję zapoznać się z każdą z tych wad osobno.
Wymiary
Monolit jest bardzo duży. Zazwyczaj komunikuje się z ogromną bazą danych. Aplikacja staje się zbyt duża, aby mógł ją zrozumieć pojedynczy programista. Z monolitem mogą dobrze pracować tylko ci, którzy spędzili dużo czasu nad tym kodem, podczas gdy nowicjusze spędzą dużo czasu na próbach zrozumienia monolitu i nie ma pewności, że im się to uda. Zazwyczaj przy pracy z monolitem zawsze jest jakiś „względny” starszy programista, który zna monolit w miarę dobrze i pilnuje młodszych programistów przez rok lub półtora. Oczywiście, taki względny senior staje się jedynym punktem awarii, a jego odejście może doprowadzić do upadku monolitu.
Powiązanie
Monolit to „duża kula błota” (big ball of mud), zmiany w którym mogą prowadzić do nieprzewidywalnych konsekwencji. Wprowadzenie zmian w jednym miejscu może uszkodzić monolit w innym (to właśnie to „podrapałem ucho, a *@ odpadło”). Wynika to z tego, że komponenty w monolicie mają bardzo skomplikowane i, co najważniejsze, nieoczywiste zależności.
Rozmieszczenie
Wdrażanie monolitu, ze względu na skomplikowane zależności między jego komponentami, to długi proces z własnym rytuałem. Taki rytuał zazwyczaj nie jest do końca sformalizowany i przekazywany jest „z ust do ust”.
Skalowalność
Moduły monolitu mogą mieć konfliktujące potrzeby dotyczące zasobów, przez co konieczne jest szukanie kompromisu z punktu widzenia sprzętu. Wyobraź sobie, że twój monolit składa się z usług A i B. Usługa A jest wymagająca pod względem wielkości dysku twardego, a usługa B — pod względem pamięci operacyjnej. W takim przypadku albo maszyna, na którą instalowany jest monolit, musi spełniać wymagania obu usług, albo będziesz musiał ręcznie, sztucznie wyłączyć jedną z usług.
Inny przykład (bardziej klasyczny): usługa A jest znacznie bardziej popularna niż usługa B, więc chcesz, aby było 100 usług A, a 10 usług B. Znowu są dwa warianty: albo wdrażamy 100 pełnoprawnych monolitów, albo na niektórych z nich ręcznie musimy wyłączyć usługi B.
Niezawodność
Ponieważ wszystkie usługi są razem, jeśli monolit upada, to wszystkie usługi padają jednocześnie. W rzeczywistości, może to nie być takie złe, przynajmniej nie będzie częściowych awarii w systemie rozproszonym, ale z drugiej strony, z powodu błędu w funkcjonalności, z której korzysta 0,001% użytkowników, możesz stracić wszystkich użytkowników swojego systemu.
Sztywność
Z powodu rozmiaru monolitu trudno jest przejść na nowe technologie. W rezultacie, osobnym wyzwaniem staje się utrzymanie tego samego, warunkowego seniora. Wybrany na początku projektu stos technologiczny może stać się blokadą, uniemożliwiającą rozwój produktu.
Podsumowanie
Następnym razem porozmawiamy o tym, jak ludzie próbowali rozwiązać wskazane problemy, przechodząc do komponentów i SOA.
Czytaj dalej:
Źródło: habr.com
