Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.
Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.
В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.
Расскажу, какие тулзы мы в итоге используем, а от каких отказались.
2. • Услуги системной интеграции, начиная от разработки технологических
решений и заканчивая доставкой видео-сигнала до конечного пользователя
• Интернет-видеоплатформа для каналов МатчТВ и НТВ-ПЛЮС
• 300 000 одновременных пользователей
• > 1 000 000 уникальных посетителей в сутки
• Отдаем контента до 300 Тб/час
3. — Достучаться до небес (фильм)
«Пойми, на небесах только и говорят, что
о море. Как оно бесконечно прекрасно…»
6. Проблемы
• Pipeline: для каждого свой проект в git, CI, …
• Сложность системы: распределенные коммуникации, дополнительное API,
больше точек отказа и логики их обработки
• Контроль целостности данных, сложность распределенных транзакций
12. В чем бонусы?
• Независимая разработка
• Отсутствие завязки на технологии
13. В чем бонусы?
• Независимая разработка
• Отсутствие завязки на технологии
• Скорость тестирования (независимость при тестировании)
14. В чем бонусы?
• Независимая разработка
• Отсутствие завязки на технологии
• Скорость тестирования (независимость при тестировании)
• Легкость масштабирования (если она вообще есть)
15. В чем бонусы?
• Независимая разработка
• Отсутствие завязки на технологии
• Скорость тестирования (независимость при тестировании)
• Легкость масштабирования (если она вообще есть)
• Минимизация ущерба при отказе сервиса (при корректной реализации
остальных)
23. Как проверить независимость?
1. Опишите бизнес-задачу сервиса одним простым предложением
2. Какое количество потребителей у сервиса?
24. Как проверить независимость?
1. Опишите бизнес-задачу сервиса одним простым предложением
2. Какое количество потребителей у сервиса?
3. Приводит ли деплой одного сервиса к деплою других сервисов?
25. Требования к микросервису
• Скрывает внутренние детали реализации
• Деплоится независимо
• Падая, не роняет все остальное
• Легко мониторится
• Реализует бизнес-модель
• Полностью децентрализован
30. Конфигурация
Что пробовали?
• файлы конфигурации при деплое разливать по всем целевым машинам
• файлы конфигурации класть в контейнер
• выставлять переменные окружения
• при сборке контейнера (ENV DB=…)
• при запуске контейнера
31. Конфигурация
• Общее K/V хранилище
• Сервис должен быть заточен под смену конфигурации
• Микс вариаций с приоритетами:
<СЕРВИС>/ (/conf/ms/recorder/)
<СЕРВИС>/<ВЕРСИЯ>/ (/conf/ms/recorder/0.12)
<СЕРВИС>/<СРЕДА>/
<СЕРВИС>/<ВЕРСИЯ>/<СРЕДА>/
<СЕРВИС>/<ВЕРСИЯ>/<НОДА>/
32. Конфигурация
1. git2consul
• не используем отдельные проекты/бранчи в git для основных параметров
• загружаем конфигурацию при деплое
• стартовый путь:
/conf/ms/<ИМЯ СЕРВИСА>/<BUILD NO>/
2. Vault
все секретное храним в отдельных проектах
40. Как решать?
• Помнить, что микросервисы — они как PHP, только микросервисы
• Вместо полноценного мониторинга — строим dashboard
41. Как решать?
• Помнить, что микросервисы — они как PHP, только микросервисы
• Вместо полноценного мониторинга — строим dashboard
• Алерты по статистическим и пороговым значениям вместо бинарных
42. Как решать?
• Помнить, что микросервисы — они как PHP, только микросервисы
• Вместо полноценного мониторинга — строим dashboard
• Алерты по статистическим и пороговым значениям вместо бинарных
• На одном dashboard сводить графики хост-машин и статистики
по docker-демону
44. 1. Сбор метрик - это важно, но еще важнее постоянный анализ полученных
данных
2. Система мониторинга должна быть более надежной и масштабируемой,
чем то, что она контролирует
3. Система должна быть оптимизирована для распределенных,
недолговечных, облачных, контейнеризованных микросервисов
4. Собирайте метрики часто … очень часто …
Стремитесь к интервалам < 10 сек
Общие рекомендации
47. В чем сложность?
1. Корректность взаимодействия с другими сервисами
2. Сервис назначения доступен, но:
• Отвечает очень медленно
• Отвечает эпизодически
• Отвечает некорректно
48. В чем сложность?
1. Корректность взаимодействия с другими сервисами
2. Сервис назначения доступен, но:
• Отвечает очень медленно
• Отвечает эпизодически
• Отвечает некорректно
Circuit Breaker!
49. В чем сложность?
1. Корректность взаимодействия с другими сервисами
2. Сервис назначения доступен, но:
• Отвечает очень медленно
• Отвечает эпизодически
• Отвечает некорректно
Circuit Breaker!
[Hystrix, Netflix]
60. Реестр сервисов
• consul — key/value хранилище, DNS, Health-Check, работа с несколькими ДЦ из коробки
• etcd — key/value хранилище
• skydock — Health-Check, регистрация docker-контейнеров
• skydns — DNS
• Apache Zookeeper — вариация key/value хранилища, сервис блокировок, вариация на тему DNS
• !redis — запись только в мастер, нет механизма достижения консенсуса при определении
актуального состояния данных после выхода из строя отдельных узлов хранилища
67. Чек-лист
Как конфигурировать?
Как мониторить и считать метрики?
Как сервисы будут находить друг друга?
Как сервис будет взаимодействовать с остальными частями проекта?
Как тестировать сервис и систему целиком?
Как обрабатывать сбои связанных сервисов?
Как переезжать на новую версию?
Как масштабировать под нагрузкой?