Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

364 views

Published on

HighLoad++ 2017

Зал Дели + Калькутта, 7 ноября, 13:00

Тезисы:
http://www.highload.ru/2017/abstracts/2867.html

Последние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда.

В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Микросервисный фронтенд Вячеслав Слинько ЦИАН
  2. 2. О докладе Микросервисная архитектура для скорости и качества разработки фронтенда в больших проектах
  3. 3. О компании 16 лет
 Один продукт
 90+ человек в IT отделе
 Много продуктовых команд
  4. 4. Разработка на виджетах • Скачал — используешь • Множество готовых виджетов • Через два дня лапшекод 4
  5. 5. SPA • Можно делать сложные проекты • Можно работать параллельно с бекендом • Проект становится большим и сложным 5
  6. 6. Библиотека компонентов • Можно переиспользовать • Часть сложности выносится из проекта • Либо библиотека базовая, либо большая и сложная 6
  7. 7. Микросервисный подход • Сложный проект собирается из простых фрагментов • Радикальная изолированность 7
  8. 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. 9. Кодовая база сервиса резко уменьшается 1.
  10. 10. Микросервис помещается в голове • Понятно что и где надо сделать • Оценить задачу проще 10
  11. 11. Maintenance можно размазать • Обновление зависимости можно поделить на сервисы • Поддержка перестает блокировать продуктовые задачи 11 t
  12. 12. Понятная архитектура сервиса • Сложные задачи может решать даже новый разработчик • Архитектуру сервиса можно адаптировать под требования 12 A B C
  13. 13. Фича может менять много сервисов • Нужно синхронизировать релиз • Нужно учитывать что зависимости может не быть на бою 13
  14. 14. Иногда надо нарушать изоляцию • UX не должен страдать из-за архитектуры 14
  15. 15. Дублирование общих зависимостей • Увеличение размера страницы • Замедление загрузки страницы 15
  16. 16. Точка входа • Принимает оригинальный запрос пользователя • Роутит запрос на нужный микросервис 16 E
  17. 17. Микросервис страницы • Принимает оригинальный запрос пользователя • Собирает лайаут страницы из фрагментов • Содержит логику обработки ошибок 17 E P
  18. 18. Микросервис фрагмента • Реализует серверный рендеринг в виде API • Принимает запрос согласно схеме • Отвечает за клиентскую часть фрагмента 18 E P F F BACKEND
  19. 19. Итоговая страница 19 Browser F FF 1 2 3 • Фрагменты отдаются в потоке • Фрагмент могут загружаться асинхронно
  20. 20. Browser Связывание фрагментов • Классический PubSub • События декларативны и минималистичны • Подходит для плоской системы 20 F PubSub F
  21. 21. • Зависимые библиотеки собираются отдельно • Сервисы используют зависимости из общей сборки Дедубликация через Webpack DLL 21 FF1 2
  22. 22. Быстрый continuous deployment без боли 2.
  23. 23. Ускорение сборки и тестирования • Быстрый фидбек разработчику • Можно релизить хоть каждый коммит 23 Code Build Test Deploy Analyse Code Code
  24. 24. Уменьшается время до релиза • Быстрое реагирование на проблемы • Проще делать эксперименты с продуктом 24 Code Build Test Deploy Analyse Code Build Test Deploy Analyse
  25. 25. Выше требования к инфраструктуре • Обязательный Zero Downtime Deploy • Устойчивость к проблемам • Быстрое масштабирование 25
  26. 26. Шаблон микросервиса • Сборка и деплой • Логирование сообщений, ошибок, телеметрии, запросов • Мало boilerplate, много библиотек 26
  27. 27. Сборка ресурсов фрагмента • Кастомизировать сборку под проект нельзя • Файлы имеют уникальный хеш в имени 27
  28. 28. Деплой • Dev для тестирования одного микросервиса • Staging для интеграционного тестирования • Релиз на бой через blue/green 28
  29. 29. Локализация проблемы в конкретном сервисе 3.
  30. 30. Ошибка сервиса не ломает систему • Фрагменты отключаются по условию • Остальные сервисы продолжают работать • Можно не тестировать всю систему перед релизом 30
  31. 31. Тормоза проявляются в одном месте • Новая зависимость не влияет на весь сайт • Можно точнее определять приоритеты работы 31
  32. 32. Микросервисам нужен мониторинг • Непопулярный микросервис может долго жить с проблемой • Мониторинг должен маштабироваться 32
  33. 33. Мониторинг ошибок • Собираем ошибки на сервере и в браузерах • Есть готовые системы, например Sentry • На ошибки надо реагировать 33 A. B. C.
  34. 34. Мониторинг производительности • Собираем сообщения, события, метрики • Данные собираются на сервере и в браузере 34
  35. 35. Navigation Timing API • Информация о скорости и этапах загрузки страницы • Каждый запрос храним на сервере • Данные сильно отличаются от ожидаемых 35
  36. 36. User Timing API • Измерение времени любых процессов • Интеграция с Chrome DevTools • Все храним на сервере 36
  37. 37. Уникальный идентификатор запроса • Идентификатор генерируется в начале запроса • Можно связать все подзапросы • Можно отправить на клиент 37 uuid.v4();
  38. 38. В итоге
  39. 39. Плюсы • Маленький размер сервиса • Быстрый continuous deployment • Проблема локализуется в одном сервисе 39
  40. 40. Минусы • Сложно связать изолированные сервисы • Нужно избавляться дублирование зависимостей • Инфраструктура становится сложнее 40
  41. 41. Почему это подходит для нас? • Много продуктовых команд делают один проект • Все хотят релизить фичи как можно чаще • Мы не хотим из-за этого страдать • Есть возможность инвестировать в архитектуру 41
  42. 42. Project Mosaic от Zalando • Похожая архитектура • Часть проектов находится в Open Source • Есть статьи и доклады 42
  43. 43. Как начать? • Сделать один фрагмент • Сделать страницу полностью из фрагментов • Начать стандартизировать 43
  44. 44. Спасибо
  45. 45. Ссылки • Project Mosaic от Zalando • Доклад про управление версиями компонентов от hh.ru • Доклад про эффективную загрузку страницы от Яндекса • Методология RAIL от Google • Система сбора ошибок Sentry 45

×