Микросервисы: удобно, надежно, серебрянопульно Архитектуры
Возглавляет команду backend разработчиков в News360. Разработал приложение для графовых операций на большом объёме данных (сотни миллионов узлов, десятки миллиардов рёбер) в Сбербанк-Технологии.
Разработал и внедрил систему сбора и обработки данных из социальных сетей в компании Инфорион. В проекте использовались Apache Spark, Apache Kafka и ElasticSearch. Ключевыми особенностями системы является высокая нагруженность подсистемы сбора и аналитики. Объём данных: терабайты в месяц.
Ведущий разработчик News360. Имеет разносторонний опыт разработки и оптимизации высоконагруженных систем, от нетривиальных корпоративных приложений и наукоемких систем распознавания документов до фреймворков и облачных платформ. Считает главным принципом разработки Keep it simple.
Тезисы
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- 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: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
