41 lines
7.6 KiB
Markdown
41 lines
7.6 KiB
Markdown
|
---
|
|||
|
|
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|Ограниченный контекст]]. Это помогает избежать пересечений и зависимостей между сервисами, а также упрощает управление данными.
|
|||
|
|
- [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны.
|
|||
|
|
- **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать согласованность данных без использования глобальных транзакций.
|
|||
|
|
- **API вместо прямого доступа к данным**. Доступ к данным одного микросервиса другими должен осуществляться только через публичные API. Это помогает соблюдать [[Инкапсуляция|инкапсуляцию]] и обеспечивает безопасное взаимодействие между сервисами.
|
|||
|
|
***
|
|||
|
|
## Мета информация
|
|||
|
|
**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
|
|||
|
|
**Родитель**::
|
|||
|
|
**Источник**::
|
|||
|
|
**Создана**:: [[2024-11-24]]
|
|||
|
|
**Автор**::
|
|||
|
|
### Дополнительные материалы
|
|||
|
|
- [[Shared Database|Shared Database]]
|
|||
|
|
|
|||
|
|
### Дочерние заметки
|
|||
|
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
|||
|
|
|