Доклад с конференции Backend Conf 2016 Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте. Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом. В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как: - конфигурирование сервисов; - интеграция между собой; - тестирование; - версионирование; - масштабирование. Расскажу, какие тулзы мы в итоге используем, а от каких отказались.

1. Чему мы научились,
разрабатывая
микросервисы?
Мадисон Вадим, М-Тех
2016

2. • Услуги системной интеграции, начиная от разработки технологических
решений и заканчивая доставкой видео-сигнала до конечного пользователя
• Интернет-видеоплатформа для каналов МатчТВ и НТВ-ПЛЮС
• 300 000 одновременных пользователей
• > 1 000 000 уникальных посетителей в сутки
• Отдаем контента до 300 Тб/час

3. — Достучаться до небес (фильм)
«Пойми, на небесах только и говорят, что
о море. Как оно бесконечно прекрасно…»

4. Кто не знает, что
такое микросервис?

5. Проблемы
микросервисов

6. Проблемы
• Pipeline: для каждого свой проект в git, CI, …
• Сложность системы: распределенные коммуникации, дополнительное API,
больше точек отказа и логики их обработки
• Контроль целостности данных, сложность распределенных транзакций

7. 17 (1/20)→340→1120

8. Проблемы
• Оверхед: сетевой, сериализация/десериализация
• Обнаружение сервисов
• Постоянный контроль независимости сервисов
• Инструментарий!

10. А чем они
тогда
привлекают?

11. В чем бонусы?
• Независимая разработка

12. В чем бонусы?
• Независимая разработка
• Отсутствие завязки на технологии

13. В чем бонусы?
• Независимая разработка
• Отсутствие завязки на технологии
• Скорость тестирования (независимость при тестировании)

14. В чем бонусы?
• Независимая разработка
• Отсутствие завязки на технологии
• Скорость тестирования (независимость при тестировании)
• Легкость масштабирования (если она вообще есть)

15. В чем бонусы?
• Независимая разработка
• Отсутствие завязки на технологии
• Скорость тестирования (независимость при тестировании)
• Легкость масштабирования (если она вообще есть)
• Минимизация ущерба при отказе сервиса (при корректной реализации
остальных)

16. Насколько микро-
должен быть -сервис?

17. Насколько микро- должен быть
микросервис?
• По длительности разработки

18. Насколько микро- должен быть
микросервис?
• По длительности разработки
• По количеству строк кода

19. Насколько микро- должен быть
микросервис?
• По длительности разработки
• По количеству строк кода
• По количеству разработчиков за N спринтов

20. Сервис должен быть независимым!

21. Как проверить
независимость?

22. Как проверить независимость?
1. Опишите бизнес-задачу сервиса одним простым предложением

23. Как проверить независимость?
1. Опишите бизнес-задачу сервиса одним простым предложением
2. Какое количество потребителей у сервиса?

24. Как проверить независимость?
1. Опишите бизнес-задачу сервиса одним простым предложением
2. Какое количество потребителей у сервиса?
3. Приводит ли деплой одного сервиса к деплою других сервисов?

25. Требования к микросервису
• Скрывает внутренние детали реализации
• Деплоится независимо
• Падая, не роняет все остальное
• Легко мониторится
• Реализует бизнес-модель
• Полностью децентрализован

26. Как готовить?

27. Конфигурация

28. Конфигурация
Что пробовали?
• файлы конфигурации при деплое разливать по всем целевым машинам

29. Конфигурация
Что пробовали?
• файлы конфигурации при деплое разливать по всем целевым машинам
• файлы конфигурации класть в контейнер

30. Конфигурация
Что пробовали?
• файлы конфигурации при деплое разливать по всем целевым машинам
• файлы конфигурации класть в контейнер
• выставлять переменные окружения
• при сборке контейнера (ENV DB=…)
• при запуске контейнера

31. Конфигурация
• Общее K/V хранилище
• Сервис должен быть заточен под смену конфигурации
• Микс вариаций с приоритетами:
<СЕРВИС>/ (/conf/ms/recorder/)
<СЕРВИС>/<ВЕРСИЯ>/ (/conf/ms/recorder/0.12)
<СЕРВИС>/<СРЕДА>/
<СЕРВИС>/<ВЕРСИЯ>/<СРЕДА>/
<СЕРВИС>/<ВЕРСИЯ>/<НОДА>/

32. Конфигурация
1. git2consul
• не используем отдельные проекты/бранчи в git для основных параметров
• загружаем конфигурацию при деплое
• стартовый путь:
/conf/ms/<ИМЯ СЕРВИСА>/<BUILD NO>/
2. Vault
все секретное храним в отдельных проектах

33. Мониторинг

37. 736

38. Как решать?

39. Как решать?
• Помнить, что микросервисы — они как PHP, только микросервисы

40. Как решать?
• Помнить, что микросервисы — они как PHP, только микросервисы
• Вместо полноценного мониторинга — строим dashboard

41. Как решать?
• Помнить, что микросервисы — они как PHP, только микросервисы
• Вместо полноценного мониторинга — строим dashboard
• Алерты по статистическим и пороговым значениям вместо бинарных

42. Как решать?
• Помнить, что микросервисы — они как PHP, только микросервисы
• Вместо полноценного мониторинга — строим dashboard
• Алерты по статистическим и пороговым значениям вместо бинарных
• На одном dashboard сводить графики хост-машин и статистики
по docker-демону

