Координация сервисов и управление состоянием

Разработка приложений на AWS

Ricardo Sueiras

Principal Technologist

Координация сервисов

 

• Несколько сервисов совместно выполняют рабочий процесс.
• Им необходима стратегия координации.
• Два подхода: оркестрация и хореография.

Оркестрация

 

• Центральный оркестратор управляет рабочим процессом.
• Он контролирует последовательность и определяет, какой сервис запускается следующим.
• Удобен для повторных попыток, условной логики и обработки ошибок.
• На AWS: реализуется через Step Functions совместно с Lambda, ECS, DynamoDB.

Оркестрация

 

• Логика рабочего процесса сосредоточена в одном месте — это упрощает отладку и мониторинг.
• Компромисс: появляется центральная точка зависимости.

Хореография

• Нет центрального контроллера.
• Сервисы реагируют на события самостоятельно.
• Каждый сервис отслеживает нужные события и выполняет свою работу.
• Ни один сервис не знает полного рабочего процесса.
• Улучшает слабую связанность и масштабируемость.

 

Хореография

• На AWS: EventBridge, SNS, SQS.
• Высокая масштабируемость.
• Компромисс: чем сложнее рабочий процесс, тем труднее его понять и отладить.

 

Событийно-ориентированная архитектура

• Сервисы взаимодействуют через производство и потребление событий.
• Обеспечивает слабую связанность между сервисами.
• Обеспечивает высокую масштабируемость.
• Позволяет обрабатывать события параллельно.
• Новые сервисы могут подписаться без изменения существующих.

 

Событийно-ориентированная архитектура

 

• Компромиссы при реализации EDA:
• Проектируйте с учётом итоговой согласованности.
• Реализуйте идемпотентность.
• Обработка сбоев становится сложнее.

Идемпотентность

 

• Одна и та же операция, выполненная несколько раз, даёт одинаковый результат.
• Ключевой принцип проектирования асинхронных и событийно-ориентированных систем.
• Распределённые системы могут доставлять дублирующиеся события (повторные попытки, сбои сети, повторная обработка).
• Обеспечивает корректность и надёжность системы.

Очереди недоставленных сообщений

 

• Управляет сбоями при асинхронном взаимодействии.
• Изолирует проблемные «отравленные» сообщения.
• После повторных неудачных попыток сообщение перемещается в DLQ.
• Основной поток обработки продолжает работу.

Очереди недоставленных сообщений

• Используйте, когда порядок сообщений не критичен.
• Не применяйте для некритичных систем, где допустима редкая потеря данных.
• Избегайте, когда порядок сообщений должен сохраняться.

 

Управление состоянием

• Управление состоянием — основа облачных приложений.
• Состояние — это любые данные, сохраняемые между взаимодействиями.
• Хранение состояния локально на сервере ограничивает масштабируемость и отказоустойчивость.

 

Управление состоянием

• Управление состоянием предполагает компромиссы в зависимости от задачи.
• Внешнее состояние повышает масштабируемость и отказоустойчивость.
• Издержки: увеличение задержки и сложности.
• Важно учитывать: согласованность, кэширование и паттерны доступа к данным.

 

Состоятельный подход

 

• Данные сессии хранятся на сервере.
• Запросы должны направляться к одному и тому же экземпляру (липкие сессии).
• Ограничивает гибкость масштабирования.
• При сбое экземпляра сессия теряется.

Подход без состояния

 

• Каждый запрос обрабатывается независимо.
• Состояние на сервере не хранится.
• Состояние находится во внешних системах.
• Предпочтительный подход для облачных приложений.
• Любой экземпляр может обработать любой запрос — горизонтальное масштабирование упрощается.

Давайте потренируемся!

Разработка приложений на AWS