Dziedzictwo: piekło czy okazja?

Przejdź na Spring Boot, mówili… Ale jak zacząć? Migracja z samodzielnego serwera JBoss do wbudowanego serwera Tomcat nie brzmi „aż tak” źle. Z drugiej strony można na to spojrzeć tak: „jak zmienić fundamenty domu?” Wtedy wygląda to „trochę” bardziej skomplikowanie. Jak więc zacząć wprowadzać taką „fundamentalną” zmianę?

Na szczęście dla nas ETFManager ma w jakiś sposób mieszaną architekturę. Posiada moduł podstawowy – będący średniej wielkości monolitem – otoczony kilkoma mikroserwisami odpowiedzialnymi za komunikację ze światem zewnętrznym. Wszystko luźno połączone za pośrednictwem brokera przesyłania komunikatów AMQ.

Większość naszych bram korzysta już ze Spring Boot. Z drugiej strony dwóch z nich nadal pracuje nad JBossem. Ponieważ bramy są stosunkowo prostymi aplikacjami, wybraliśmy je do naszego ośrodka eksperymentalnego.

Ponieważ większość naszych bram była już napisana w Spring Boot, zdecydowaliśmy się na replikację struktury plików i konfiguracji w niezmienionej postaci. Stworzyliśmy dodatkowy katalog, który zawierał wszystkie właściwości związane ze środowiskiem, konfiguracje rejestrowania i uruchamiane skrypty wsadowe/powłokowe.

• wejście
  • odl
    • wspólne.właściwości aplikacji
    • właściwości dewelopera aplikacji
    • właściwości przedprodukcyjne aplikacji
    • właściwości produktu aplikacji
    • właściwości aplikacji-sit
    • właściwości obsługi aplikacji
    • właściwości aplikacji-uat
    • jeden
    • cii
    • xml
    • logback-dev.xml
  • źródło
    • … kod aplikacji
  • kompilacja.gradle 

dist to katalog domowy aplikacji. Wewnątrz znajdują się pliki konfiguracyjne

• common, który zawiera konfigurację współdzieloną
• konfiguracje specyficzne dla środowiska

Ponieważ wszystkie nasze środowiska, poza deweloperskim, zapisują logi na tym samym serwerze Kibana, mamy dwie konfiguracje logowania:

• dev – dla rozwoju lokalnego
• wspólne – dla każdego odległego środowiska.

Aby ułatwić uruchomienie, utworzono dwa pliki skryptów, tj. bat i sh. Zawierają proste użycie i trochę JAVA_OPTS.

Zachowanie tej konfiguracji z kodem nie wydaje się najlepszym pomysłem, ale traktujemy to jako etap przejściowy przed dokowaniem (konteneryzacją) aplikacji. Na razie wolimy nadal działać w ujednolicony sposób ze starymi aplikacjami.

Po zastosowaniu zmian w konfiguracji środowiska wykonawczego przeszliśmy do zależności Gradle. Dodaliśmy startery do rozruchu wiosennego i usunęliśmy niepotrzebne JBoss lub zduplikowane startery Spring. Cel WAR został zastąpiony za pomocą wtyczki Spring Boot Gradle przez wykonywalny plik JAR. Dodano niestandardowe zadanie spakowania i spakowania naszego katalogu `dist`. Stara konfiguracja zależności „kompiluj” została zastąpiona nową „implementacją”. Dodano klasyczną metodę `SpringApplication.run()` i voila! Robimy pierwszą jazdę próbną!

Nie. Oczywiście nie było to takie proste. Uruchomienie aplikacji ujawniło kilka brakujących definicji fasoli. Wszystkie bramy zostały podłączone do usług zewnętrznych, takich jak DB lub Message Broker. Gdy aplikacje działały na JBoss, Enterprise Server udostępniał konfiguracje umożliwiające łączenie się z tymi usługami poprzez JNDI. Było tak oczywiste, że te usługi są świadczone, że prawie zapomnieliśmy o ich istnieniu.

