Python в Highload-ипотеке: От монолита к микросервисам на стероидах (и обратно к разумному балансу)

Тезисный план доклада (30 минут)

С красивой версткой: https://docs.google.com/document/d/1n2xlD2LSSPPZEQgvNMeJfjCevbW_0C0-eJf1vKZA9Zs/edit?usp=sharing

(2 мин) Вступление: Кто я и где работаю
Я – IT лидер Дивизиона (Готовое Жильё), прошёл весь путь от разработчика до руководителя и имею богатый опыт внедрения высоконагруженных решений в условиях дедлайнов от Центробанка, международных санкций и нулевой толерантности к простоям.
Домклик – дочка Сбера, через нас выдаётся больше половины ипотеки в нашей стране. Наши IT решения и архитектура позволяют нам первыми на рынке запускать крупные продукты и решать любые вопросы с недвижимостью.
(2 мин) Точка кипения: Почему монолит не мог масштабироваться
Бизнес-успех vs. Технический долг: Сервис приносил деньги, но был капризен в эксплуатации и не мог быстро развиваться.
Решение №1 – "Островки нового": Создание команды на новом Python стеке для виджетов внутри монолита как первый шаг к модульности.
(5 мин) Адреналиновый рывок: Триумф микросервисов (на стероидах)
Поворотный момент – "2 месяца на революцию": Бизнес-идея реформы ипотеки и безумный дедлайн. Как сделать быстро, при этом заложив сразу целевую архитектуру.
Стратегия: Новая система на Python как "обвязка" вокруг старого монолита.
Успех: Модульность, асинхронность, масштабируемость, скорость доработки.
Победное шествие: Полный отказ от PHP и переписывание всего на Python-микросервисы.
(8 мин) Обратная сторона медали: Когда "микросервисно" = "больно"
Рост "микросервисной паутины": Каждая фича = новый сервис?
Главные боли:
Dependency Hell: Общие библиотеки – кошмар синхронизации версий и обновлений в 30+ сервисах.
Сложность координации: Десятки репозиториев, CI/CD-пайплайны, артефакты, релизные процессы.
Нагрузка на инфраструктуру: Оркестрация, мониторинг, логи, ограничения кибербезопасности.
Снижение скорости разработки: Скатывание в постоянную интеграцию вместо написания кода.
Сложность отладки распределенных транзакций.
Осознание: Микросервисы – не серебряная пуля, а дорогой инструмент. Компромисс сложности vs. выгод мог стать отрицательным.
(7 мин) Путь к балансу: Осознанное укрупнение и "разумные сервисы"
Анализ связности: Какие сервисы реально должны быть отделены, а какие страдают от разделения?
Критерии объединения:
Частота совместных изменений.
Общие сложные транзакции/данные.
Схожий паттерн нагрузки.
Управляемость зависимостей.
Рождение "Крупнокалиберных" сервисов и выделенных микросервисов:
Core Сервис + Интеграционный (внешние контуры) - основа проекта.
Сервис Услуг – агрегатор для всех услуг и процессов по ним в компании
Кабинет Руквоводителя: яркий пример сервиса с админкой.
Календарь: Выделенный, но крупный центральный сервис для работы с календарём менеджера.
Кеш Офисов: Пример нагруженного сервиса с узким профилем.
Редактор документов: Изолированный сервис генерации документов (идеальный кандидат в микросервис!).
Принцип: "Сервис как продукт" – владелец, четкий контракт, автономность в рамках его размера.
(6 мин) Итоги: Уроки и баланс
Микросервисы – тактика, а не стратегия. Их границы должны эволюционировать.
Ключевые метрики: Скорость разработки, надежность, стоимость владения (включая трудозатраты).
Наш баланс: Крупные, но внутренне модульные сервисы (Core, Интеграционный) + мелкие для специфичных изолированных задач (Редактор документов).
Общий код: База типовых библиотек и бойлерплейт для новых сервисов
Главный компромисс: Отказ от "чистоты" микросервисов ради практической скорости и управляемости.
Совет: Начинайте с модульного монолита, дробите только при явной необходимости и укрупняйте при явной боли.