Podróż Shoprocket do mikrousług: Część 1

Kilka miesięcy po rozpoczęciu pracy w Shoprocket zaczynałem się frustrować. Mieliśmy aplikację PHP, nad którą pracował nasz mały zespół utalentowanych programistów rozproszonych po całym świecie. Dlaczego byłem sfrustrowany? Wydawało mi się, że poprawki błędów generowały kolejne błędy, integracja nowych funkcji nie była tak prosta, jak mogłaby być, a wdrożenia były rzadkie i stresujące. Powodem tych problemów był mocno sprzężony kod.

Mieliśmy monolityczną aplikację, a prawie cały nasz kod znajdował się w jednym repozytorium Github. Aktualizacje lub poprawki jednej funkcji często wymagały zmian w kilku miejscach. W celu testowania stosowaliśmy proces przeglądu rówieśniczego, w którym co najmniej dwóch innych programistów musiało zatwierdzić gałąź, zanim została połączona z główną i wdrożona. Wszystko to oznaczało, że gdy błędy udawało się wkradnąć w ukrycie, często trudno było zlokalizować źródło problemu. A kiedy już to zrobiliśmy, poprawki musiały przejść przez ten sam proces, a cała aplikacja musiała zostać ponownie wdrożona.

Będąc ambitnym młodym programistą, zawsze szukającym nowości, kiedy natknąłem się na mikroserwisy, pomyślałem, że ten styl architektoniczny rozwiąże wszystkie nasze problemy. Nie ma formalnej definicji mikroserwisów, ale z moich badań wynika, że architektura mikroserwisów to sposób projektowania aplikacji jako rozproszonych systemów niezależnych usług, z których każda jest wysoce wyspecjalizowana i ma własny cykl życia. Dla czytelników, którzy chcą szczegółowego wprowadzenia do tego pojęcia, polecam doskonały artykuł Martina Fowlersa.

Było wiele aspektów mikroserwisów, którymi byłem zainteresowany, ale szczególnie dwa: Po pierwsze, pomysł podziału aplikacji na usługi z bardzo wyraźnymi granicami. To zmniejsza szansę na wyciek logiki specyficznej dla jednego kontekstu biznesowego między komponentami, ponieważ interfejsy między granicami muszą być starannie zaplanowane. To nie jest takie proste, jak wykonywanie lokalnych wywołań funkcji; Po drugie, każdy komponent może mieć własny niezależny cykl życia. To pozwala zespołom na przejęcie odpowiedzialności za swój kod i wykorzystanie stosu technologicznego najlepiej dopasowanego do danej usługi. Ponadto umożliwia bardziej szczegółową kontrolę nad aplikacją, ponieważ zmiany można wdrażać do jednej usługi na raz i cofać bez wpływu na resztę aplikacji, jeśli coś pójdzie nie tak.

Więc byłem kupiony. Shoprocket rozbije monolit! To pierwszy z krótkiej serii wpisów na blogu, śledzących tę podróż. Mam nadzieję, że czytelnicy planujący lub przechodzący przez podobną transformację skorzystają z naszych sukcesów i porażek i będą się lepiej przygotowani do podjęcia tego wyzwania w swoich projektach.

Moim pierwszym wyzwaniem nie było techniczne, lecz ludzkie. Musiałem sprzedać pomysł reszcie zespołu. Wydawali się ciekawi, ale nie dzielili tego samego entuzjazmu i byli niechętni do rezygnacji z godzin deweloperskich na tak wczesnym etapie życia naszego produktu. Na szczęście CTO chciał, żebym przyjrzał się naszym zarządzaniem sesjami i skorzystałem z tej okazji, przekonując go, że mogę wydzielić usługę sesji.

Patrząc wstecz, być może był to zły wybór komponentu na pierwszą usługę. Nasz produkt zawiera wtyczkę javascript, która umożliwia handel elektroniczny na każdej stronie internetowej. Traktujemy sesje jako zasób, przechowując informacje sesyjne w bazie danych w celu szczegółowej analizy wskaźników KPI, takich jak wskaźniki opuszczania koszyka. Jednak ten zasób nie jest tak namacalny jak np. zamówienia czy pozycje. Ponadto używaliśmy zasobu sesji przy prawie każdej zmianie w stanie aplikacji. Oznaczało to, że usługa będzie nieuchronnie musiała często komunikować się z resztą aplikacji, czego nie przewidziałem, co utrudniło mi zadanie.

