В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться. Микросервисы. Зачем они вообще: - В простых сервисах легче разбираться и локализовывать проблемы. - В микросервисной архитектуре проще добиваться отказоустойчивости. - Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее. - Независимое обновление компонентов. - Тестирование частей системы. Как: - 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: описание архитектуры обязано быть актуальным и полным, иначе беда. Трудности: Допишу через пару дней.

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

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

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

4. Проблемы
• Поддержка
• Обновление
• Производительность
• Инструменты

5. Что мы сделали
Дробление сервисов на более мелкие
Использование подходящих языков и технологий
Плавная миграция на открытые решения

6. Микросервисы
• Сервис, который можно написать
за 2 недели
• Single responsibility
• Bounded context

7. Преимущества микросервисов
• Независимое обновление
• Масштабирование
• Возможность экспериментировать
• Простота
• Поддержка любым разработчиком
• Адаптация под требования

8. Search
Crawler
Система поиска статей
Scheduler
API
Crawler
Article
Extractor
Renderer
IndexerSearch API Elastic
Search

9. Типы коммуникации
• RPC (HTTP)
• Message bus (RabbitMQ, Kafka)
• Permanent connect (TCP)

10. Система поиска статей
Scheduler
API
Crawler
Article
Extractor
Renderer
IndexerSearch API
HTTP
HTTPHTTP
HTTPRabbitMQ
RabbitMQ
HTTP
RabbitMQ
Elastic
Search

11. Формат сообщений
Типы сообщений:
• Text (Json) – общий формат
• Binary (Protobuf) - highload
Best practices:
• Cross-platform contracts
• Cross-platform data types

12. Система поиска статей
Scheduler
API
Crawler
Article
Extractor
Renderer
IndexerSearch API
HTTP
HTTPHTTP
HTTPRabbitMQ
RabbitMQ
HTTP
RabbitMQ
Elastic
Search
Protobuf JSON
JSON
JSON
JSONJSON

13. Communication bad practices
• Платформо-зависимые технологии
• Свои библиотеки для RPC
• Свои библиотеки-клиенты
• DTO в библиотеках
• Общий DTO для многих сервисов

14. Deployment
• Windows service
• IIS web service
• Self-host web service
• Linux services in Docker
• Rancher orchestration

15. Мониторинг
• Логи
• Метрики сервисов
• Сервис status API (HTTP)
• Мониторинг машин
• Мониторинг очередей

16. Логи
• Logstash + centralized file storage
• ElasticsSearch + fluentd + Kibana
• Структурированные логи (json)

17. Метрики
• Graphite + Grafana (statsd)
• Zabbix + Grafana integration
• Riemann + InfluxDB – отказались

18. Масштабирование
• Вручную для Windows сервисов
• Nginx http load balancer
• Rancher – автоматизированно
• Auto-scaling – не используем

19. Отказоустойчивость
• Готовность к падению другого
сервиса
• Деградация функциональности
• Отсутствие зависаний –
лучше падение

20. Отказоустойчивость - техники
• Сonnection restoring
• Retries
• Timeouts
• Message bus - exactly once delivery
• HealthChecks

21. Message bus техники
• Messages reject
• RabbitMQ Dead Letter Exchanges (DLX)
• Long retries on DLX

22. Long retries on RabbitMQ
Input
queue
Error
queue
Input queue DLX
Retry queue DLX
Reject
TTL Retry
queue
Service
PublishConsume

23. Continuous integration
• Build CI – unit and integration
• Deploy CI – service functional tests
• Commit CI – Drone.io

24. Документация
• Swagger для http-сервисов
• README.md
• Описание сервиса в Wiki
• Сводная таблица сервисов
• Архитектурные диаграммы

25. Документация для сервиса
• Краткое описание
функциональности
• Репозиторий
• Конфиги
• Деплои
• Логи
• Мониторинг
• Тесты
• Внешние зависимости
• Требования к
производительности
• Критичность
• Ответственный

26. Стандартизация
• Стандарты использования технологий
• Шаблоны микросервисов
• Логи, мониторинг и т.д.
• Сode conventions
Свобода
Скорость
?

27. Практики разработки
• Ответственность - Owner, team
• 1-2 разработчика на сервис
• Сross-team code review
• Git-репозиторий для сервиса
• Минимизация зависимостей
• Уменьшать связанность сервисов
• Часто копи-паст лучше

28. Трудности
• Схема взаимодействия сервисов
• Актуальность диаграмм
• Много рутины
• Глобальный рефакторинг
архитектуры
• Зоопарк технологий

29. Спасибо за внимание!
Вопросы?