Witaj, hab. Zapisy na nowy strumień kursów są już otwarte w OTUS . W przeddzień rozpoczęcia kursu chcę podzielić się z Wami moim autorskim artykułem.
Wprowadzenie
Wybór stylu architektonicznego jest jedną z podstawowych decyzji technicznych przy budowie systemu informatycznego. W tym cyklu artykułów proponuję przeanalizować najpopularniejsze style architektoniczne w zastosowaniach budowlanych i odpowiedzieć na pytanie, kiedy który styl architektoniczny jest najbardziej preferowany. W trakcie prezentacji postaram się narysować logiczny łańcuch wyjaśniający rozwój stylów architektonicznych od monolitów po mikroserwisy.
Trochę historii
Jeśli spróbujesz zapytać programistów: „Po co nam mikroserwisy?”, otrzymasz wiele odpowiedzi. Usłyszysz, że mikrousługi poprawiają skalowalność, ułatwiają zrozumienie kodu, poprawiają odporność na błędy, a czasami usłyszysz, że pozwalają „oczyścić kod”. Spójrzmy na historię, aby zrozumieć cel pojawienia się mikrousług.
W skrócie mikrousługi w naszym obecnym rozumieniu powstały następująco: w 2011 roku James Lewis, analizując pracę różnych firm, zwrócił uwagę na pojawienie się nowego wzorca „mikroaplikacji”, który optymalizował SOA pod kątem przyspieszania wdrażania usługi. Nieco później, w 2012 roku, na szczycie poświęconym architekturze, nazwę wzorca zmieniono na mikroserwis. Zatem początkowym celem wprowadzenia mikroserwisów było ulepszenie tego, co osławione czas na rynek.
W 2015 roku o mikrousługach zrobiło się głośno. Według niektórych badań żadna konferencja nie odbyła się bez raportu na temat mikroserwisów. Ponadto część konferencji poświęcona była wyłącznie mikroserwisom. Obecnie wiele projektów zaczyna wykorzystywać ten styl architektoniczny, a jeśli projekt zawiera tony starszego kodu, to prawdopodobnie aktywnie prowadzona jest migracja do mikroserwisów.
Pomimo tego dość niewielka liczba programistów nadal potrafi zdefiniować pojęcie „mikroserwisu”. Ale o tym porozmawiamy trochę później...
Monolit
Styl architektoniczny kontrastujący z mikrousługami to monolit (lub wszystko w jednym). Prawdopodobnie nie ma sensu mówić, czym jest monolit, więc od razu wymienię wady tego stylu architektonicznego, który zapoczątkował dalszy rozwój stylów architektonicznych: rozmiar, łączność, wdrożenie, skalowalność, niezawodność i sztywność. Poniżej proponuję przyjrzeć się każdemu z niedociągnięć z osobna.
Rozmiar
Monolit jest bardzo duży. I zwykle komunikuje się z bardzo dużą bazą danych. Aplikacja staje się zbyt duża, aby jeden programista mógł ją w ogóle zrozumieć. Tylko ci, którzy spędzili dużo czasu pracując nad tym kodem, mogą dobrze pracować z monolitem, podczas gdy początkujący spędzą dużo czasu próbując rozgryźć monolit i nie ma gwarancji, że im się to uda. Zwykle przy pracy z monolitem zawsze trafia się jakiś „warunkowy” senior, który zna monolit mniej więcej dobrze i w ciągu półtora roku pokonuje ręce innych nowych programistów. Oczywiście taki warunkowy senior jest pojedynczym punktem awarii, a jego odejście może doprowadzić do śmierci monolitu.
Połączenia
Monolit to „wielka kula błota”, w której zmiany mogą prowadzić do nieprzewidywalnych konsekwencji. Dokonując zmian w jednym miejscu, możesz uszkodzić monolit w innym (tak samo „podrapałeś ucho, *@ odpadło”). Wynika to z faktu, że składniki monolitu łączą bardzo złożone i co najważniejsze nieoczywiste zależności.
Rozlokowanie
Rozkładanie monolitu, ze względu na złożone relacje pomiędzy jego elementami, jest długim procesem, mającym swój własny rytuał. Taki rytuał zwykle nie jest całkowicie ustandaryzowany i przekazywany jest „ustnie”.
Skalowalność
Moduły Monolith mogą mieć sprzeczne potrzeby w zakresie zasobów, co wymaga kompromisu w zakresie sprzętu. Wyobraź sobie, że masz monolit składający się z usług A i B. Usługa A wymaga rozmiaru dysku twardego, a usługa B wymaga pamięci RAM. W takim przypadku albo maszyna, na której zainstalowany jest monolit, musi obsługiwać wymagania obu usług, albo trzeba będzie 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 i 10 usług B. Znowu dwie opcje: albo stawiamy 100 pełnoprawnych monolitów, albo na niektórych wtedy usługi B będą musiały zostać wyłączone ręcznie.
Niezawodność
Ponieważ wszystkie usługi są zlokalizowane razem, jeśli monolit upadnie, wszystkie usługi ulegną upadkowi na raz. W rzeczywistości może nie jest tak źle, 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 Twojego systemu.
Bezwładność
Ze względu na wielkość monolitu przejście na nowe technologie jest trudne. W rezultacie zatrzymanie tego samego seniora jest odrębnym zadaniem. Wybrany na początku projektu stos technologiczny może stać się blokadą utrudniającą rozwój produktu.
wniosek
Następnym razem porozmawiamy o tym, jak ludzie próbowali rozwiązać te problemy, przechodząc na komponenty i architekturę SOA.
Czytaj więcej:
Źródło: www.habr.com