Mając przekonanego szefa, zwiększyłem moje badania nad mikroserwisami. Oprócz wspomnianego wcześniej artykułu, uznałem 'Building Microservices' Sama Newmana za niezwykle cenne źródło. Będę często odnosił się do obu w moich postach.

W swojej książce Newman zaleca najpierw przekształcić istniejącą aplikację w moduły odzwierciedlające ograniczone konteksty domeny. Następnie, gdy tylko deweloperzy będą zadowoleni, moduły można rozdzielić na własne usługi. Powodem tego jest to, że znacznie łatwiej jest rozłożyć i przepisać moduły, jeśli ich granice były źle określone, niż rozdzielić i przepisać całe usługi z całym ich dodatkowym kodem i zasobami trwałymi. Jednak z powodu ograniczeń czasowych i mojego pragnienia zbudowania komponentu własnego, zdecydowałem się na pierwszą usługę.

Wybierałem stos tylko marginalnie różniący się od tego, którego używaliśmy w naszym monolicie i zacząłem budować. Sam proces budowy przebiegł dość szybko, zajmując kilka tygodni na stworzenie autonomicznej aplikacji z interfejsem API REST. Dopiero wtedy zaczęły się prawdziwe wyzwania.

Musiałem sprawić, by usługa komunikowała się z monolitem. To w tym momencie nauczyłem się, jak ściśle związane było zarządzanie sesjami z resztą kodu. Zajęło mi trochę czasu rozłożyć istniejące wywołania funkcji i przetłumaczyć je na wywołania API. To było trudne. Ponieważ usługa sesji i monolit miały swoje własne schematy baz danych, musiałem przepisać wszelką logikę w monolicie, która korzystała z zasobów sesji w starej bazie danych, przekształcając dane na granicy aplikacji, aby zachować kompatybilność z klientami, takimi jak nasza wtyczka javascript.

Integracja usługi z naszą istniejącą aplikacją zajęła więcej czasu niż sama jej napisanie, a to nie obejmowało wielu dodatkowych czynników, które zwykle wiążą się z mikroserwisami, takich jak odkrywanie usług, logowanie i monitorowanie. Ponadto, z powodu silnego sprzężenia, wprowadzono zmiany w wielu obszarach kodu. Ponieważ zespół pracował w tym czasie równolegle nad różnymi obszarami kodu, wymagałoby to znacznie więcej pracy, aby połączyć zmiany i wdrożyć usługę sesji do produkcji.

Usługa mogła wkrótce trafić do produkcji, jednak teraz czuję, że powinienem był posłuchać rady Newmana i skupić swoje wysiłki na modularizacji naszej istniejącej aplikacji. Korzyść z posiadania jednej usługi działającej samodzielnie jest marginalna. Prawdziwą korzyść przyniesie podział całego rozwiązania, przynajmniej na usługi o dużych granicach, które komunikują się ze sobą jak najmniej. Wymaga to bardzo przemyślanych granic komponentów, a my jeszcze tam nie jesteśmy.

Wciąż jestem przekonany o idei mikroserwisów i widzę swoją próbę wydzielenia usługi jako udany eksperyment. Nauczyłem się wiele o architekturze aplikacji i modelowaniu domeny w tym procesie, oraz poprawiłem swoje zrozumienie zasad REST, między innymi. Te zmiany miały natychmiastowy wpływ na inne obszary naszego kodu.

Dla czytelników, którzy szukają zmiany, zdecydowanie zalecałbym zapoznanie się z tematem i wstrzymywanie pracy, dopóki nie będą bardzo pewni swojego istniejącego kodu i modelu domeny. Istnieją inne sposoby na wprowadzenie stabilności i odporności do monolitycznej aplikacji. Rozwój z naciskiem na testy oraz zautomatyzowane testy jednostkowe i funkcjonalne pomagają w dużej mierze. Poziomy skalowania również pomagają sprawić, by wdrożenia były nieco płynniejsze.

Shoprocket będzie kontynuował swoją podróż do mikroserwisów. Czekamy na podzielenie się z Wami więcej w części 2!