Na szczęście przepisanie ich nie było takie trudne:

• najpierw musieliśmy znaleźć wszystkie zależności JNDI wstrzyknięte do aplikacji
  • znaleźliśmy je w konfiguracji JBoss po zastrzykach JNDI, a następnie zwalidowaliśmy ich użycie w aplikacji po nazwach JNDI
• następnie musieliśmy zapewnić nasze fabryki połączeń:
  • Atomikos dla DB
  • RedHat Artemis dla AMQ 7
• Na koniec musieliśmy wszystko połączyć w całość za pośrednictwem naszego menadżera transakcji – tak jak poprzednio zapewnił JBoss

Przy pomocy oprogramowania Atomikos i Spring Data o otwartym kodzie źródłowym rozwiązano to małe wyzwanie i pomyślnie nawiązano połączenia z brokerami przesyłania wiadomości.

Jednak, jak wspomniałem na początku, nasza aplikacja jest dość przestarzała. Udostępnienie aplikacji źródeł danych to jedno. Inną sprawą jest udostępnianie za ich pomocą zewnętrznych (starszych) bibliotek. Jedna z bramek korzysta z komunikacji Autex FIX. . . I tylko poprzez JNDI. Szybkie wyszukiwanie… teoretycznie nie stanowi to problemu. Tomcat może zapewnić JNDI.

Dokonaliśmy konfiguracji Java z ładnym i czystym ładowaniem komponentów bean do kontekstu JNDI. Pojedyncze źródło danych było używane z JNDI i innymi komponentami bean. Wszyscy szczęśliwi, zrobiliśmy pierwszą rundę testową. Po kilku nieudanych próbach Roman odkrył, że… Kontekst JNDI Tomcata w Spring Boot jest czyszczony po inicjalizacji kontekstu. Nie znaleziono bezpośredniego rozwiązania. Tylko po to, aby ponownie napisać cały kod zależny od JNDI na coś bardziej aktualnego.

Po jeszcze bardziej szczegółowych poszukiwaniach i wielu łzach później, głęboko w otchłani internetu, znaleźliśmy to. Dołączany osadzony kontekst JNDI. Niestety, nasz święty Graal okazał się częściowo przestarzały. Po raz kolejny odważny Roman uratował sytuację, wskakując do Spring Code i udostępniając nasz zamiennik przekreślonej treści. Skończyło się na implementacji SimpleNamingContextBuilder i małego kontekstu JNDI:

• @Fasola
• @DependsOn( „Menedżer transakcji” )
• publiczny javax.naming.Context początkowyJNDIContext(
• Źródło danychŹródło danych,
• Menedżer transakcji użytkownika. Menedżer transakcji użytkownika
• ) zgłasza wyjątek NamingException {
•     Konstruktor EtfmSimpleNamingContextBuilder = nowy EtfmSimpleNamingContextBuilder();
•     konstruktor.aktywuj();
•     JndiTemplate jndiTemplate = nowy JndiTemplate();
•     javax.naming.Context ctx = jndiTemplate.getContext();
•     ctx.bind( „java:comp/env/cust/ETFMDatasourceIM“, źródło danych );
•     ctx.bind( „java:/TransactionManager”, userTransactionManager );
•     ctx.bind( „Java:comp/env/cust/UserTransaction”, userTransactionManager );
•     zwróć ctx;
• }

Zadziałało! Hacky czy nie, przełożyliśmy ponowne napisanie jednej starszej biblioteki, oszczędzając trochę czasu na nadchodzącą bitwę…

Po kilku poprawkach tu i ówdzie, aplikacja była dla Niej gotowa. Agata – nasza QA – otrzymała pakiet i rozpoczęła pełną regresję. Każdy fragment kodu został przetestowany. Każda ścieżka, przepływ, każdy proces…

