Должна ли каждая микросервисная система иметь отдельную базу данных для каждого сервиса?

Принцип "один сервис — одна база данных" является краеугольным камнем микросервисной архитектуры. Его основная цель — обеспечить слабую связанность (loose coupling) между сервисами. Когда сервис владеет своими данными и только он имеет к ним прямой доступ через свой API, это предотвращает создание скрытых зависимостей, которые усложняют независимые развёртывания и изменения.

Преимущества отдельной базы данных на сервис

• Независимость технологий: Команда, отвечающая за сервис заказов, может использовать PostgreSQL, в то время как команда сервиса рекомендаций — MongoDB.
• Масштабируемость: Базу данных можно масштабировать отдельно от других сервисов в соответствии с её нагрузкой.
• Устойчивость к сбоям: Проблема в одной БД (например, исчерпание соединений) не должна напрямую влиять на доступность других сервисов.
• Чёткие границы контекста: Этот принцип хорошо согласуется с Domain-Driven Design (DDD), где каждый ограниченный контекст (сервис) управляет своей собственной моделью данных.

Практические сложности и компромиссы

Строгое соблюдение правила может быть непрактичным. Например, выполнение транзакций, затрагивающих несколько сервисов, требует реализации шаблонов Saga или компенсирующих транзакций, что значительно сложнее, чем использование ACID-транзакций в монолитной БД. Кроме того, дублирование данных (например, копия имени пользователя в сервисе заказов) необходимо для автономности, но создаёт проблемы синхронизации.

Пример кода и подхода

Рассмотрим простой сценарий, где сервис заказов (Orders) и сервис пользователей (Users) разделены. Сервис заказов не может выполнить JOIN с таблицей пользователей. Вместо этого он хранит копию необходимых данных (например, userId, userName) и обновляет их асинхронно через события.

// Сервис Users публикует событие при изменении имени пользователя
eventBus.publish('user.updated', {
  userId: '123',
  newName: 'Alice Smith'
});

// Сервис Orders подписывается на это событие и обновляет свою локальную копию
eventBus.subscribe('user.updated', (event) => {
  Order.updateMany(
    { 'user.id': event.userId },
    { $set: { 'user.name': event.newName } }
  );
  // Примечание: это в конечном счёте согласованная операция
});

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

Вывод: Принцип "один сервис — одна БД" следует рассматривать как руководство к достижению независимости, а не как абсолютный догмат. Его стоит применять для ключевых бизнес-сервисов, где важны автономность и масштабируемость. Для вспомогательных или тесно связанных сервисов общая база данных может быть допустимым компромиссом, снижающим операционную сложность.