Часто спикеры на конференции рассказывают, как построить классную микросервисную платформу, но редко делятся увлекательным процессом перехода от монолита/сервисной архитектуры на микросервисы.
В докладе расскажу об опыте подобного перехода без остановки развития сервиса.

Онлайн-оплата на сети АЗС «Газпромнефть» стартовала в 2018 году с собственной сети. Сейчас ежедневно более 2,5 миллиона литров топлива водители покупают на сети АЗС «Газпромнефть» онлайн. Сервис интегрирован с партнерами с большой клиентской аудиторией, а также с узкопрофильными мобильными приложениями. Поговорим о пользовательском приложении, что стоит за тремя «простыми» экранами заправки?

1. Как мы начинали: low-code-платформа для быстрого старта на 30 точек продаж, 6 месяцев разработки.
2. Рост сервиса опережает функционал, разработка играет роль догоняющего, решение — только распределение нагрузки и изоляция сервисов друг от друга. Все понимаем, планируем переход на новую архитектуру, но не успеваем.
3. Тираж mvp на 1000 точек и первые проблемы low-code, дублирующие сервисы, параллельная нагрузка, функциональное разделение платформы, дополнительный сервер для асинхронных запросов и ODS. Все это на «горячую», без остановок развития функционала и самого сервиса.
4. Рост использования приложения х10 за 1,5 мес и первый серьезный даунтайм, начинаем переход на микросервисы в части транспортного слоя, сложности нагрузочного тестирования распределенных систем, CAP-теорема.

Что сейчас? На выходе получили 3 слоя и 28 микросервисов, оркестратор, шину сообщений и стабильный сон по ночам, продолжаем распиливать монолит без сожаления. Тут поговорим про паттерн SAGA на примере пользовательского опыта.