Ale przede wszystkim – cała ta migracja nie odbyła się tak spontanicznie, jak mogłoby się wydawać na pierwszy rzut oka. Aplikacja jest w pewnym sensie starsza i ma całkiem sporo testów jednostkowych. Ponieważ nasze zajęcia niewiele się zmieniły, te testy nie były zbyt pomocne. Naszą drugą zaletą był stosunkowo duży zestaw testów integracyjnych i całkiem niezawodny runbook do ważnych prac ręcznych. Z takim garniturem rozpoczęliśmy migrację pewni, że w najgorszym przypadku wrócimy do punktu wyjścia. Awaria produkcyjna nie była brana pod uwagę jako opcja.

Większość funkcji działała zgodnie z oczekiwaniami, ale pojawiły się pewne zakłócenia. Wstrzyknięto niewłaściwe ziarna w nieoczekiwanych miejscach. Dokonano błędnych połączeń poprzez niewłaściwe źródła danych. Sprawdzaliśmy kod wiele razy i wszystko wyglądało dobrze. Nie było miejsca, gdzie coś mogłoby pójść nie tak. Ale nadal coś było nie tak. Nasza konfiguracja nie działała zgodnie z oczekiwaniami, ale zaczęła żyć własnym życiem.

Po kilku godzinach debugowania i porównywaniu nowego kodu ze starym znaleźliśmy go. Jak wspomniałem wcześniej, ponownie napisaliśmy konfigurację XML w Javie. Okazało się, że XML może obsłużyć znacznie więcej niż Java. Niewiele klas konfiguracyjnych i ustawiaczy automatycznego okablowania korzystało z niewłaściwych typów klas (ogólnych?). Podczas gdy XML po cichu akceptował je i obsługiwał zgodnie z życzeniem twórcy, konfiguracja Java sprzeciwiała się niewłaściwej konfiguracji. I niestety, zamiast podanych, zastosowano wartości domyślne… CICHY!

Ze względu na problem z typem nie mogliśmy rozwiązać tego problemu za pomocą prostego @Qualifier, ponieważ wykryto by niezgodność typu.

Wykrycie problemu i naprawienie powyższego przykładu jest dość proste. Jednak w rzeczywistym scenariuszu z wieloma podobnymi komponentami bean uświadomienie sobie, co się dzieje, może zająć trochę czasu. Ponadto zagnieżdżanie ziaren może znacznie utrudnić znajdowanie problemów, ponieważ niewłaściwy typ może być propagowany przez wiele zagnieżdżonych poziomów wywołania. Mimo to… lepiej zdawać sobie sprawę z takich usterek.

W miarę jak nasza aplikacja stawała się coraz bardziej stabilna, pojawił się nowy wróg – problemy z wydajnością. Po pierwsze, logowanie do aplikacji – pod załadowaną aktualnymi danymi bazę danych – stało się zadaniem dość czasochłonnym. Po drugie, w JBoss wykonanie wszystkich zadań w tle zwykle zajmowało kilka sekund. To samo w Spring Boot może zająć ponad dwadzieścia sekund.

Nasze pierwsze kroki podczas badania tych problemów z wydajnością skłoniły nas do sprawdzenia, co działo się podczas uruchamiania. Szybkie sprawdzenie procesu uruchamiania i stało się jasne, że dla setek aktywnych transakcji użytkowników aplikacja wykonywała tysiące zapytań do bazy danych. A mimo to – JBoss po prostu spisał się lepiej.

Zaczęliśmy sprawdzać konfiguracje zarówno źródeł danych, jak i pul połączeń. Napisano kilka testów dla różnych wartości. Ale wyniki nie były zadowalające. Zdobycie kilku sekund nie może się równać z szybkością JBossa. Ostatecznie zdecydowaliśmy się zoptymalizować kod ładowania. Spełniło swoje zadanie, ale i tak czuliśmy się trochę rozczarowani. Czy był to problem z konfiguracją? A może JBoss wykonał swoją pracę lepiej niż open-source'owy Atomikos?

