Последние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда.
В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.
В своем докладе я расскажу про архитектуру фронтенда (и так называемого миддленда) в ЦИАН: какие задачи перед нами стояли, что мы решили, где мы находимся сейчас и с какими проблемами мы столкнулись.
16. Точка входа
• Принимает оригинальный запрос пользователя
• Роутит запрос на нужный микросервис
16
E
17. Микросервис страницы
• Принимает оригинальный запрос пользователя
• Собирает лайаут страницы из фрагментов
• Содержит логику обработки ошибок
17
E P
18. Микросервис фрагмента
• Реализует серверный рендеринг в виде API
• Принимает запрос согласно схеме
• Отвечает за клиентскую часть фрагмента
18
E P
F F
BACKEND
23. Ускорение сборки и тестирования
• Быстрый фидбек разработчику
• Можно релизить хоть каждый коммит
23
Code Build Test Deploy Analyse
Code
Code
24. Уменьшается время до релиза
• Быстрое реагирование на проблемы
• Проще делать эксперименты с продуктом
24
Code Build Test Deploy Analyse
Code Build Test Deploy Analyse
25. Выше требования к инфраструктуре
• Обязательный Zero Downtime Deploy
• Устойчивость к проблемам
• Быстрое масштабирование
25
26. Шаблон микросервиса
• Сборка и деплой
• Логирование сообщений, ошибок, телеметрии, запросов
• Мало boilerplate, много библиотек
26
27. Сборка ресурсов фрагмента
• Кастомизировать сборку под проект нельзя
• Файлы имеют уникальный хеш в имени
27
28. Деплой
• Dev для тестирования одного микросервиса
• Staging для интеграционного тестирования
• Релиз на бой через blue/green
28
30. Ошибка сервиса не ломает систему
• Фрагменты отключаются по условию
• Остальные сервисы продолжают работать
• Можно не тестировать всю систему перед релизом
30
31. Тормоза проявляются в одном месте
• Новая зависимость не влияет на весь сайт
• Можно точнее определять приоритеты работы
31
35. Navigation Timing API
• Информация о скорости и этапах загрузки страницы
• Каждый запрос храним на сервере
• Данные сильно отличаются от ожидаемых
35
36. User Timing API
• Измерение времени любых процессов
• Интеграция с Chrome DevTools
• Все храним на сервере
36
37. Уникальный идентификатор запроса
• Идентификатор генерируется в начале запроса
• Можно связать все подзапросы
• Можно отправить на клиент
37
uuid.v4();
39. Плюсы
• Маленький размер сервиса
• Быстрый continuous deployment
• Проблема локализуется в одном сервисе
39
40. Минусы
• Сложно связать изолированные сервисы
• Нужно избавляться дублирование зависимостей
• Инфраструктура становится сложнее
40
41. Почему это подходит для нас?
• Много продуктовых команд делают один проект
• Все хотят релизить фичи как можно чаще
• Мы не хотим из-за этого страдать
• Есть возможность инвестировать в архитектуру
41
42. Project Mosaic от Zalando
• Похожая архитектура
• Часть проектов находится в Open Source
• Есть статьи и доклады
42
43. Как начать?
• Сделать один фрагмент
• Сделать страницу полностью из фрагментов
• Начать стандартизировать
43
45. Ссылки
• Project Mosaic от Zalando
• Доклад про управление версиями компонентов от hh.ru
• Доклад про эффективную загрузку страницы от Яндекса
• Методология RAIL от Google
• Система сбора ошибок Sentry
45