HighLoad++ 2017 Зал Дели + Калькутта, 7 ноября, 13:00 Тезисы: http://www.highload.ru/2017/abstracts/2867.html Последние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда. В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.

1. Микросервисный
фронтенд
Вячеслав Слинько
ЦИАН

2. О докладе
Микросервисная архитектура для скорости и качества разработки
фронтенда в больших проектах

3. О компании
16 лет
Один продукт
90+ человек в IT отделе
Много продуктовых команд

4. Разработка на виджетах
• Скачал — используешь
• Множество готовых виджетов
• Через два дня лапшекод
4

5. SPA
• Можно делать сложные проекты
• Можно работать параллельно с бекендом
• Проект становится большим и сложным
5

6. Библиотека компонентов
• Можно переиспользовать
• Часть сложности выносится из проекта
• Либо библиотека базовая, либо большая и сложная
6

7. Микросервисный подход
• Сложный проект собирается из простых фрагментов
• Радикальная изолированность
7

8. Что мы называем микросервисом?
8
GET https://frontend-header/v1/get-header-markup/?device=tablet
<link rel=“stylesheet” href=“//header.cian.site/header.css”>
<!-- ... -->
<header class=“header—tablet”><!-- ... --></header>
<!-- ... -->
<script src=“//header.cian.site/header.js”></script>

9. Кодовая база сервиса
резко уменьшается
1.

10. Микросервис помещается в голове
• Понятно что и где надо сделать
• Оценить задачу проще
10

11. Maintenance можно размазать
• Обновление зависимости можно поделить на сервисы
• Поддержка перестает блокировать продуктовые задачи
11
t

12. Понятная архитектура сервиса
• Сложные задачи может решать даже новый разработчик
• Архитектуру сервиса можно адаптировать под требования
12
A B
C

13. Фича может менять много сервисов
• Нужно синхронизировать релиз
• Нужно учитывать что зависимости может не быть на бою
13

14. Иногда надо нарушать изоляцию
• UX не должен страдать из-за архитектуры
14

15. Дублирование общих зависимостей
• Увеличение размера страницы
• Замедление загрузки страницы
15

16. Точка входа
• Принимает оригинальный запрос пользователя
• Роутит запрос на нужный микросервис
16
E

17. Микросервис страницы
• Принимает оригинальный запрос пользователя
• Собирает лайаут страницы из фрагментов
• Содержит логику обработки ошибок
17
E P

18. Микросервис фрагмента
• Реализует серверный рендеринг в виде API
• Принимает запрос согласно схеме
• Отвечает за клиентскую часть фрагмента
18
E P
F F
BACKEND

19. Итоговая страница
19
Browser
F FF
1 2 3
• Фрагменты отдаются в потоке
• Фрагмент могут загружаться асинхронно

20. Browser
Связывание фрагментов
• Классический PubSub
• События декларативны и минималистичны
• Подходит для плоской системы
20
F PubSub F

21. • Зависимые библиотеки собираются отдельно
• Сервисы используют зависимости из общей сборки
Дедубликация через Webpack DLL
21
FF1 2

22. Быстрый continuous
deployment без боли
2.

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

29. Локализация проблемы
в конкретном сервисе
3.

30. Ошибка сервиса не ломает систему
• Фрагменты отключаются по условию
• Остальные сервисы продолжают работать
• Можно не тестировать всю систему перед релизом
30

31. Тормоза проявляются в одном месте
• Новая зависимость не влияет на весь сайт
• Можно точнее определять приоритеты работы
31

32. Микросервисам нужен мониторинг
• Непопулярный микросервис может долго жить с проблемой
• Мониторинг должен маштабироваться
32

33. Мониторинг ошибок
• Собираем ошибки на сервере и в браузерах
• Есть готовые системы, например Sentry
• На ошибки надо реагировать
33
A.
B.
C.

34. Мониторинг производительности
• Собираем сообщения, события, метрики
• Данные собираются на сервере и в браузере
34

35. Navigation Timing API
• Информация о скорости и этапах загрузки страницы
• Каждый запрос храним на сервере
• Данные сильно отличаются от ожидаемых
35

36. User Timing API
• Измерение времени любых процессов
• Интеграция с Chrome DevTools
• Все храним на сервере
36

37. Уникальный идентификатор запроса
• Идентификатор генерируется в начале запроса
• Можно связать все подзапросы
• Можно отправить на клиент
37
uuid.v4();

38. В итоге

39. Плюсы
• Маленький размер сервиса
• Быстрый continuous deployment
• Проблема локализуется в одном сервисе
39

40. Минусы
• Сложно связать изолированные сервисы
• Нужно избавляться дублирование зависимостей
• Инфраструктура становится сложнее
40

41. Почему это подходит для нас?
• Много продуктовых команд делают один проект
• Все хотят релизить фичи как можно чаще
• Мы не хотим из-за этого страдать
• Есть возможность инвестировать в архитектуру
41

42. Project Mosaic от Zalando
• Похожая архитектура
• Часть проектов находится в Open Source
• Есть статьи и доклады
42

43. Как начать?
• Сделать один фрагмент
• Сделать страницу полностью из фрагментов
• Начать стандартизировать
43

44. Спасибо

45. Ссылки
• Project Mosaic от Zalando
• Доклад про управление версиями компонентов от hh.ru
• Доклад про эффективную загрузку страницы от Яндекса
• Методология RAIL от Google
• Система сбора ошибок Sentry
45