Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
2. • Услуги системной интеграции, начиная от разработки
технологических решений и заканчивая доставкой видео-сигнала до
конечного пользователя
• Интернет-видеоплатформа для каналов МатчТВ и НТВ-ПЛЮС
• 300 000 одновременных пользователей
• > 1 000 000 уникальных посетителей в сутки
• Отдаем контента до 300 Тб/час
7. Начало времен
• 2 сервера в docker-кластере
• DB запускается на тех же машинах, в контейнерах
• Выделенного хранилища как такового нет
• Инфраструктура минимальна
9. Середина пути
• 80 серверов в docker-кластере
• Хранилище на базе CEPH
• DB запускается на отдельных серверах
• Пересмотр взаимодействия между сервисами
• Выделенный мониторинг
10. Наши дни
• Несколько сотен серверов в docker-кластере
• Сотни запущенных микросервисов
• Выделение сервисов в отдельные зоны
• Кластеризация шин обмена сообщениями между сервисами
15. protobuf
Плюсы
• Достаточно компактен
• Есть быстрые реализации
• Условно типизирован
Минусы
• протокол становится
“проприетарным”
• требуется поддерживать в
актуальном состоянии
утилиты для обращению к
сервису
16. protobuf
Плюсы
• Достаточно компактен
• Есть быстрые реализации
• Условно типизирован
Минусы
• протокол становится
“проприетарным”
• требуется поддерживать в
актуальном состоянии
утилиты для обращения к
сервису
19. gRPC
Плюсы
• HTTP/2
• Эффективность передачи
• Работает из коробки
• Поддержка основных
серверных языков
• Поддержка основных
клиентских языков
Минусы
• Вещь в себе
• Сложность реализации
собственной логики
• Доступ к логам через
собственные обертки и
парсеры
• Сложность работы в
динамичной среде
20. gRPC
Плюсы
• HTTP/2
• Эффективность передачи
• Работает из коробки
• Поддержка основных
серверных языков
• Поддержка основных
клиентских языков
Минусы
• Вещь в себе
• Сложность реализации
собственной логики
• Доступ к логам через
собственные обертки и
парсеры
• Усиливает зависимости
между сервисами
• Сложно версионируется
23. JSON
Плюсы
• “Можно” HTTP/2
• Есть очень быстрые
реализации
• Поддержка повсеместно
• Не требуется разрабатывать
дополнительный
инструментарий
• Позволяется работать с
“частью данных”
24. JSON
Плюсы
• “Можно” HTTP/2
• Есть очень быстрые
реализации
• Поддержка повсеместно
• Не требуется разрабатывать
дополнительный
инструментарий
• Позволяется работать с
“частью данных”
Минусы
• Не компактен
• Не типизирован
34. Выводы
• Основная проблема — частично работающий сервис
• Мертвый сервис - хорошо!
• Каждый сервис должен знать свой лимит (Rate limit)!
• Защита - паттерн Circuit Breaker
35. Выводы
• Основная проблема — частично работающий сервис
• Мертвый сервис — хорошо!
• Каждый сервис должен знать свой лимит (Rate limit)!
• Защита - паттерн Circuit Breaker
36. Выводы
• Основная проблема — частично работающий сервис
• Мертвый сервис — хорошо!
• Каждый сервис должен знать свой лимит (Rate limit)!
• Защита - паттерн Circuit Breaker
37. Выводы
• Основная проблема — частично работающий сервис
• Мертвый сервис — хорошо!
• Каждый сервис должен знать свой лимит (Rate limit)!
• Защита — паттерн Circuit Breaker
67. Подготовка: тип масштабируемости
• Сервис полностью независим
→ тестируем предел для одного инстанса
→ тестируем 2 инстанса, чтобы проверить линейность
• Масштабируемость зависит от внешних ресурсов
→ при нагрузочном тестировании проводим
несколько раундов тестирования с увеличением
количества инстансов
• Масштабируемость ограничена определенным лимитом
→ порог указывается в точке конфигурирования сервиса
68. Подготовка: тип масштабируемости
• Сервис полностью независим
→ тестируем предел для одного инстанса
→ тестируем 2 инстанса, чтобы проверить линейность
• Масштабируемость зависит от внешних ресурсов
→ при нагрузочном тестировании проводим
несколько раундов тестирования с увеличением
количества инстансов
• Масштабируемость ограничена определенным лимитом
→ порог указывается в точке конфигурирования сервиса
69. Подготовка: тип масштабируемости
• Сервис полностью независим
→ тестируем предел для одного инстанса
→ тестируем 2 инстанса, чтобы проверить линейность
• Масштабируемость зависит от внешних ресурсов
→ при нагрузочном тестировании проводим
несколько раундов тестирования с увеличением
количества инстансов
• Масштабируемость ограничена определенным лимитом
→ порог указывается в точке конфигурирования сервиса
75. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди - наше все
• Не нужно пытаться поднять/починить сервис - нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция
76. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди - наше все
• Не нужно пытаться поднять/починить сервис - нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция
77. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди — наше все
• Не нужно пытаться поднять/починить сервис - нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция
78. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди — наше все
• Не нужно пытаться поднять/починить сервис — нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция
79. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди — наше все
• Не нужно пытаться поднять/починить сервис — нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция
80. Рекомендации
• Начинайте разработку сразу с использованием системы
оркестрации
• В каждый момент времени помните, что каждого инстанса
сервиса должно быть не меньше 2-х
• Шина сообщений, блокировки и очереди — наше все
• Не нужно пытаться поднять/починить сервис — нужно
отстрелить его и потом попробовать понять, что не так
• Собирайте метрики и работайте с ними
• Выдавайте алерты только там, где требуется реакция