Successfully reported this slideshow.
Your SlideShare is downloading. ×

Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павлов, Сергей Шумов (News360)

Ad

Микросервисы:
удобно, надежно,
серебрянопульно
Евгений Павлов
Сергей Шумов

Ad

Кто мы?
News360 – новостной агрегатор
• 6M загрузок
• 100K активных пользователей
• 30000 источников
Native.AI – аналитика...

Ad

Что было
• SOA
• Большие сервисы
• Legacy код
• Одна платформа

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Check these out next

1 of 29 Ad
1 of 29 Ad

Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павлов, Сергей Шумов (News360)

Download to read offline

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

Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.

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

Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.

Advertisement
Advertisement

More Related Content

Slideshows for you (18)

Viewers also liked (20)

Advertisement

More from Ontico (20)

Advertisement

Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павлов, Сергей Шумов (News360)

  1. 1. Микросервисы: удобно, надежно, серебрянопульно Евгений Павлов Сергей Шумов
  2. 2. Кто мы? News360 – новостной агрегатор • 6M загрузок • 100K активных пользователей • 30000 источников Native.AI – аналитика • 20M событий в день • 100M в перспективе • Трекинг Reuters.com
  3. 3. Что было • SOA • Большие сервисы • Legacy код • Одна платформа
  4. 4. Проблемы • Поддержка • Обновление • Производительность • Инструменты
  5. 5. Что мы сделали Дробление сервисов на более мелкие Использование подходящих языков и технологий Плавная миграция на открытые решения
  6. 6. Микросервисы • Сервис, который можно написать за 2 недели • Single responsibility • Bounded context
  7. 7. Преимущества микросервисов • Независимое обновление • Масштабирование • Возможность экспериментировать • Простота • Поддержка любым разработчиком • Адаптация под требования
  8. 8. Search Crawler Система поиска статей Scheduler API Crawler Article Extractor Renderer IndexerSearch API Elastic Search
  9. 9. Типы коммуникации • RPC (HTTP) • Message bus (RabbitMQ, Kafka) • Permanent connect (TCP)
  10. 10. Система поиска статей Scheduler API Crawler Article Extractor Renderer IndexerSearch API HTTP HTTPHTTP HTTPRabbitMQ RabbitMQ HTTP RabbitMQ Elastic Search
  11. 11. Формат сообщений Типы сообщений: • Text (Json) – общий формат • Binary (Protobuf) - highload Best practices: • Cross-platform contracts • Cross-platform data types
  12. 12. Система поиска статей Scheduler API Crawler Article Extractor Renderer IndexerSearch API HTTP HTTPHTTP HTTPRabbitMQ RabbitMQ HTTP RabbitMQ Elastic Search Protobuf JSON JSON JSON JSONJSON
  13. 13. Communication bad practices • Платформо-зависимые технологии • Свои библиотеки для RPC • Свои библиотеки-клиенты • DTO в библиотеках • Общий DTO для многих сервисов
  14. 14. Deployment • Windows service • IIS web service • Self-host web service • Linux services in Docker • Rancher orchestration
  15. 15. Мониторинг • Логи • Метрики сервисов • Сервис status API (HTTP) • Мониторинг машин • Мониторинг очередей
  16. 16. Логи • Logstash + centralized file storage • ElasticsSearch + fluentd + Kibana • Структурированные логи (json)
  17. 17. Метрики • Graphite + Grafana (statsd) • Zabbix + Grafana integration • Riemann + InfluxDB – отказались
  18. 18. Масштабирование • Вручную для Windows сервисов • Nginx http load balancer • Rancher – автоматизированно • Auto-scaling – не используем
  19. 19. Отказоустойчивость • Готовность к падению другого сервиса • Деградация функциональности • Отсутствие зависаний – лучше падение
  20. 20. Отказоустойчивость - техники • Сonnection restoring • Retries • Timeouts • Message bus - exactly once delivery • HealthChecks
  21. 21. Message bus техники • Messages reject • RabbitMQ Dead Letter Exchanges (DLX) • Long retries on DLX
  22. 22. Long retries on RabbitMQ Input queue Error queue Input queue DLX Retry queue DLX Reject TTL Retry queue Service PublishConsume
  23. 23. Continuous integration • Build CI – unit and integration • Deploy CI – service functional tests • Commit CI – Drone.io
  24. 24. Документация • Swagger для http-сервисов • README.md • Описание сервиса в Wiki • Сводная таблица сервисов • Архитектурные диаграммы
  25. 25. Документация для сервиса • Краткое описание функциональности • Репозиторий • Конфиги • Деплои • Логи • Мониторинг • Тесты • Внешние зависимости • Требования к производительности • Критичность • Ответственный
  26. 26. Стандартизация • Стандарты использования технологий • Шаблоны микросервисов • Логи, мониторинг и т.д. • Сode conventions Свобода Скорость ?
  27. 27. Практики разработки • Ответственность - Owner, team • 1-2 разработчика на сервис • Сross-team code review • Git-репозиторий для сервиса • Минимизация зависимостей • Уменьшать связанность сервисов • Часто копи-паст лучше
  28. 28. Трудности • Схема взаимодействия сервисов • Актуальность диаграмм • Много рутины • Глобальный рефакторинг архитектуры • Зоопарк технологий
  29. 29. Спасибо за внимание! Вопросы?

×