19 września w Moskwie pierwsze spotkanie tematyczne HUG (Highload++ User Group), które było poświęcone mikroserwisom. Odbyła się prezentacja „Operowanie mikrousługami: rozmiar ma znaczenie, nawet jeśli masz Kubernetes”, w której podzieliliśmy się bogatym doświadczeniem Flant w zakresie obsługi projektów z architekturą mikrousług. Przede wszystkim przyda się wszystkim programistom, którzy zastanawiają się nad zastosowaniem tego podejścia w swoim obecnym lub przyszłym projekcie.
Przedstawiamy (50 minut, znacznie więcej informacji niż artykuł), a także główny wyciąg z niego w formie tekstowej.
Uwaga: filmy i prezentacje są również dostępne na końcu tego wpisu.
Wprowadzenie
Zwykle dobra historia ma początek, główny wątek i zakończenie. To sprawozdanie przypomina raczej preludium i to tragiczne. Należy również zauważyć, że zapewnia spojrzenie na mikrousługi z zewnątrz. eksploatacja.
Zacznę od tego wykresu, którego autor (w 2015 r.) Martin Fowler:
Pokazuje, jak w przypadku aplikacji monolitycznej, która osiąga określoną wartość, produktywność zaczyna spadać. Mikrousługi różnią się tym, że początkowa produktywność w ich przypadku jest niższa, ale wraz ze wzrostem złożoności spadek wydajności nie jest dla nich tak zauważalny.
Dodam do tego wykresu dla przypadku korzystania z Kubernetes:
Dlaczego aplikacja z mikroserwisami jest lepsza? Bo taka architektura stawia przed architekturą poważne wymagania, które z kolei doskonale pokrywają możliwości Kubernetesa. Z drugiej strony część tej funkcjonalności przyda się w przypadku monolitu, zwłaszcza, że typowy monolit dzisiaj nie jest do końca monolitem (szczegóły będą w dalszej części raportu).
Jak widać końcowy wykres (gdy w infrastrukturze z Kubernetesem znajdują się zarówno aplikacje monolityczne, jak i mikroserwisowe) nie różni się zbytnio od pierwotnego. W dalszej części porozmawiamy o aplikacjach obsługiwanych przy użyciu Kubernetesa.
Przydatne i szkodliwe mikrousługi
A oto główna myśl:
Co to jest normalne architektura mikrousług? Powinno przynieść Ci to realne korzyści, zwiększając efektywność Twojej pracy. Wracając do wykresu, oto on:
Jeśli do niej zadzwonisz użyteczne, to po drugiej stronie wykresu będzie szkodliwy mikrousługi (zakłócają pracę):
Wracając do „głównej idei”: czy w ogóle warto ufać mojemu doświadczeniu? Od początku tego roku szukałem 85 projektów. Nie wszystkie z nich były mikroserwisami (około jedna trzecia do połowy z nich miała taką architekturę), ale i tak jest to duża liczba. My (firma Flant) jako outsourcerzy jesteśmy w stanie zaobserwować szeroką gamę aplikacji tworzonych zarówno w małych firmach (z 5 programistami), jak i dużych (~500 programistów). Dodatkową korzyścią jest to, że aplikacje te żyją i ewoluują na przestrzeni lat.
Dlaczego mikroserwisy?
Na pytanie o zalety mikroserwisów nie ma od wspomnianego już Martina Fowlera:
- jasne granice modułowości;
- niezależne wdrożenie;
- swobodę wyboru technologii.
Dużo rozmawiałem z architektami oprogramowania i programistami i pytałem, dlaczego potrzebują mikrousług. I sporządziłem listę ich oczekiwań. Oto co się stało:
Jeśli opiszemy niektóre punkty „w doznaniach”, to:
- jasne granice modułów: tutaj mamy straszny monolit, a teraz wszystko będzie ładnie poukładane w repozytoriach Git, w których wszystko jest „na półkach”, ciepłe i miękkie nie mieszają się;
- niezależność wdrożeniowa: będziemy mogli samodzielnie wdrażać usługi, dzięki czemu rozwój będzie przebiegał szybciej (równolegle publikujemy nowe funkcje);
- niezależność programistyczna: tę mikrousługę możemy przekazać jednemu zespołowi/programiście, a drugą drugiemu, dzięki czemu możemy rozwijać się szybciej;
- боwiększa niezawodność: jeśli nastąpi częściowa degradacja (upadek jednego mikroserwisu na 20), wówczas tylko jeden przycisk przestanie działać, a system jako całość będzie nadal działał.
Typowa (szkodliwa) architektura mikrousług
Aby wyjaśnić, dlaczego rzeczywistość nie jest taka, jakiej oczekujemy, przedstawię kolektyw obraz architektury mikroserwisowej oparty na doświadczeniach z wielu różnych projektów.
Przykładem może być abstrakcyjny sklep internetowy, który będzie konkurował z Amazonem lub przynajmniej OZONEM. Architektura mikroserwisów wygląda następująco:
Z różnych powodów te mikrousługi są pisane na różnych platformach:
Ponieważ każda mikrousługa musi mieć autonomię, wiele z nich potrzebuje własnej bazy danych i pamięci podręcznej. Ostateczna architektura wygląda następująco:
Jakie są jego konsekwencje?
Fowler też to ma — o „opłacie” za korzystanie z mikroserwisów:
I zobaczymy, czy nasze oczekiwania zostały spełnione.
Jasne granice modułów...
Ale ile mikrousług faktycznie musimy naprawić?wdrożyć zmianę? Czy potrafimy w ogóle zrozumieć, jak wszystko działa bez rozproszonego modułu śledzącego (w końcu każde żądanie jest przetwarzane przez połowę mikroserwisów)?
Jest wzór”„, a tutaj okazało się, że jest to rozsypana bryła brudu. Aby to potwierdzić, oto przybliżona ilustracja przebiegu żądań:
Niezależność wdrażania...
Technicznie udało się to osiągnąć: możemy wdrożyć każdy mikroserwis osobno. Ale w praktyce trzeba wziąć pod uwagę, że zawsze się toczy wiele mikroserwisówi musimy to wziąć pod uwagę kolejność ich wdrażania. Mówiąc ogólnie, musimy przetestować w oddzielnym obwodzie, czy wdrażamy wersję we właściwej kolejności.
Swoboda wyboru technologii...
Jest. Pamiętaj tylko, że wolność często graniczy z bezprawiem. Bardzo ważne jest, aby nie wybierać technologii tylko po to, aby się nimi „bawić”.
Niezależność rozwoju...
Jak wykonać pętlę testową dla całej aplikacji (przy tak dużej liczbie komponentów)? Ale nadal musisz być na bieżąco. Wszystko to prowadzi do tego, że rzeczywista liczba obwodów testowych, które w zasadzie możemy zawierać, okazuje się minimalne.
A co powiecie na wdrożenie tego wszystkiego lokalnie?.. Okazuje się, że często programista wykonuje swoją pracę samodzielnie, ale „na chybił trafił”, bo zmuszony jest poczekać, aż obwód będzie wolny do testów.
Oddzielne skalowanie...
Tak, ale jest to ograniczone w obszarze używanego systemu DBMS. W podanym przykładzie architektury Cassandra nie będzie miała problemów, ale MySQL i PostgreSQL będą.
Боwiększa niezawodność...
Nie tylko awaria jednego mikroserwisu w rzeczywistości często zakłóca prawidłowe funkcjonowanie całego systemu, ale pojawia się także nowy problem: zapewnienie odporności na błędy każdej mikrousługi jest bardzo trudne. Ponieważ mikroserwisy wykorzystują różne technologie (memcache, Redis itp.), dla każdego trzeba wszystko przemyśleć i wdrożyć, co oczywiście jest możliwe, ale wymaga ogromnych zasobów.
Załaduj wymierność...
To jest naprawdę dobre.
„Lekkość” mikroserwisów...
Mamy nie tylko ogromne obciążenie sieci (mnożą się żądania DNS itp.), ale także z powodu wielu podzapytań, które uruchomiliśmy replikować dane (pamięci podręczne sklepów), co doprowadziło do powstania znacznej ilości miejsca do przechowywania.
A oto efekt spełnienia naszych oczekiwań:
Ale to nie wszystko!
Ponieważ:
- Najprawdopodobniej będziemy potrzebować magistrali wiadomości.
- Jak wykonać spójną kopię zapasową we właściwym momencie? Jedyny real opcją jest wyłączenie ruchu w tym celu. Ale jak to zrobić na produkcji?
- Jeśli mówimy o wsparciu kilku regionów, to zorganizowanie zrównoważonego rozwoju w każdym z nich jest zadaniem bardzo pracochłonnym.
- Pojawia się problem dokonywania scentralizowanych zmian. Na przykład, jeśli będziemy musieli zaktualizować wersję PHP, będziemy musieli zatwierdzić każde repozytorium (a jest ich dziesiątki).
- Wzrost złożoności operacyjnej jest od razu wykładniczy.
Co z tym wszystkim zrobić?
Zacznij od aplikacji monolitycznej. Doświadczenie Fowlera że prawie wszystkie udane aplikacje mikrousługowe zaczynały jako monolit, który stawał się zbyt duży, a następnie ulegał zniszczeniu. Jednocześnie prawie wszystkie systemy budowane od początku jako mikroserwisy prędzej czy później napotykały poważne problemy.
Kolejną cenną myślą jest to, że aby projekt o architekturze mikroserwisowej odniósł sukces, trzeba bardzo dobrze to wiedzieć i tematyka oraz jak tworzyć mikroserwisy. A najlepszym sposobem na naukę danego obszaru jest stworzenie monolitu.
Ale co jeśli już jesteśmy w takiej sytuacji?
Pierwszym krokiem do rozwiązania problemu jest zgoda na niego i zrozumienie, że jest to problem i że nie chcemy już dłużej cierpieć.
Jeśli w przypadku przerośniętego monolitu (kiedy skończyła nam się możliwość dokupienia do niego dodatkowych zasobów) go wytniemy, to w tym przypadku sytuacja okazuje się odwrotna: gdy nadmierne mikroserwisy już nie pomagają, a wręcz przeszkadzają – odetnij nadmiar i powiększ!
Na przykład dla omówionego powyżej zbiorowego obrazu...
Pozbądź się najbardziej wątpliwych mikrousług:
Połącz wszystkie mikrousługi odpowiedzialne za generowanie frontendu:
... w jeden mikroserwis napisany w jednym (nowoczesnym i normalnym, jak sam myślisz) języku/frameworku:
Będzie miał jeden ORM (jeden DBMS) i najpierw kilka aplikacji:
... ale ogólnie możesz tam przenieść znacznie więcej, uzyskując następujący wynik:
Co więcej, w Kubernetesie uruchamiamy to wszystko w oddzielnych instancjach, co oznacza, że nadal możemy mierzyć obciążenie i skalować je oddzielnie.
Podsumowanie
Spójrz na szerszy obraz. Bardzo często wszystkie te problemy z mikroserwisami powstają dlatego, że ktoś podjął się ich zadania, ale chciał „pobawić się mikroserwisami”.
W słowie „mikrousługi” część „mikro” jest zbędna.. Są „mikro” tylko dlatego, że są mniejsze od ogromnego monolitu. Ale nie myśl o nich jak o czymś małym.
Na koniec wróćmy do pierwotnego wykresu:
Notatka na nim napisana (w prawym górnym rogu) sprowadza się do tego, że umiejętności zespołu realizującego Twój projekt są zawsze najważniejsze — odegrają kluczową rolę w wyborze pomiędzy mikroserwisami a monolitem. Jeśli zespół nie będzie miał wystarczających umiejętności, ale zacznie tworzyć mikroserwisy, historia na pewno będzie fatalna.
Filmy i slajdy
Film z wystąpienia (~50 minut; niestety nie oddaje licznych emocji zwiedzających, które w dużej mierze zadecydowały o nastroju relacji, ale tak właśnie jest):
Prezentacja raportu:
PS
Inne relacje na naszym blogu:
- «» (Dmitry Stolyarov; 28 maja 2018 na RootConf);
- «» (Dmitry Stolyarov; 7 listopada 2017 w HighLoad++);
- «» (Dmitry Stolyarov; 6 czerwca 2017 na RootConf);
- «» (Dmitry Stolyarov; 8 listopada 2016 w HighLoad++);
- «» (Dmitry Stolyarov; 31 maja 2016 na RootConf).
Mogą Cię zainteresować także następujące publikacje:
- «";
- «";
- «".
Źródło: www.habr.com