Микросервисы во Freedom Travel
Монолит на Django и Python 2.6, который рос с 2014 года, к 2018-му превратился в зоопарк зависимостей: невозможно обновить ни джангу, ни питон, нельзя масштабировать что-то одно — только всё сразу. Как из этого вырасти в систему из ~200 сервисов, обслуживающую 20 млн+ запросов в сутки?
Эдуард Сидиропуло — Senior Python разработчик во Freedom Travel — рассказывает, как команда переехала с монолита на микросервисы и какие технологии и подходы под это выбрала.
В докладе: — масштаб системы: 200 тыс.+ поисков авиа и ж/д ежедневно, 20 млн+ запросов в сутки, ~200 сервисов в проде — проблемы старого монолита: отсутствие асинхронности и стабильности, сложность параллельной разработки несколькими командами — стек перехода: Sanic, PostgreSQL, Redis, RabbitMQ, Kubernetes и API-шлюз Kong до 200 000 RPS на узел — общий каркас сервисов: ядро фреймворка, клиенты для HTTP, ивентов и БД, единый формат логирования, сквозной контекст, health-check'и — сервис-оркестратор как точка входа и архитектура под особенности бизнеса: отказоустойчивость, безопасность, большое число поставщиков — автомониторинг и алерты: метрики api, статусы подов в k8s, очереди и ошибки в Sentry, график дежурства с автодозвонами — честный взгляд: микросервисы не панацея — запутанность, оверхед на коммуникацию и сложность инфраструктуры
Презентация
1 / 27
Текст презентации
Слайд 1: Микросервисы
Микросервисы Архитектура, технологии, подходы Сидиропуло Эдуард Senior Python разработчик
Слайд 3: Где мы сейчас
Где мы сейчас 200к + поисков авиа и жд ежедневно 20кк + запросов в сутки MAU и DAU авиа: 531к/42к MAU и DAU жд: 395к и 29к ~200 сервисов в проде
Слайд 5: Начало, 2014
Начало, 2014 Python 2.6, Монолит Django 2.* MySQL Redis Celery
Слайд 6: Проблемы, 2018
Проблемы, 2018 Отсутствие асинхронности, мобильности, стабильности Сложность в разработке и тестировании несколькими командами одновременно Зоопарк зависимостей, которые невозможно обновлять →невозможно обновлять саму джангу и питон Хочешь масштабировать что то одно - масштабируй все И так далее...
Слайд 7: Решение
Решение Микросервисы - разделение доменных областей на отдельные сервисы Sanic - быстрый, простой и асинхронный фреймворк для высоконагруженных API PostgreSQL - надёжная реляционная СУБД с транзакциями и расширенными возможностями Redis - сверхбыстрый in-memory кэш и хранилище для ускорения запросов и хранения сессий RabbitMQ - надёжная асинхронная передача сообщений между сервисами Kubernetes - автоматическое управление, масштабирование и отказоустойчивость сервисов Kong - API-шлюз с маршрутизацией, безопасностью и мониторингом
Слайд 8: Sanic
Sanic Один из самых быстрых Python-фреймворков Асинхронность из коробки. Обработчики, middleware, роутеры — всё может быть асинхронным. Синтаксис похож на Flask, низкий порог входа. Имеет встроенный HTTP/1.1 и HTTP/2 сервер. Поддерживает graceful shutdown, health checks, worker management Активное сообщество
Слайд 10: Базы
Базы PostgreSQL PostgreSQL — это полноценная ACID СУБД, где каждая операция - транзакция Параллельные запросы и оптимизация Репликация и отказоустойчивость Redis-Непростокэш!!! Большое кол-во структур Поддерживает Pub/Sub и Streams Счётчики и лимиты (rate limiting) Feature flags, конфиги Persistence - дампы, журнал команд Масштабирование и отказоустойчивость
Слайд 11: Kong
Kong До 200000 RPS на одном узле в базовых тестах. Расширяемость через плагины Поддержка JWT, OAuth2, Key-Auth, mTLS, OIDC. Интеграция с наблюдаемостью и мониторингом
Слайд 14: Клиент/Фронт
Клиент/Фронт Kong Kong Kong Kong Kong Kong Redis Сервис 1 База 1 Сервис 2 База 2 RabbitMQ авторизация аутентификация Auth Идентификация
Слайд 15: Архитектура - особенности бизнеса
Архитектура - особенности бизнеса Высокая отказоустойчивость Весомая доля приложений Адаптивность под разный контент Безопасность Большоекол-вопоставщиков
Слайд 16: Сервис оркестратор
Сервис оркестратор - точка входа Админка Правила сервис провайдер провайдер сервис провайдер провайдер сервис провайдер провайдер Rabbit База/redis
Слайд 18: Каркас сервисов
Каркас сервисов Ядро фреймворка Контроль зависимостей Всевозможные клиенты для HTTP запросов, ивентов, баз, логирования и тд Общий формат логгирования Единая обработка ошибок Сквозной контекст Авторизация, аутентификация Health-check’и
Слайд 23: Авто-мониторинг и алерты
Авто-мониторинг и алерты Время ответа api, кол-во bad requests Статус подов в k8s (недоступность, probes) Превышение кол-ва ивентов в очередях Превышение кол-ва ошибок в sentry График дежурства + автодозвоны по критичным метрикам
Слайд 24: Микросервисы - не панацея
Микросервисы - не панацея Запутанность - основная проблема Они могут не решить проблему производительности Сделать по-настоящему независимую систему труднее чем кажется Оверхед на коммуникацию между командами Трудности отладки и тестирования Сложность инфраструктуры
Слайд 25: Планы
Планы Автомасштабирование зависящее от метрик Автогенерация документации
Слайд 27: Спасибо за внимание!
Спасибо за внимание!
Другие доклады митапа
- ССMicroPython — искусство малых форм Сергей Степанов
- КУFastAPI с Clean Architecture Коспан Улан
- ЕДКак работает стартап на миллиард долларов Ерзат Дулат
