Ответ
Ключевой принцип — одна база данных на сервис (Database per Service). Каждый микросервис владеет своими данными и имеет эксклюзивный доступ к своей базе данных.
Это делается для обеспечения слабой связанности (loose coupling) между сервисами. Ни один сервис не может напрямую обращаться к базе данных другого сервиса; взаимодействие происходит только через опубликованные API.
Преимущества такого подхода:
- Автономность: Команды могут изменять схему БД, обновлять и масштабировать её, не затрагивая другие сервисы.
- Полиглотная персистентность (Polyglot Persistence): Возможность выбрать лучшую технологию хранения для каждого сервиса. Например:
- Сервис заказов — реляционная СУБД (PostgreSQL) для ACID-транзакций.
- Сервис каталога товаров — документо-ориентированная СУБД (MongoDB) для гибкой структуры.
- Сервис рекомендаций — графовая СУБД (Neo4j).
- Изоляция сбоев: Проблемы с базой данных одного сервиса не влияют напрямую на работоспособность других.
Основные вызовы и их решения:
-
Согласованность данных (Data Consistency)
- Проблема: Атомарные транзакции (ACID) не могут охватывать несколько баз данных.
- Решение: Паттерн Saga. Бизнес-транзакция разбивается на серию локальных транзакций в каждом сервисе. Для координации используются брокеры сообщений (Kafka, RabbitMQ), что приводит к конечной согласованности (eventual consistency).
-
Запросы к данным из нескольких сервисов
- Проблема: Как получить данные, которые хранятся в базах данных разных сервисов (например, собрать информацию о заказе и пользователе)?
- Решение: Паттерн API Composition. Создается сервис-агрегатор, который опрашивает другие сервисы по их API и объединяет результаты.