System Design
Микросервисы
Цели урока
- Понять когда нужны микросервисы, а когда достаточно монолита
- Освоить принципы декомпозиции: bounded contexts, data ownership
- Различать sync и async коммуникацию между сервисами
- Применять Saga pattern для distributed transactions
- Использовать resilience patterns: Circuit Breaker, Retry, Timeout
Предварительные знания
- Message Queue и паттерны async коммуникации
- Понимание REST API и основ distributed систем
Монолит vs Микросервисы
**Микросервисы** - архитектурный стиль, где приложение состоит из небольших автономных сервисов, каждый со своей БД, деплоящихся независимо.
**Монолит - не ругательство**. Микросервисы решают проблемы масштабирования команд. Для 5 разработчиков и 1000 пользователей - монолит отлично подойдёт.
| Критерий | Монолит | Микросервисы |
|---|---|---|
| Деплой | Один артефакт | Независимо каждый сервис |
| Scaling | Весь монолит | Отдельные компоненты |
| Отладка | Один процесс | Distributed tracing |
| Транзакции | ACID через БД | Saga, eventual consistency |
| Команда | Все в одном коде | Команда = сервис |
| Failure isolation | Один баг роняет всё | Изолированные сбои |
**Правило**: начинайте с монолита, выделяйте сервисы когда появляется боль. Premature decomposition хуже монолита.
У стартапа 8 разработчиков, 5000 пользователей, неясная бизнес-модель. Какую архитектуру выбрать?
Принципы декомпозиции
Границы сервисов - ключевое архитектурное решение. Неправильная декомпозиция создаёт distributed monolith - худший из миров.
**Размер сервиса**: "можно переписать за 2 недели" - хороший heuristic. Слишком мелкие = overhead, слишком большие = мини-монолиты.
Пример декомпозиции e-commerce:
**Анти-паттерн: Distributed Monolith**. Если сервисы деплоятся вместе, тестируются вместе, падают вместе - это не микросервисы, а распределённая боль.
В e-commerce какой сервис должен владеть информацией о цене товара?
Паттерны коммуникации
Выбор между синхронной и асинхронной коммуникацией - ключевое решение для каждого взаимодействия.
| Паттерн | Когда использовать | Пример |
|---|---|---|
| Sync REST/gRPC | Нужен ответ немедленно | Проверка авторизации |
| Async Messaging | Fire-and-forget | order.created → email |
| Request-Reply | Async, но нужен ответ | Long-running tasks |
| Event Sourcing | Audit trail, replay | Финансовые транзакции |
**Правило**: Sync для queries (нужен ответ), Async для commands (изменяющие действия). CQRS помогает разделить.
OrderService должен отправить email покупателю после заказа. Какой тип коммуникации выбрать?
Saga Pattern
**Saga** - паттерн для distributed transactions. Последовательность локальных транзакций с компенсирующими действиями для отката.
В микросервисах нет 2PC (two-phase commit). Каждый сервис имеет свою БД. Saga - альтернатива для consistency.
Два стиля реализации Saga: **Choreography** (децентрализованный) и **Orchestration** (централизованный).
**Выбор**: Choreography для простых flows (2-3 шага). Orchestration для сложных бизнес-процессов с ветвлениями.
В Saga для бронирования отеля: Hotel Service сначала забронировал, потом Flight Service упал. Что делать?
Resilience Patterns
В distributed системах сбои неизбежны. Resilience patterns защищают от cascade failures.
**Правило трёх**: Timeout + Retry + Circuit Breaker - минимальный набор для каждого внешнего вызова.
Service A вызывает Service B. B отвечает за 10 секунд вместо 100ms. Что произойдёт без timeout?
Database per Service
**Database per Service** - золотое правило микросервисов. Каждый сервис владеет своими данными. Никакого shared database!
Как получить данные другого сервиса? Три подхода:
**Data duplication OK**! В микросервисах денормализация ради независимости - нормальная практика. Eventual consistency - принятый компромисс.
Order Service должен показать имя пользователя в заказе. Как получить данные?
Ключевые принципы микросервисов
- **Монолит first** - микросервисы когда команда > 50 или нужен независимый scaling
- **Bounded contexts** - каждый сервис = один бизнес-домен
- **Database per service** - никакого shared database!
- **Saga** для distributed transactions (не 2PC)
- **Circuit Breaker + Retry + Timeout** - обязательная тройка для resilience
- **Async > Sync** для non-critical paths (notifications, analytics)
Связанные темы
Микросервисы требуют развитой инфраструктуры
- API Gateway — Единая точка входа для клиентов, routing, auth
- Service Mesh — Networking, observability, mTLS между сервисами
- Message Queue — Async communication между сервисами