Trans.eu: migracja architektury bez przestojów dzięki tymczasowemu serwisowi agregującemu
About the project
Trans.eu to jedna z największych giełd transportowych w Europie, łącząca codziennie tysiące przewoźników, spedytorów i dostawców ładunków. W 2017 roku firma rozpoczęła strategiczną migrację swojej platformy z monolitu na architekturę mikroserwisów. Zatrudnia kilkaset osób i obsługuje rynek ogólnoeuropejski.
Biznesowe
- Zapewnienie ciągłości danych o firmach w czasie trwania migracji – nowa platforma mikroserwisowa potrzebowała spójnego źródła informacji o kontrahentach, zanim powstały wszystkie docelowe serwisy.
- Uniezależnienie nowej platformy od starego monolitu – minimalizacja zależności między starym a nowym systemem, tak by oba mogły być rozwijane równolegle bez blokowania się nawzajem.
- Dostarczenie zagregowanych statystyk o firmach (m.in. liczba złożonych ofert) jako danych wspierających decyzje biznesowe użytkowników giełdy.
Technologiczne
- Zbudowanie od zera mikroserwisu agregującego dane o firmach z heterogenicznych źródeł: starej platformy monolitycznej i stopniowo pojawiających się nowych mikroserwisów.
- Implementacja wspólnego modelu odczytu (read model) z danymi o firmach, dostępnego dla całej nowej platformy.
- Nasłuchiwanie i przetwarzanie zdarzeń z magistrali wiadomości w czasie zbliżonym do rzeczywistego.
Customer experience
Zespół fireup.pro bardzo sprawnie podszedł do realizacji projektu. Dzięki jego zaangażowaniu możemy dalej rozwijać wykorzystanie danych w naszej grupie.
Piotr Sobala,
Product Owner, Trans.eu
From challenge
Key Challenges
Migracja etapami – nowa platforma nie mogła czekać na kompletność
Migracja etapami – nowa platforma nie mogła czekać na kompletność
Trans.eu przechodziło z monolitu na mikroserwisy, ale nowe serwisy powstawały stopniowo. Tymczasem elementy nowej platformy już działały i potrzebowały danych o firmach – adresów, danych rejestrowych, statystyk aktywności. Nie było jednego gotowego źródła tych danych po stronie nowej architektury.
Dane rozproszone po dwóch światach
Dane rozproszone po dwóch światach
Część informacji o firmach żyła w starym monolicie, część zaczynała pojawiać się w nowych mikroserwisach. CBIF musiał umieć czytać z obu tych źródeł jednocześnie i scalać je w spójny obraz, mimo że były to systemy o różnych modelach danych i sposobach dostępu.
Fasada między starą a nową platformą
Fasada między starą a nową platformą
Kluczowym wymaganiem było to, żeby nowa platforma nie wiedziała, skąd pochodzą dane. CBIF miał zachowywać się jak pełnoprawny mikroserwis nowej architektury, a wewnętrznie – pobierać część danych ze starszego systemu. To wymagało starannego zaprojektowania API i modelu danych tak, by żaden konsument nie musiał znać ani potrzebować szczegółów implementacji.
Tymczasowość jako wymaganie projektowe
Tymczasowość jako wymaganie projektowe
CBIF był projektowany z założeniem, że przestanie być potrzebny – gdy nowa platforma dojrzeje do tego stopnia, że własne mikroserwisy przejmą obsługę danych o firmach. Trzeba było zbudować rozwiązanie solidne operacyjnie, ale bez nadmiernego inwestowania w funkcje, które i tak zostałyby zastąpione.
Kluczowe wymagania funkcjonalne i niefunkcjonalne
Funkcjonalne
- Agregacja danych o firmach ze zdarzeń generowanych przez mikroserwisy (via kolejka wiadomości) oraz z baz danych starego systemu.
- Wspólny read model – ujednolicony widok danych o firmie dostępny przez REST API dla innych serwisów platformy.
- Statystyki firmowe – agregacja danych ilościowych, m.in. historia i liczba składanych ofert.
- Obsługa zdarzeń domenowych w architekturze event-driven z użyciem microbatchingu.
Niefunkcjonalne
- Wysoka dostępność - dane musiały być dostępne dla konsumentów przez cały czas działania platformy.
- Obserwowalność – monitoring i metryki produkcyjne do wykrywania problemów.
- Izolacja od legacy - zmiana lub wyłączenie starego systemu nie powinna wymuszać zmian u konsumentów CBIF.
Through the solution
Through the solution
Architektura fasady na czas przejściowy
fireup.pro zbudowało CBIF jako samodzielny mikroserwis oparty na Domain-Driven Design. Serwis nasłuchiwał zdarzeń z RabbitMQ – publikowanych zarówno przez nowe mikroserwisy, jak i przez adaptery reagujące na zmiany wstarym monolicie i na ich podstawie budował i aktualizował read model przechowywany w Elasticsearch. Konsumenci na nowej platformie korzystali wyłącznie z REST API CBIF, nie wiedząc nic o tym, skąd dane faktycznie pochodzą. Gdy nowe mikroserwisy sukcesywnie przejmowały kolejne obszary, CBIF adaptował swoje źródła bez żadnych zmian dla odbiorców.
Podejście do przetwarzania danych
Zdarzenia domenowe z kolejki wiadomości były przetwarzane w trybie microbatchingu, co pozwalało efektywnie agregować dane z wielu źródeł. Elasticsearch zapewniał szybkie odpowiedzi na zapytania o read model, a Redis wspierał cache'owanie tam, gdzie liczyła się latencja.
Konfiguracja serwisów była zarządzana przez Consul, co umożliwiało dynamiczne dostosowywanie do zmieniającego się środowiska mikroserwisowego.
Jakość i testowanie
Niezawodność CBIF była krytyczna – błędy w danych o firmach oznaczały błędy decyzji po stronie użytkowników giełdy. Zespół zastosował podejście BDD z frameworkiem Serenity, automatyzując testy API i end-to-end. Wiremock służył do izolowania testów od zewnętrznych zależności. Przeprowadzono również testy obciążeniowe weryfikujące zachowanie serwisu przy produkcyjnym wolumenie zdarzeń. Kibana i Grafana zapewniały bieżący wgląd w działanie systemu.
To the success
Technological outcomes
Nowa platforma uniezależniona od monolitu.
Żaden z konsumentów danych o firmach nie musiał integrować się bezpośrednio ze starym systemem. CBIF był jedynym punktem styku, co znacząco uprościło architekturę całej platformy w trakcie migracji.
Spójny read model przez cały czas trwania migracji.
Dane o firmach były dostępne w ujednoliconej formie od pierwszego dnia, niezależnie od stopnia zaawansowania migracji poszczególnych obszarów systemu.
Płynne wycofanie serwisu.
Kiedy nowa platforma dojrzała i własne mikroserwisy przejęły obsługę danych o firmach, CBIF został zastąpiony przez dedykowany serwis wizytówki firmy bez zakłóceń dla żadnego z konsumentów.
Korzyści biznesowe
Migracja Trans.eu mogła postępować etapami bez wymuszania synchronizacji wszystkich obszarów systemu naraz, co znacząco zmniejszyło ryzyko projektu.
Nowe elementy platformy miały dostęp do danych o kontrahentach od razu, nie czekając na zakończenie migracji całego systemu.
Tymczasowe rozwiązanie zostało zaprojektowane tak precyzyjnie, że jego wycofanie nie wymagało żadnych zmian po stronie konsumentów.
Project team
Adam
Architekt
Tech stack
Java8
Spring Boot
Maven
Spring Integration
RabbitMQ
Elasticsearch
Liquibase
Redis
Serenity
Your success is our success
See how we can build a technological advantage for your company together.
We have a team that truly knows its stuff — we'll help you find a solution that works.
Conclusions & recommendations
Tymczasowe serwisy to pełnoprawna strategia migracji.
W przypadku migracji do nowego rozwiązania nasuwają się dwie strategie albo zatrzymać starą platformę do czasu gdy nowa będzie gotowa w całości, albo budować nową w izolacji i synchronizować je dopiero na końcu. CBIF pokazuje trzecią drogę: tymczasowy serwis agregujący, który pozwala nowej platformie rosnąć bez zależności od starego systemu, a sam wycofuje się, gdy staje się zbędny.
Facade pattern chroni konsumentów przez cały czas trwania migracji.
Żaden z serwisów konsumujących dane o firmach nie wiedział, skąd one pochodzą. To pozwoliło zmieniać wewnętrzne źródła danych bez żadnych zmian po stronie odbiorców - klasyczne zastosowanie wzorca, które w kontekście migracji daje bardzo konkretną wartość operacyjną.
Event-driven architecture ułatwia agregację z wielu źródeł.
Zbieranie danych przez nasłuchiwanie zdarzeń domenowych z kolejki wiadomości, zamiast bezpośrednich zapytań do baz danych, oddzieliło CBIF od wewnętrznej struktury źródeł. Każde nowe źródło wymagało tylko publikowania odpowiednich zdarzeń bez zmian w samym serwisie agregującym.
Obserwowalność to nie opcja, tylko konieczność przy serwisach krytycznych dla platformy.
CBIF był jedynym źródłem danych o firmach dla całej nowej platformy. Grafana i Kibana pozwalały wychwycić problemy zanim zaczęły wpływać na użytkowników, co przy tak centralnej roli serwisu było warunkiem koniecznym spokojnej pracy.
