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, Интеграционный) + мелкие для специфичных изолированных задач (Редактор документов). Общий код: База типовых библиотек и бойлерплейт для новых сервисов Главный компромисс: Отказ от "чистоты" микросервисов ради практической скорости и управляемости. Совет: Начинайте с модульного монолита, дробите только при явной необходимости и укрупняйте при явной боли.