AI Рефакторинг системы рекомендаций: как мы перешли с монолита на микросервисы

[AI]

Привет, я разработчик программного обеспечения в компании 1221Systems и хочу рассказать об опыте перевода проекта с монолитной архитектуры на микросервисную: как выглядел исходный проект и с какими проблемами мы столкнулись, какую архитектуру построили после рефакторинга и какие преимущества в итоге получили.

Что у нас было


Проект состоял из двух частей:

• 
  Монолит на PHP / JS / PostgreSQL
  
  • 
    Интерфейс управления рекомендациями
    
    
  • 
    Логика хранения и отображения данных
    

• 
  ML-сервис на Python
  
  • 
    Прогнозирование поведения пользователей
    
    
  • 
    Формирование рекомендаций
    

Исходная система работала стабильно, но со временем начались проблемы. Визуально ее можно представить так:

Почему решили переделать

• 
  Изменения в одном модуле могли повлиять на другую часть, что требовало полного тестирования всей системы.
  
  
• 
  Разнородность технологий без четкого разделения ответственности: PHP и Python использовались совместно, но без границ между компонентами.
  
  
• 
  Проект разрастался, появлялись новые функциональные элементы и компоненты, что могло привести в данной архитектуре если не к краху, то к большим проблемам.
  

Нам хотелось повысить отказоустойчивость и масштабируемость, ускорить процессы разработки и деплоя, четко разделить зоны ответственности и создать возможность независимого развития каждого сервиса.

Что у нас получилось


После рефакторинга архитектура стала выглядеть так:

После декомпозиции мы разделили систему на четыре микросервиса:

1. Сервис приема данных

• 
  Что делает сервис: принимает информацию для хранения и обработки
  
  
• 
  Стек: Python / PostgreSQL
  

2. Административный сервис

• 
  Что делает сервис: управление настройками рекомендаций, для дальнейшего просчета
  
  
• 
  Стек: JS / Symfony / PostgreSQL
  

3. Сервис просчета рекомендаций

• 
  Что делает сервис: обучение моделей, прогнозирование, формирование рекомендательных лент
  
  
• 
  Стек: Python (scikit-learn, PyTorch)
  
  
• 
  Особенности: вычислительно тяжелый, легко масштабируется горизонтально
  

4. Сервис отдачи рекомендаций

• 
  Что делает сервис: предоставление готовых лент рекомендаций
  
  
• 
  Стек: Symfony / Redis / gRPC
  

Что нам потребовалось?


Для надежной работы всех микросервисов мы внедрили такую инфраструктуру:

• 
  API Gateway – маршрутизация запросов, аутентификация, ограничение скорости
  
  
• 
  Шина сообщений – Kafka / RabbitMQ для асинхронного взаимодействия
  
  
• 
  Контейнеризация – Docker + Kubernetes для автоматического деплоя и масштабирования
  
  
• 
  Логирование и мониторинг – Prometheus, Grafana
  

Какие трудности?

• 
  Сложности взаимодействия команд на разных стеках: нужно документировать API и стандартизировать взаимодействие ни только между сервисами, но и между командами
  
  
• 
  Управленческая сложность: управление множеством сервисов требует хорошего DevOps-обеспечения. Кроме того, возникла проблема управления большим количеством разносторонних сервисов с различной архитектурой и стеком.
  
  
• 
  Согласованность данных: проблема при синхронизации больших объемов данных. Пришлось распределять данные по различным хранилищам (postgreSql, ElasticSearch). Распределенные данные потребовали применения паттернов Event Sourcing или Saga.
  

В итоге мы получили такие плюсы

• 
  Независимость сервисов
  
  • 
    Тестирование, обслуживание и обновления стали проще
    
    
  • 
    Быстрее вывод новых фич
    
• 
  Гибкость в выборе технологий
  
  • 
    Можно использовать оптимальный стек под каждую задачу
    

• 
  Масштабируемость
  
  • 
    Каждый сервис можно масштабировать отдельно
    

• 
  Высокая отказоустойчивость
  
  • 
    Выход одного сервиса не парализует всю систему
    

• 
  Поддержка экспериментов
  
  • 
    Возможность A/B-тестирования на уровне отдельных сервисов
    

Итого


Переход на микросервисную архитектуру — это не только технический, но и организационный процесс. Он требует планирования, стратегии и понимания целей, вовлеченности всей команды (спасибо коллегам!), и нужно быть готовыми к этому. Зато этот шаг открывает широкие возможности для масштабирования, гибкости и развития продукта (об этом – в следующей статье).

Разделение исходного монолита на микросервисы позволило значительно повысить производительность, отказоустойчивость и скорость разработки. Это стало важным этапом в развитии нашей рекомендательной системы и дало возможность эффективно разрабатывать новые функции для бизнеса. Если у вас был аналогичный опыт, было бы интересно обсудить его в комментариях!