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.

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

2,521 views

Published on

Мы прошли довольно большой путь в разработке через микросервисы.

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

Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.

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

Published in: Engineering
  • Be the first to comment

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

  1. 1. Микросервисы: опыт использования в нагруженном проекте Вадим Мадисон
 М-Тех
  2. 2. • Услуги системной интеграции, начиная от разработки технологических решений и заканчивая доставкой видео-сигнала до конечного пользователя • Интернет-видеоплатформа для каналов МатчТВ и НТВ-ПЛЮС • 300 000 одновременных пользователей • > 1 000 000 уникальных посетителей в сутки • Отдаем контента до 300 Тб/час
  3. 3. Про что эта история?
  4. 4. История про … • Рост проекта • Развитие • Переосмысление работы системы и отдельных компонентов
  5. 5. История про … Масштабирование
  6. 6. Пройденный путь
  7. 7. Начало времен • 2 сервера в docker-кластере • DB запускается на тех же машинах, в контейнерах • Выделенного хранилища как такового нет • Инфраструктура минимальна
  8. 8. Docker TeamCity
  9. 9. Середина пути • 80 серверов в docker-кластере • Хранилище на базе CEPH • DB запускается на отдельных серверах • Пересмотр взаимодействия между сервисами • Выделенный мониторинг
  10. 10. Наши дни • Несколько сотен серверов в docker-кластере • Сотни запущенных микросервисов • Выделение сервисов в отдельные зоны • Кластеризация шин обмена сообщениями между сервисами
  11. 11. Транспорт
  12. 12. Транспорт protobuf → gRPC → JSON
  13. 13. protobuf Плюсы • Достаточно компактен • Есть быстрые реализации • Условно типизирован Минусы • протокол становится “проприетарным” • требуется поддерживать в актуальном состоянии утилиты для обращению к сервису
  14. 14. protobuf Плюсы • Достаточно компактен • Есть быстрые реализации • Условно типизирован Минусы • протокол становится “проприетарным” • требуется поддерживать в актуальном состоянии утилиты для обращения к сервису
  15. 15. Транспорт protobuf → gRPC → JSON
  16. 16. Docker TeamCity
  17. 17. gRPC Плюсы • HTTP/2 • Эффективность передачи • Работает из коробки • Поддержка основных серверных языков • Поддержка основных клиентских языков Минусы • Вещь в себе • Сложность реализации собственной логики • Доступ к логам через собственные обертки и парсеры • Сложность работы в динамичной среде
  18. 18. gRPC Плюсы • HTTP/2 • Эффективность передачи • Работает из коробки • Поддержка основных серверных языков • Поддержка основных клиентских языков Минусы • Вещь в себе • Сложность реализации собственной логики • Доступ к логам через собственные обертки и парсеры • Усиливает зависимости между сервисами • Сложно версионируется
  19. 19. Транспорт protobuf → gRPC → JSON
  20. 20. Docker TeamCity JSON
  21. 21. JSON Плюсы • “Можно” HTTP/2 • Есть очень быстрые реализации • Поддержка повсеместно • Не требуется разрабатывать дополнительный инструментарий • Позволяется работать с “частью данных”
  22. 22. JSON Плюсы • “Можно” HTTP/2 • Есть очень быстрые реализации • Поддержка повсеместно • Не требуется разрабатывать дополнительный инструментарий • Позволяется работать с “частью данных” Минусы • Не компактен • Не типизирован
  23. 23. Версионирование протокола
  24. 24. Версионирование протокола V1,V2,… → V1 + schema
  25. 25. Версионирование протокола V1,V2,… → V1 + schema /api/v1/content /api/v2/content → /api/v1/content + JSON Schema v1.X /api/v3/content
  26. 26. { "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" }
  27. 27. { "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"] }
  28. 28. { "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"] }
  29. 29. Стабильность работы
  30. 30. Docker TeamCity JSON Grafana
  31. 31. Выводы • Основная проблема — частично работающий сервис • Мертвый сервис - хорошо! • Каждый сервис должен знать свой лимит (Rate limit)! • Защита - паттерн Circuit Breaker
  32. 32. Выводы • Основная проблема — частично работающий сервис • Мертвый сервис — хорошо! • Каждый сервис должен знать свой лимит (Rate limit)! • Защита - паттерн Circuit Breaker
  33. 33. Выводы • Основная проблема — частично работающий сервис • Мертвый сервис — хорошо! • Каждый сервис должен знать свой лимит (Rate limit)! • Защита - паттерн Circuit Breaker
  34. 34. Выводы • Основная проблема — частично работающий сервис • Мертвый сервис — хорошо! • Каждый сервис должен знать свой лимит (Rate limit)! • Защита — паттерн Circuit Breaker
  35. 35. Docker TeamCity JSON Grafana Hystrix
  36. 36. Исполнение запроса
  37. 37. 1 2 3 4 5
  38. 38. Docker TeamCity JSON Grafana HystrixAppdash
  39. 39. Docker TeamCity JSON Grafana Hystrix
  40. 40. общее время
  41. 41. общее время Обращение к БД
 внутри сервиса
  42. 42. TraceID: 19502dcb3e187d615eacf73a0ba1bfe0
  43. 43. Docker TeamCity JSON Grafana HystrixOpentracing
  44. 44. Логирование
  45. 45. Docker TeamCity JSON Grafana HystrixOpentracingElastic + Kibana
  46. 46. Логирование: сбор логов
  47. 47. Логирование • добавляем TraceID в логи • строим Dashboard фильтром по TraceID • динамический DEBUG MODE
  48. 48. Логирование • добавляем TraceID в логи • строим Dashboard фильтром по TraceID • динамический DEBUG MODE
  49. 49. Агрегирование ошибок
  50. 50. Docker TeamCity JSON Grafana HystrixOpentracingElastic + Kibana Sentry
  51. 51. Масштабирование
  52. 52. Docker TeamCity JSON Grafana HystrixOpentracingElastic + Kibana Sentry Nomad
  53. 53. Docker TeamCity JSON Grafana HystrixOpentracingElastic + Kibana Sentry Consul VaultNomad
  54. 54. Docker TeamCity JSON Grafana HystrixOpentracingElastic + Kibana Sentry Consul VaultKubernetes
  55. 55. Стандартизация: RAM-CPU-NET
  56. 56. Стандартизация: R3-C2-N1
  57. 57. Стандартизация: матрица размерностей 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
  58. 58. Стандартизация •N1C3R1 → [10 Mb] [3000 MHz] [128 MB] •N1C2R3 → [10 Mb] [1500 MHz] [1 GB]
  59. 59. Стандартизация •N1C3R1 → [10 Mb] [3000 MHz] [128 MB] •N1C2R3 → [10 Mb] [1000 MHz] [1 GB]
  60. 60. Подготовка: тип масштабируемости • Сервис полностью независим → тестируем предел для одного инстанса → тестируем 2 инстанса, чтобы проверить линейность
 • Масштабируемость зависит от внешних ресурсов → при нагрузочном тестировании проводим
 несколько раундов тестирования с увеличением 
 количества инстансов
 • Масштабируемость ограничена определенным лимитом → порог указывается в точке конфигурирования сервиса
  61. 61. Подготовка: тип масштабируемости • Сервис полностью независим → тестируем предел для одного инстанса → тестируем 2 инстанса, чтобы проверить линейность
 • Масштабируемость зависит от внешних ресурсов → при нагрузочном тестировании проводим
 несколько раундов тестирования с увеличением 
 количества инстансов
 • Масштабируемость ограничена определенным лимитом → порог указывается в точке конфигурирования сервиса
  62. 62. Подготовка: тип масштабируемости • Сервис полностью независим → тестируем предел для одного инстанса → тестируем 2 инстанса, чтобы проверить линейность
 • Масштабируемость зависит от внешних ресурсов → при нагрузочном тестировании проводим
 несколько раундов тестирования с увеличением 
 количества инстансов
 • Масштабируемость ограничена определенным лимитом → порог указывается в точке конфигурирования сервиса
  63. 63. Подготовка: нагрузочное тестирование
  64. 64. Docker JSON Grafana HystrixOpentracingElastic + Kibana Sentry Consul VaultKubernetes Gitlab CI TeamCity
  65. 65. Рекомендации • Начинайте разработку сразу с использованием системы оркестрации • В каждый момент времени помните, что каждого инстанса сервиса должно быть не меньше 2-х • Шина сообщений, блокировки и очереди - наше все • Не нужно пытаться поднять/починить сервис - нужно отстрелить его и потом попробовать понять, что не так • Собирайте метрики и работайте с ними • Выдавайте алерты только там, где требуется реакция
  66. 66. Рекомендации • Начинайте разработку сразу с использованием системы оркестрации • В каждый момент времени помните, что каждого инстанса сервиса должно быть не меньше 2-х • Шина сообщений, блокировки и очереди - наше все • Не нужно пытаться поднять/починить сервис - нужно отстрелить его и потом попробовать понять, что не так • Собирайте метрики и работайте с ними • Выдавайте алерты только там, где требуется реакция
  67. 67. Рекомендации • Начинайте разработку сразу с использованием системы оркестрации • В каждый момент времени помните, что каждого инстанса сервиса должно быть не меньше 2-х • Шина сообщений, блокировки и очереди — наше все • Не нужно пытаться поднять/починить сервис - нужно отстрелить его и потом попробовать понять, что не так • Собирайте метрики и работайте с ними • Выдавайте алерты только там, где требуется реакция
  68. 68. Рекомендации • Начинайте разработку сразу с использованием системы оркестрации • В каждый момент времени помните, что каждого инстанса сервиса должно быть не меньше 2-х • Шина сообщений, блокировки и очереди — наше все • Не нужно пытаться поднять/починить сервис — нужно отстрелить его и потом попробовать понять, что не так • Собирайте метрики и работайте с ними • Выдавайте алерты только там, где требуется реакция
  69. 69. Рекомендации • Начинайте разработку сразу с использованием системы оркестрации • В каждый момент времени помните, что каждого инстанса сервиса должно быть не меньше 2-х • Шина сообщений, блокировки и очереди — наше все • Не нужно пытаться поднять/починить сервис — нужно отстрелить его и потом попробовать понять, что не так • Собирайте метрики и работайте с ними • Выдавайте алерты только там, где требуется реакция
  70. 70. Рекомендации • Начинайте разработку сразу с использованием системы оркестрации • В каждый момент времени помните, что каждого инстанса сервиса должно быть не меньше 2-х • Шина сообщений, блокировки и очереди — наше все • Не нужно пытаться поднять/починить сервис — нужно отстрелить его и потом попробовать понять, что не так • Собирайте метрики и работайте с ними • Выдавайте алерты только там, где требуется реакция
  71. 71. Спасибо! Вадим Мадисон М-Тех vadim.madison@gmail.com vmadison@media-t.ru

×