Ответ
В микросервисной архитектуре используются устоявшиеся паттерны для решения общих проблем, таких как маршрутизация, отказоустойчивость и управление данными.
API Gateway
- Проблема: Как клиентам обращаться к множеству сервисов, не зная их адресов и не усложняя клиентский код?
- Решение: Единая точка входа, которая маршрутизирует запросы к нужным сервисам. Также может выполнять аутентификацию, авторизацию, SSL-терминацию, кэширование и агрегацию ответов.
Service Discovery (Обнаружение сервисов)
- Проблема: В динамической среде (контейнеры, VM) адреса сервисов постоянно меняются. Как сервисам находить друг друга?
- Решение: Центральный реестр сервисов (например, Consul, Eureka или встроенный механизм Kubernetes), где сервисы регистрируются при старте и куда другие обращаются за их актуальными адресами.
Circuit Breaker (Автоматический выключатель)
- Проблема: Один неработающий сервис может вызвать каскадный сбой всей системы из-за долгих таймаутов и исчерпания ресурсов.
- Решение: Паттерн, который отслеживает сбои при вызове сервиса. После определенного порога ошибок «выключатель» размыкается, и последующие вызовы немедленно завершаются ошибкой, не нагружая неисправный сервис. Пример в Go —
github.com/sony/gobreaker.
Saga
- Проблема: Как обеспечить консистентность данных между сервисами без использования распределенных транзакций (которые сложны и плохо масштабируются)?
- Решение: Управление транзакцией через последовательность локальных транзакций в каждом сервисе. При сбое одного из шагов запускаются компенсирующие транзакции для отката изменений. Бывает двух видов: Choreography (сервисы общаются через события) и Orchestration (центральный сервис-оркестратор управляет процессом).
CQRS (Command Query Responsibility Segregation)
- Проблема: Модель данных, удобная для записи, часто неэффективна для чтения, и наоборот.
- Решение: Разделение операций на команды (изменяющие состояние) и запросы (читающие состояние). Это позволяет использовать разные модели данных и даже разные базы данных для записи и чтения, оптимизируя каждую операцию независимо.
Event Sourcing (Событийная модель)
- Проблема: Как сохранить полную историю изменений состояния системы?
- Решение: Вместо хранения текущего состояния, система хранит полную последовательность событий, которые привели к этому состоянию. Текущее состояние можно восстановить, проиграв все события. Часто используется вместе с CQRS.