--- aliases: - separate data store - своя база данных tags: - maturity/🌱 date: 2024-11-24 --- В [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисной архитектуре]] [[Паттерн проектирования|паттерн]] "Database per Service" означает, что у каждого сервиса есть своя собственная, независимая [[../../meta/zero/00 Реляционная база данных|база данных]]. Это позволяет полностью изолировать данные, что обеспечивает независимость и автономность каждого микросервиса. При таком подходе, на этапе выполнения, сервисы не блокируют друг друга, и ни одному из них не приходится ждать из-за конкуренции за доступ к общей базе данных. Этот паттерн подразумевает, что каждый [[микросервис]] владеет своим хранилищем данных и несёт ответственность за его структуру и управление. ==Это не означает, что для каждого сервиса необходимо выделять отдельный сервер базы данных — вполне возможно использование одного физического сервера с несколькими логически изолированными базами данных== или базой с разными схемами для разных сервисов. **Преимущества подхода:** 1. **Изоляция данных**. Каждый сервис владеет своими данными, и другие сервисы не имеют прямого доступа к этим данным. Это повышает безопасность и уменьшает вероятность ошибок, вызванных некорректным использованием данных другими сервисами. 2. **Независимость разработки и деплоя**. Каждый микросервис может развиваться, тестироваться и развёртываться независимо, так как изменение структуры данных в одном сервисе не затрагивает другие. 3. **Устранение конкуренции за ресурсы**. Сервис не будет блокирован другим сервисом, который интенсивно использует общую базу данных. Это улучшает производительность и уменьшает задержки. 4. **Масштабируемость**. Каждый сервис может масштабироваться независимо, в том числе и его база данных. Это позволяет учитывать конкретные требования к нагрузке каждого сервиса. Проблемы - **Невозможность глобальных транзакций (ACID)**. В случае, когда бизнес-логика требует согласованности данных на уровне нескольких микросервисов, использование ACID-транзакций на уровне всего приложения становится невозможным. Для решения этой проблемы применяются паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), которые позволяют координировать распределённые транзакции через цепочку локальных операций. - [[Избыточность данных|Избыточность данных]] и консистентность. Поскольку каждый микросервис владеет своими данными, иногда возникает необходимость дублирования данных между сервисами для обеспечения эффективной работы. Это может привести к проблемам с поддержанием консистентности данных и усложняет управление изменениями. - **Усложнение запросов**. Если бизнес-логика требует данных из нескольких микросервисов, выполнение сложных запросов становится трудной задачей, поскольку прямое обращение к базе данных другого сервиса не разрешено. В таких случаях приходится использовать API или механизмы синхронизации данных, что усложняет архитектуру. Лучшие практики - **Чёткие границы владения данными**. Определите чёткие границы владения данными для каждого сервиса, - [[Bounded Context|Ограниченный контекст]]. Это помогает избежать пересечений и зависимостей между сервисами, а также упрощает управление данными. - [[Событийно-ориентированная архитектура|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны. - **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать согласованность данных без использования глобальных транзакций. - **API вместо прямого доступа к данным**. Доступ к данным одного микросервиса другими должен осуществляться только через публичные API. Это помогает соблюдать [[Инкапсуляция|инкапсуляцию]] и обеспечивает безопасное взаимодействие между сервисами. *** ## Мета информация **Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]] **Родитель**:: **Источник**:: **Создана**:: [[2024-11-24]] **Автор**:: ### Дополнительные материалы - [[Shared Database|Shared Database]] ### Дочерние заметки