Jednak problemy z ładowaniem aplikacji nie były jedynymi problemami związanymi z wydajnością. Niektóre procesy naszej aplikacji działają w tle i są uruchamiane przez harmonogram Quartz. Jednak od czasu do czasu niektóre z tych procesów trzeba uruchomić ręcznie.

Ręczne uruchomienie akcji na JBossie zadziałało natychmiast. Wykonanie tego samego w Spring Boot spowodowało około 20 do 30 sekund opóźnienia. Ale dlaczego? Z naszej perspektywy wydawało się, że „nic” nie trwało zbyt długo. W bazie kodu, która nie była nasza, miała miejsce długa przerwa. Znalezienie zewnętrznego kodu powodującego tę przerwę również było dla nas niemożliwe.

Oczywiście Google był naszym pierwszym strzałem. Szybkie wyszukiwanie nie znalazło rozwiązania. Jednak zagłębiając się coraz głębiej, odkryliśmy, że usunięcie @Transactional z naszej usługi ręcznego wyzwalania spełniło swoje zadanie. Mieliśmy więc wybór: zaakceptować opóźnienie lub wykonać wiele operacji w oddzielnych transakcjach.

Na szczęście dla nas czas nie był krytyczny, więc wybrano pierwszą opcję, ale sprawa wciąż czeka na rozwiązanie. Czy jest to związane z zarządzaniem transakcjami Spring Boot, czy może Atomikos? Czy będziemy w stanie dostroić to zachowanie? A może jest tak, że otwarte wersje bibliotek, z których korzystamy, po prostu działają gorzej niż ich płatne odpowiedniki?

Oczywiście ta historia nie wyczerpuje wszystkich problemów, z jakimi się spotkaliśmy. Po drodze znaleźliśmy wiele innych mniejszych problemów, o których prawdopodobnie nie warto wspominać w tym artykule. Poza tym Krzysztof i Marcin nie tylko pomogli nam podczas migracji, ale co najważniejsze, świetnie się spisali, chroniąc nas przed wszelkimi wpływami zewnętrznymi. Wzięli na swoje barki odpowiedzialność za negocjacje z klientem, skanowanie bezpieczeństwa i wszelkie inne doraźne problemy.

Dalsze testy ujawniły kilka innych drobnych problemów z wydajnością połączeń DB. Zastosowaliśmy pewne poprawki, ale i tak od czasu do czasu przypominają nam o sobie w różnych miejscach kodu. Prawdopodobnie system transakcyjny JBoss działa po prostu lepiej niż Open Source Atomikos. A może nasza konfiguracja Atomikosa nie została dostosowana tak dobrze, jak mogła.

Mimo to udało nam się. Dociskaliśmy do końca. Wycofaliśmy naszego JBossa z całego jego ogromnego potencjału, ale równie ogromnego rozmiaru i kosztów infrastruktury. I zastąpiliśmy go lekkim i darmowym Spring Bootem.

Czy było warto? Z jednej strony straciliśmy komercyjne wsparcie Red Hat i niesamowicie wyposażony serwer Java Enterprise. Z drugiej strony udało nam się obciąć niemałe koszty i usamodzielnić naszą aplikację, co było jednym z kluczowych kroków w stronę przygotowania jej do pracy w chmurze. Na krótką metę było to mnóstwo pracy, która nie wnosiła dla klienta żadnej wartości biznesowej. W dłuższej perspektywie pozwoliło to klientowi zaoszczędzić sporo kosztów i pozwoliło ewoluować projektowi w kierunku ery przetwarzania w chmurze. A to na pewno przyda się w nadchodzących latach.

Sama podróż była trudna, ale dała nam dużo doświadczenia na temat serwerów aplikacji dla przedsiębiorstw, a także samodzielnych serwerów Java.