Database per service

В микросервисной архитектуре паттерн “Database per Service” означает, что у каждого сервиса есть своя собственная, независимая база данных. Это позволяет полностью изолировать данные, что обеспечивает независимость и автономность каждого микросервиса. При таком подходе, на этапе выполнения, сервисы не блокируют друг друга, и ни одному из них не приходится ждать из-за конкуренции за доступ к общей базе данных.

Этот паттерн подразумевает, что каждый микросервис владеет своим хранилищем данных и несёт ответственность за его структуру и управление. Это не означает, что для каждого сервиса необходимо выделять отдельный сервер базы данных — вполне возможно использование одного физического сервера с несколькими логически изолированными базами данных или базой с разными схемами для разных сервисов.

Преимущества подхода:

1. Изоляция данных. Каждый сервис владеет своими данными, и другие сервисы не имеют прямого доступа к этим данным. Это повышает безопасность и уменьшает вероятность ошибок, вызванных некорректным использованием данных другими сервисами.
2. Независимость разработки и деплоя. Каждый микросервис может развиваться, тестироваться и развёртываться независимо, так как изменение структуры данных в одном сервисе не затрагивает другие.
3. Устранение конкуренции за ресурсы. Сервис не будет блокирован другим сервисом, который интенсивно использует общую базу данных. Это улучшает производительность и уменьшает задержки.
4. Масштабируемость. Каждый сервис может масштабироваться независимо, в том числе и его база данных. Это позволяет учитывать конкретные требования к нагрузке каждого сервиса.

Проблемы

• Невозможность глобальных транзакций (ACID). В случае, когда бизнес-логика требует согласованности данных на уровне нескольких микросервисов, использование ACID-транзакций на уровне всего приложения становится невозможным. Для решения этой проблемы применяются паттерны, такие как Saga, которые позволяют координировать распределённые транзакции через цепочку локальных операций.
• Избыточность данных и консистентность. Поскольку каждый микросервис владеет своими данными, иногда возникает необходимость дублирования данных между сервисами для обеспечения эффективной работы. Это может привести к проблемам с поддержанием консистентности данных и усложняет управление изменениями.
• Усложнение запросов. Если бизнес-логика требует данных из нескольких микросервисов, выполнение сложных запросов становится трудной задачей, поскольку прямое обращение к базе данных другого сервиса не разрешено. В таких случаях приходится использовать API или механизмы синхронизации данных, что усложняет архитектуру.

Лучшие практики

• Чёткие границы владения данными. Определите чёткие границы владения данными для каждого сервиса, - Ограниченный контекст. Это помогает избежать пересечений и зависимостей между сервисами, а также упрощает управление данными.
• Событийно-ориентированная архитектура. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны.
• Реализация паттернов для согласованности. Используйте паттерны, такие как Saga, чтобы координировать действия между несколькими микросервисами и гарантировать согласованность данных без использования глобальных транзакций.
• API вместо прямого доступа к данным. Доступ к данным одного микросервиса другими должен осуществляться только через публичные API. Это помогает соблюдать инкапсуляцию и обеспечивает безопасное взаимодействие между сервисами.

Мета информация

Область:: 00 Микросервисная архитектура
Родитель::
Источник::
Создана:: 2024-11-24
Автор::

Дополнительные материалы

• Shared Database

Дочерние заметки