23 вопросов
Подход к архитектуре: приложение как набор небольших независимых сервисов, каждый в своем процессе, с отдельной БД и API. Коммуникация по сети (HTTP, gRPC, очереди). Плюсы: независимое развертывание, масштабирование по сервисам, технологическое разнообразие. Минусы: сложность операций, распределенные отказы, консистентность.
Плюсы: независимый деплой и масштабирование, технологическая свобода, отказоустойчивость по сервисам. Минусы: сложность операций, распределенные транзакции и отладка, сетевые задержки, дублирование данных и логики.
При малой команде, простом домене, необходимости быстрого старта. Монолит проще разрабатывать и деплоить. Микросервисы оправданы при росте команды, разных требованиях к масштабированию и надежности компонентов.
Постепенная миграция с монолита: новый функционал в сервисах, трафик переводится на них; старый код со временем "обвивается" и заменяется. Снижает риск большого переписывания.
Синхронная (HTTP, gRPC): простой запрос-ответ, но связь и каскадные отказы. Асинхронная (очереди, события): развязка, устойчивость к сбоям, eventual consistency. Выбор по требованию к консистентности и задержке.
Паттерн распределенных транзакций: последовательность локальных транзакций с компенсирующими действиями при откате. Choreography (события) или Orchestration (центральный координатор). Нет ACID между сервисами.
При повторных сбоях вызова сервиса переключается в "открытое" состояние - вызовы не выполняются, возвращается ошибка. После таймаута - попытка (half-open). Защита от каскадных сбоев и перегрузки.
Паттерн надежной доставки: запись бизнес-данных и сообщения в одну БД в одной транзакции (outbox-таблица); отдельный процесс читает outbox и публикует в брокер. Гарантия "ровно один раз" публикации при идемпотентном потребителе.
Хранение состояния как лога событий; текущее состояние восстанавливается применением событий. Полная история, аудит, воспроизведение. CQRS часто сочетают с event sourcing. Сложность в миграциях и запросах.
Механизм поиска экземпляров сервисов по имени (DNS, Consul, etcd, Kubernetes Services). Клиент не знает IP; получает актуальный список при обращении. Регистрация при старте, снятие при остановке.
Единая точка входа: маршрутизация, аутентификация, rate limiting, агрегация ответов. Клиенты обращаются к шлюзу, шлюз - к сервисам. Упрощение клиентов и централизация кросс-срезовых задач.
Backend for Frontend - отдельный слой API под конкретный клиент (веб, мобильное приложение). Агрегирует вызовы к сервисам, адаптирует формат. Уменьшает число запросов и связность клиента с множеством сервисов.
Обратное давление: при перегрузке потребитель сигнализирует производителю замедлиться или приостановиться. Предотвращение переполнения очередей и падения потребителя. Реализация в реактивных потоках и очередях.
При сбое зависимого сервиса приложение снижает функциональность, но продолжает работать. Кеш, заглушки, отключение не критичных фич. Цель - доступность и приемлемый UX при частичных сбоях.
Повтор запроса при временной ошибке; backoff - увеличение паузы между попытками (например, удвоение). Ограничение числа попыток и максимальной паузы. Jitter для разброса нагрузки. Не ретраить идемпотентные мутации без идемпотентного ключа.
Изоляция ресурсов: пулы потоков/соединений разделены по сервисам или по типу запросов. Сбой или перегрузка одного не исчерпывают общий пул. По аналогии с отсеками на корабле.
Уникальный идентификатор запроса, передается по всей цепочке вызовов (заголовок, лог). Позволяет связать логи и трейсы одного запроса в разных сервисах. Критично для отладки распределенных систем.
Таймауты должны задаваться на каждом уровне (клиент, шлюз, сервис). Каскадные таймауты: общий таймаут запроса распределять по вызовам. Не оставлять бесконечные ожидания - иначе накопление зависших соединений.
Endpoint (например, /health) для проверки живости и готовности. Liveness - жив ли процесс; readiness - готов ли принимать трафик (БД, кеш). Оркестратор и балансировщики используют для маршрутизации и рестартов.
Dead Letter Queue - очередь для сообщений, которые не удалось обработать после N попыток. Анализ, ручная обработка или повторная публикация. Не терять сообщения и не блокировать основную очередь.
Вертикальное - больший сервер (CPU, RAM). Проще, но есть предел и single point of failure. Горизонтальное - больше экземпляров, балансировка. Лучше для отказоустойчивости и роста. Микросервисы ориентированы на горизонтальное.
Распределение запросов между экземплярами сервиса. Алгоритмы: round-robin, least connections, IP hash. Health checks для исключения нерабочих. Слой 4 (TCP) или уровень 7 (HTTP). Sticky session при необходимости.
ESB (Enterprise Service Bus) - центральный брокер интеграции, трансформации, оркестрация. Тяжелый, монолитный. API Gateway - единая точка входа для API, маршрутизация и кросс-срезовые задачи. Современные системы чаще Gateway и прямая коммуникация сервисов.