Jak vpodarok przeszedł z monolitu na Yii1 do architektury usług z własnym przetwarzaniem

Jak projekt Vpodarok przeszedł od monolitu do architektury usługowej

Projekt Vpodarok rozpoczął się jako zwykły sklep internetowy z bonami podarunkowymi oparty na Yii1. Z czasem przekształcił się w ekosystem z witrynami B2B, API oraz złożoną logiką biznesową. Opowiadamy, jak zespół krok po kroku wydzielił rdzeń systemu do osobnego serwisu Processing, dlaczego potrzebny był Data Connector oraz jakie kompromisy trzeba było zaakceptować podczas przejścia do modelu usługowego.

Jak wszystko się zaczęło: monolit, który stał się ERP

Pierwsze wersje Vpodarok zostały napisane w Yii1. Był to klasyczny sklep internetowy: wybór certyfikatu, złożenie zamówienia i wysyłka na e-mail.

Przez kilka lat nad bazą kodu pracowały kolejno dziesiątki zespołów. Kod stawał się coraz bardziej skomplikowany, pojawiały się niespójne rozwiązania, a utrzymanie systemu było coraz trudniejsze. Jednocześnie produkt stale się rozwijał:

• pojawiły się witryny przeznaczone dla klientów B2B;

• dodano funkcje dla firm i raportowanie;

• rozrosły się API oraz integracje z 1C;

• pojawiło się generowanie PDF oraz wysyłki partnerskie.

Nasz zespół przejął projekt i równolegle z utrzymywaniem starego rozwiązania rozpoczął budowę nowego projektu na frameworku Laravel. Później przeprowadzono płynne przejście na nowe rozwiązanie oraz całkowicie zrezygnowano ze starego systemu.

Z czasem nowa aplikacja również zaczęła rozrastać się o kolejne funkcjonalności. W projekcie uczestniczyło kilka zespołów, w tym nasz.

Aplikacja Laravel stopniowo przekształciła się w uniwersalny kombajn: obsługiwała zarówno scenariusze użytkowników, generowanie certyfikatów, jak i cały backoffice. Produkt zaczął przypominać system ERP — jednak bez wyraźnych granic odpowiedzialności pomiędzy obszarami.

W praktyce oznaczało to:

Każda zmiana zaczęła wpływać na dziesiątki innych elementów systemu. Nowi programiści mieli trudności ze zrozumieniem zależności i logiki biznesowej. Obsługa każdej nowej funkcji wymagała ręcznej synchronizacji wielu komponentów.

Kiedy stało się jasne, że trzeba coś zmienić

Punktem zwrotnym stały się ciągłe problemy z wydajnością.

Podczas dużych kampanii marketingowych lub okresów zwiększonej liczby zamówień od klientów korporacyjnych system zaczynał działać niestabilnie:

• rosło obciążenie serwera;

• zapytania do bazy danych działały wolniej;

• pojawiały się duplikujące żądania z przeglądarek i botów;

• wzrosły wymagania dotyczące bezpieczeństwa — pojawiały się podatności oraz ataki skryptowe przez otwarte publiczne endpointy.

Zespół doszedł do wniosku, że logikę należy stopniowo wydzielać z monolitu. Nie poprzez „przepisanie wszystkiego od zera”, ale poprzez stopniową ewolucję architektury.

Pierwszy etap: stabilizacja obecnego systemu

Rozpoczęliśmy od usunięcia wąskich gardeł.

Co zostało zrobione:

• Baza danych — została przeniesiona na osobny serwer po wcześniejszym pomiarze opóźnień pomiędzy centrami danych.

• Ochrona przed spamem — wdrożono mechanizm throttle z Laravel oraz zastąpiono Google reCaptcha lokalnym rozwiązaniem dostosowanym do rosyjskiego sektora.

• Monitoring — Laravel Telescope pomógł śledzić obciążenie i zachowanie aplikacji.

• Powiadomienia — krytyczne błędy zaczęły trafiać bezpośrednio na kanał zespołu w Telegramie.

Równolegle część najbardziej zasobożernych operacji została przeniesiona do asynchronicznych kolejek RabbitMQ.

Przykładowo aktywacja certyfikatów, która wcześniej była wykonywana przez cron, zaczęła być obsługiwana przez workery Supervisor działające wielowątkowo. Od razu poprawiło to stabilność oraz zmniejszyło obciążenie monolitu.

Drugi etap: uruchomienie własnego procesora

Kluczową decyzją było uruchomienie nowego serwisu — Processing.

Była to izolowana aplikacja backendowa, niezależna od interfejsu użytkownika i niedostępna bezpośrednio z zewnątrz. Stopniowo przeniesiono do niej wszystkie krytyczne funkcje biznesowe:

