Мы прошли довольно большой путь в разработке через микросервисы. Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов. Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным. В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.

1. Микросервисы: опыт
использования в
нагруженном проекте
Вадим Мадисон
М-Тех

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

3. Про что эта история?

4. История про …
• Рост проекта
• Развитие
• Переосмысление работы системы и отдельных компонентов

5. История про …
Масштабирование

6. Пройденный путь

7. Начало времен
• 2 сервера в docker-кластере
• DB запускается на тех же машинах, в контейнерах
• Выделенного хранилища как такового нет
• Инфраструктура минимальна

8. Docker TeamCity

9. Середина пути
• 80 серверов в docker-кластере
• Хранилище на базе CEPH
• DB запускается на отдельных серверах
• Пересмотр взаимодействия между сервисами
• Выделенный мониторинг

10. Наши дни
• Несколько сотен серверов в docker-кластере
• Сотни запущенных микросервисов
• Выделение сервисов в отдельные зоны
• Кластеризация шин обмена сообщениями между сервисами

12. Транспорт

13. Транспорт
protobuf → gRPC → JSON

15. protobuf
Плюсы
• Достаточно компактен
• Есть быстрые реализации
• Условно типизирован
Минусы
• протокол становится
“проприетарным”
• требуется поддерживать в
актуальном состоянии
утилиты для обращению к
сервису

16. protobuf
Плюсы
• Достаточно компактен
• Есть быстрые реализации
• Условно типизирован
Минусы
• протокол становится
“проприетарным”
• требуется поддерживать в
актуальном состоянии
утилиты для обращения к
сервису

17. Транспорт
protobuf → gRPC → JSON

18. Docker TeamCity

19. gRPC
Плюсы
• HTTP/2
• Эффективность передачи
• Работает из коробки
• Поддержка основных
серверных языков
• Поддержка основных
клиентских языков
Минусы
• Вещь в себе
• Сложность реализации
собственной логики
• Доступ к логам через
собственные обертки и
парсеры
• Сложность работы в
динамичной среде

20. gRPC
Плюсы
• HTTP/2
• Эффективность передачи
• Работает из коробки
• Поддержка основных
серверных языков
• Поддержка основных
клиентских языков
Минусы
• Вещь в себе
• Сложность реализации
собственной логики
• Доступ к логам через
собственные обертки и
парсеры
• Усиливает зависимости
между сервисами
• Сложно версионируется

21. Транспорт
protobuf → gRPC → JSON

22. Docker TeamCity JSON

23. JSON
Плюсы
• “Можно” HTTP/2
• Есть очень быстрые
реализации
• Поддержка повсеместно
• Не требуется разрабатывать
дополнительный
инструментарий
• Позволяется работать с
“частью данных”

24. JSON
Плюсы
• “Можно” HTTP/2
• Есть очень быстрые
реализации
• Поддержка повсеместно
• Не требуется разрабатывать
дополнительный
инструментарий
• Позволяется работать с
“частью данных”
Минусы
• Не компактен
• Не типизирован

25. Версионирование протокола

26. Версионирование протокола
V1,V2,… → V1 + schema

27. Версионирование протокола
V1,V2,… → V1 + schema
/api/v1/content
/api/v2/content → /api/v1/content + JSON Schema v1.X
/api/v3/content

28. {
"id": "507f1f77bcf86cd7994390",
"projectId": "507f1f77bcf86cd7994390",
"content": "broadcast",
"name": "Жопоног - Газмяз",
"date" : {
"start": "2005-08-09T18:31:42-03:30",
"end": "2005-08-09T18:31:42-03:30"
},
"source": "http://.../playlist.m3u8",
"extra": {
"videoType": "хоккей",
"description": "Чемпионат мира по
гребной травле тараканов"
},
"listeningStatus": "fail",
"status": "enabled"
}

29. {
"id": "507f1f77bcf86cd7994390",
"projectId": "507f1f77bcf86cd7994390",
"content": "broadcast",
"name": "Жопоног - Газмяз",
"date" : {
"start": "2005-08-09T18:31:42-03:30",
"end": "2005-08-09T18:31:42-03:30"
},
"source": "http://.../playlist.m3u8",
"extra": {
"videoType": "хоккей",
"description": "Чемпионат мира по
гребной травле тараканов ;)"
},
"listeningStatus": "fail",
"status": "enabled"
}
{
"$schema": "…",
"type": "object",
"properties": {
"id": { "type": "string" },
"content": { "type": "string" },
"date": {
"type": "object",
"properties": {
"start": { "type": "string" },
"end": { "type": "string" }
},
"required": ["start","end"]
},
"source": { "type": "string" },
"status": { "type": "string" },
…
},
"required": ["id", "content",
"date", "status"]
}

30. {
"id": "507f1f77bcf86cd7994390",
"content": "broadcast",
"date" : {
"start": "2005-08-09T18:31:42-03:30",
"end": "2005-08-09T18:31:42-03:30"
},
"status": "enabled"
}
{
"$schema": "…",
"type": "object",
"properties": {
"id": { "type": "string" },
"content": { "type": "string" },
"date": {
"type": "object",
"properties": {
"start": { "type": "string" },
"end": { "type": "string" }
},
"required": ["start","end"]
},
"source": { "type": "string" },
"status": { "type": "string" },
…
},
"required": ["id", "content",
"date", "status"]
}