43. Наш стек

44. 1. Сбор метрик - это важно, но еще важнее постоянный анализ полученных
данных
2. Система мониторинга должна быть более надежной и масштабируемой,
чем то, что она контролирует
3. Система должна быть оптимизирована для распределенных,
недолговечных, облачных, контейнеризованных микросервисов
4. Собирайте метрики часто … очень часто …
Стремитесь к интервалам < 10 сек
Общие рекомендации

45. Тестирование

46. В чем сложность?
1. Корректность взаимодействия с другими сервисами

47. В чем сложность?
1. Корректность взаимодействия с другими сервисами
2. Сервис назначения доступен, но:
• Отвечает очень медленно
• Отвечает эпизодически
• Отвечает некорректно

48. В чем сложность?
1. Корректность взаимодействия с другими сервисами
2. Сервис назначения доступен, но:
• Отвечает очень медленно
• Отвечает эпизодически
• Отвечает некорректно
Circuit Breaker!

49. В чем сложность?
1. Корректность взаимодействия с другими сервисами
2. Сервис назначения доступен, но:
• Отвечает очень медленно
• Отвечает эпизодически
• Отвечает некорректно
Circuit Breaker!
[Hystrix, Netflix]

50. Этапы тестирования

51. Тестовый
кластер
Raspberry
Pi 3 - 6шт
Фото: pocketcluster.wordpress.com

52. Хранение

53. Что пробовали?
• Проброс файловой системы в контейнер

54. Что пробовали?
• Проброс файловой системы в контейнер
• «Собирающие контейнеры»

55. Что пробовали?
• Проброс файловой системы в контейнер
• «Собирающие контейнеры»
• Shared data volume

56. Что пробовали?
• Проброс файловой системы в контейнер
• «Собирающие контейнеры»
• Shared data volume
• Flocker

57. Для файлового
хранения
Распределенная файловая система:
CEPH (http://ceph.com/)

58. Для БД
• Выделенные сервера
• Особая конфигурация машин
• Расширенная сеть

59. Обнаружение
сервисов

60. Реестр сервисов
• consul — key/value хранилище, DNS, Health-Check, работа с несколькими ДЦ из коробки
• etcd — key/value хранилище
• skydock — Health-Check, регистрация docker-контейнеров
• skydns — DNS
• Apache Zookeeper — вариация key/value хранилища, сервис блокировок, вариация на тему DNS
• !redis — запись только в мастер, нет механизма достижения консенсуса при определении
актуального состояния данных после выхода из строя отдельных узлов хранилища

61. Оркестрация
• docker swarm [1.2.2] — доставка, регистрация, масштабирование (consul)
• nomad [0.3.2] — доставка, регистрация, масштабирование (consul)
• kubernetes [1.2.4] — доставка, регистрация, масштабирование, LB (etcd)
• mesos [0.28.1] (marathon [1.1.1]) — доставка, регистрация,
масштабирование, LB (zookeeper, HAProxy)

62. Consul Template
{{range services}}{{ if in .Tags "demo" }}{{if .Tags | join "," | regexMatch "urlprefix-"}}
upstream {{.Name}} {
least_conn;
{{range service .Name}}server {{.Address}}:{{.Port}} max_fails=3 fail_timeout=30 weight=1;{{end}}
}
{{end}}{{end}}{{end}}
server {
listen 80 default_server;
location /health {
add_header Content-Type text/plain;
return 200 'OK';
}
{{range services}}{{ if in .Tags "demo" }}{{if .Tags | join "," | regexMatch "urlprefix-"}}
{{range .Tags}}{{ if . | contains "urlprefix-" }}location {{. | replaceAll "urlprefix-" ""}} { {{end}}{{end}}
proxy_pass http://{{.Name}}/; # / в конце означает обрезку проксируемого пути
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
{{end}}{{end}}{{end}}
}

63. Consul Template
{{range services}}
{{ if in .Tags "demo" }}
{{if .Tags | join "," | regexMatch “urlprefix-“}} #urlprefix-/playlist
upstream {{.Name}} {
least_conn;
{{range service .Name}}server {{.Address}}:{{.Port}} max_fails=3
fail_timeout=30 weight=1;{{end}}
}
{{end}}
{{end}}
{{end}}
в списке только
прошедшие
health-check!

64. Consul Template
{{range services}}
{{ if in .Tags "demo" }}
{{if .Tags | join "," | regexMatch "urlprefix-"}}
{{range .Tags}}{{ if . | contains "urlprefix-" }}
# Tag: urlprefix-/playlist
location {{. | replaceAll "urlprefix-" ""}} {
{{end}}{{end}}
proxy_pass http://{{.Name}}/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
{{end}}{{end}}{{end}}

65. Consul Template
upstream playlistapi {
least_conn;
server 10.1.1.2:5100 max_fails=3 fail_timeout=30 weight=1;
}
...
location /playlist {
proxy_pass http://playlistapi/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}

66. http://bit.ly/1TE1KdM
Исходные коды примера

67. Чек-лист
Как конфигурировать?
Как мониторить и считать метрики?
Как сервисы будут находить друг друга?
Как сервис будет взаимодействовать с остальными частями проекта?
Как тестировать сервис и систему целиком?
Как обрабатывать сбои связанных сервисов?
Как переезжать на новую версию?
Как масштабировать под нагрузкой?

68. Спасибо!
Вадим Мадисон
М-Тех
vmadison@rutube.ru