• zamówienia i transakcje;

• generowanie certyfikatów;

• obsługę bramek płatniczych i emitentów;

• walidację danych i autoryzację;

• logowanie oraz throttling.

Processing zaczął pełnić rolę głównego rdzenia całego systemu.

Ważny szczegół: sam Processing nie udostępnia publicznych API. Komunikacja odbywa się wyłącznie poprzez specjalną warstwę pośrednią — Data Connector.

Przejął on rolę fasady, agregatora starszych API oraz routera zapytań klientów. Dzięki temu nawet starsze integracje korzystające z API v1/v2 nadal działały bez zakłóceń — mimo że w rzeczywistości komunikowały się już z nowym systemem.

Jak obecnie wygląda obsługa zamówienia

Cykl życia zamówienia przeszedł całkowitą transformację.

Krok po kroku:

• Klient składa zamówienie poprzez API v3.

• W zależności od metody płatności środki są pobierane z salda klienta albo tworzona jest faktura w agregatorze płatności i obsługiwany jest callback.

• Po potwierdzeniu płatności Processing wysyła zadanie do kolejki.

• Worker generuje zaszyfrowany certyfikat PDF i zapisuje go w prywatnym magazynie.

• Dokument można otrzymać poprzez odpowiedź API, webhook, e-mail lub SMS — zależnie od konfiguracji.

• Aktywacja i realizacja certyfikatu również odbywa się przez Data Connector: sprawdza on status karty i tworzy zadanie dezaktywacji w Processing.

Rezultaty: co zmieniło się w architekturze

Najważniejszym efektem było rozdzielenie logiki biznesowej od interfejsów.

Obecnie witryny, panel administracyjny, rozwiązania partnerskie oraz sklep internetowy działają niezależnie od siebie. Wszystko, co jest związane z procesami biznesowymi, zostało skoncentrowane wewnątrz Processing.

Może on być skalowany niezależnie, aktualizowany niezależnie i nie jest już powiązany z frontendem.

Kolejki, logowanie oraz powiadomienia również stały się samodzielnymi usługami.

Pozwoliło to:

• odciążyć główną aplikację;

• znacząco zmniejszyć obciążenie zespołu wsparcia;

• szybciej wdrażać nowych programistów — zakres odpowiedzialności stał się jasny, dokumentacja bardziej uporządkowana, a testowanie przewidywalne.

Nie tylko zalety: szczere spojrzenie na kompromisy

Jak każda migracja do architektury usługowej, również ta droga wymagała dodatkowego wysiłku.

Co stało się bardziej skomplikowane:

• DevOps — pojawiły się dodatkowe zadania: monitoring, konteneryzacja oraz utrzymanie wielu komponentów.

• SLA — zarządzanie stało się trudniejsze: nawet niewielka awaria jednego z dziesięciu serwisów mogła wpłynąć na dostępność całego systemu.

• Komunikacja między usługami — wymaga uwzględnienia opóźnień (latency) oraz odporności na awarie.

• Wewnętrzna wiedza techniczna — potrzebna była większa ekspertyza w zakresie bezpieczeństwa, brokerów wiadomości, typów baz danych oraz synchronizacji danych.

Jednak te koszty okazały się uzasadnione.

Według wewnętrznych metryk czas poświęcany na utrzymanie odziedziczonego kodu zmniejszył się dwukrotnie, a wydajność wzrosła kilkukrotnie.

Co dalej

Zespół kontynuuje przejście do pełnego modelu usługowego.

Najbliższe plany:

• całkowite rozdzielenie witryn oraz sklepu internetowego;

• rozwój publicznego API;

• wdrożenie dodatkowych poziomów bezpieczeństwa i monitoringu;

• wykorzystanie Processing jako gotowego rozwiązania — z własnym interfejsem, SLA oraz autonomicznym wdrożeniem dla klientów korporacyjnych.

Podsumowanie

Przejście od monolitu do architektury usługowej w Vpodarok nie było chaotycznym przepisywaniem systemu, lecz zaplanowaną ewolucją wynikającą z wymagań biznesowych.

Architektura zmieniła się, ponieważ produkt wyszedł poza ramy jednej witryny i stał się platformą.

Obecnie system jest przygotowany na rozwój, skalowanie oraz wdrażanie nowych rozwiązań bez obawy, że „wszystko się zepsuje”.

Choć cała droga zajęła ponad rok, stała się fundamentem długoterminowego i stabilnego rozwoju produktu.

Życzymy wszystkim udanych projektów! Będziemy wdzięczni za subskrypcje i komentarze.