31. Стабильность работы

33. Docker TeamCity JSON Grafana

34. Выводы
• Основная проблема — частично работающий сервис
• Мертвый сервис - хорошо!
• Каждый сервис должен знать свой лимит (Rate limit)!
• Защита - паттерн Circuit Breaker

35. Выводы
• Основная проблема — частично работающий сервис
• Мертвый сервис — хорошо!
• Каждый сервис должен знать свой лимит (Rate limit)!
• Защита - паттерн Circuit Breaker

36. Выводы
• Основная проблема — частично работающий сервис
• Мертвый сервис — хорошо!
• Каждый сервис должен знать свой лимит (Rate limit)!
• Защита - паттерн Circuit Breaker

37. Выводы
• Основная проблема — частично работающий сервис
• Мертвый сервис — хорошо!
• Каждый сервис должен знать свой лимит (Rate limit)!
• Защита — паттерн Circuit Breaker

38. Docker TeamCity JSON Grafana
Hystrix

41. Исполнение запроса

42. 1 2 3
4 5

44. Docker TeamCity JSON Grafana
HystrixAppdash

46. Docker TeamCity JSON Grafana
Hystrix

47. общее время

48. общее время
Обращение к БД
внутри сервиса

49. TraceID: 19502dcb3e187d615eacf73a0ba1bfe0

50. Docker TeamCity JSON Grafana
HystrixOpentracing

51. Логирование

52. Docker TeamCity JSON Grafana
HystrixOpentracingElastic + Kibana

53. Логирование: сбор логов

54. Логирование
• добавляем TraceID в логи
• строим Dashboard фильтром по TraceID
• динамический DEBUG MODE

55. Логирование
• добавляем TraceID в логи
• строим Dashboard фильтром по TraceID
• динамический DEBUG MODE

56. Агрегирование ошибок

57. Docker TeamCity JSON Grafana
HystrixOpentracingElastic + Kibana
Sentry

58. Масштабирование

59. Docker TeamCity JSON Grafana
HystrixOpentracingElastic + Kibana
Sentry Nomad

60. Docker TeamCity JSON Grafana
HystrixOpentracingElastic + Kibana
Sentry Consul VaultNomad

61. Docker TeamCity JSON Grafana
HystrixOpentracingElastic + Kibana
Sentry Consul VaultKubernetes

62. Стандартизация: RAM-CPU-NET

63. Стандартизация: R3-C2-N1

64. Стандартизация: матрица размерностей
CPU RAM NET
C1 = 500 MHz R1 = 128 MB N1 = 10 Mb
C2 = 1000 MHz R2 = 256 MB N2 = 100 Mb
C3 = 3000 Mhz R3 = 512 MB N3 = 1 Gb

65. Стандартизация
•N1C3R1 → [10 Mb] [3000 MHz] [128 MB]
•N1C2R3 → [10 Mb] [1500 MHz] [1 GB]

66. Стандартизация
•N1C3R1 → [10 Mb] [3000 MHz] [128 MB]
•N1C2R3 → [10 Mb] [1000 MHz] [1 GB]

67. Подготовка: тип масштабируемости
• Сервис полностью независим
→ тестируем предел для одного инстанса
→ тестируем 2 инстанса, чтобы проверить линейность
• Масштабируемость зависит от внешних ресурсов
→ при нагрузочном тестировании проводим
несколько раундов тестирования с увеличением
количества инстансов
• Масштабируемость ограничена определенным лимитом
→ порог указывается в точке конфигурирования сервиса

68. Подготовка: тип масштабируемости
• Сервис полностью независим
→ тестируем предел для одного инстанса
→ тестируем 2 инстанса, чтобы проверить линейность
• Масштабируемость зависит от внешних ресурсов
→ при нагрузочном тестировании проводим
несколько раундов тестирования с увеличением
количества инстансов
• Масштабируемость ограничена определенным лимитом
→ порог указывается в точке конфигурирования сервиса

69. Подготовка: тип масштабируемости
• Сервис полностью независим
→ тестируем предел для одного инстанса
→ тестируем 2 инстанса, чтобы проверить линейность
• Масштабируемость зависит от внешних ресурсов
→ при нагрузочном тестировании проводим
несколько раундов тестирования с увеличением
количества инстансов
• Масштабируемость ограничена определенным лимитом
→ порог указывается в точке конфигурирования сервиса

70. Подготовка: нагрузочное тестирование

74. Docker JSON Grafana
HystrixOpentracingElastic + Kibana
Sentry Consul VaultKubernetes Gitlab CI
TeamCity

75. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди - наше все
• Не нужно пытаться поднять/починить сервис - нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция

76. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди - наше все
• Не нужно пытаться поднять/починить сервис - нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция

77. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди — наше все
• Не нужно пытаться поднять/починить сервис - нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция

78. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди — наше все
• Не нужно пытаться поднять/починить сервис — нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция

79. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди — наше все
• Не нужно пытаться поднять/починить сервис — нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция

80. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди — наше все
• Не нужно пытаться поднять/починить сервис — нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция

81. Спасибо!
Вадим Мадисон
М-Тех
vadim.madison@gmail.com
vmadison@media-t.ru