Wygląda na to, że szczyt szumu na mikroserwisy mamy już za sobą. Nie czytamy już kilka razy w tygodniu postów „Jak przeniosłem swój monolit na 150 usług”. Teraz coraz częściej słyszę zdroworozsądkowe myśli: „Nie nienawidzę monolitu, zależy mi tylko na efektywności”. Zaobserwowaliśmy nawet kilka migracji . Przechodząc z jednej dużej aplikacji do wielu mniejszych usług, będziesz musiał rozwiązać kilka nowych problemów. Wymienimy je możliwie najkrócej.
Otoczenie: od podstaw chemii po mechanikę kwantową
Konfigurowanie podstawowej bazy danych i aplikacji z procesem w tle było dość prostym procesem. Publikuję plik Readme na Githubie - i często w ciągu godziny, najwyżej kilku godzin wszystko działa i rozpoczynam nowy projekt. Dodawanie i uruchamianie kodu, przynajmniej dla środowiska początkowego, odbywa się pierwszego dnia. Ale jeśli zapuścimy się w mikrousługi, początkowy czas uruchomienia gwałtownie się wydłuży. Tak, teraz mamy Dockera z orkiestracją i klastrem maszyn K8, ale dla początkującego programisty wszystko to jest znacznie bardziej skomplikowane. Dla wielu juniorów jest to obciążenie, które tak naprawdę jest niepotrzebną komplikacją.
System nie jest łatwy do zrozumienia
Skupmy się na chwilę na naszym juniorze. W przypadku aplikacji monolitycznych, jeśli pojawił się błąd, łatwo było go wyśledzić i od razu przejść do debugowania. Teraz mamy usługę, która komunikuje się z inną usługą, która kolejkuje coś na magistrali komunikatów, która przetwarza inną usługę — i wtedy pojawia się błąd. Musimy złożyć wszystkie te elementy w całość, aby ostatecznie dowiedzieć się, że usługa A działa w wersji 11, a usługa E już czeka na wersję 12. To bardzo różni się od mojego standardowego skonsolidowanego dziennika: konieczność użycia interaktywnego terminala/debuggera do przejścia przez cały proces krok po kroku. Debugowanie i zrozumienie stały się z natury trudniejsze.
Jeśli nie da się tego debugować, może je przetestujemy
Ciągła integracja i ciągły rozwój stają się obecnie codziennością. Większość nowych aplikacji, które widzę, automatycznie tworzy i uruchamia testy z każdą nową wersją i wymaga przeprowadzenia testów i sprawdzenia ich przed rejestracją. Są to wspaniałe procesy, których nie należy porzucać i które były dużą zmianą dla wielu firm. Ale teraz, aby naprawdę przetestować usługę, muszę pobrać pełną działającą wersję mojej aplikacji. Pamiętasz tego nowego inżyniera z klastrem K8 obejmującym 150 usług? Cóż, teraz nauczymy nasz system CI, jak wywołać wszystkie te systemy, aby sprawdzić, czy wszystko naprawdę działa. To prawdopodobnie zbyt duży wysiłek, więc przetestujemy każdą część z osobna: jestem pewien, że nasze specyfikacje są wystarczająco dobre, interfejsy API są czyste, a awaria usługi jest izolowana i nie będzie miała wpływu na inne.
Wszystkie kompromisy mają dobry powód. Prawidłowy?
Powodów przejścia na mikroserwisy jest wiele. Widziałem to, aby zapewnić większą elastyczność, skalowanie zespołów, wydajność i zapewnić lepszą trwałość. Ale w rzeczywistości zainwestowaliśmy dziesięciolecia w narzędzia i praktyki, aby opracować monolity, które wciąż ewoluują. Współpracuję ze specjalistami w różnych technologiach. Zwykle mówimy o skalowaniu, ponieważ ogranicza się ono do limitów pojedynczego węzła bazy danych Postgres. Większość rozmów dotyczy .
Ale zawsze jestem zainteresowany poznaniem ich architektury. Na jakim etapie przejścia na mikroserwisy są? Interesujące jest to, że coraz więcej inżynierów twierdzi, że są zadowoleni ze swojej monolitycznej aplikacji. Wiele osób odniesie korzyści z mikrousług, a korzyści przewyższą przeszkody na ścieżce migracji. Ale osobiście proszę o moją monolityczną aplikację, miejsce na plaży - i jestem w pełni szczęśliwy.
Źródło: www.habr.com