6.4 KiB
| aliases | tags | date | ||
|---|---|---|---|---|
|
|
2024-11-24 |
Подход "Shared Database" предполагает, что все микросервисы используют одну общую базу данных для хранения данных. Сервисы взаимодействуют напрямую с таблицами, которые принадлежат другим сервисам, что создает зависимости на уровне данных и разрушает Инкапсуляция между микросервисами.
Наличие одной базы данных для всех сервисов увеличивает Связность системы и создаёт Bottlneck.
В ../../../../wiki/zero/00 Микросервисная архитектура подход, при котором все сервисы общаются с одной общей базой данных, считается скорее анти-паттерном. Несмотря на то, что в некоторых случаях это может показаться более простым решением, такой подход ведет к серьёзным ограничениям и проблемам, особенно в масштабируемых системах. Использование общей базы данных приводит к проблемам с разделением ответственности и нарушает принципы слабой Связанность и высокой Связность, которые являются основными в микросервисной архитектуре.
Проблемы подхода Shared Database
- Сильная связанность между сервисами. Общая база данных приводит к явным и неявным зависимостям между сервисами. Это может проявляться через использование триггеров или процедур, которые затрагивают данные разных сервисов. Например, один сервис может использовать процедуру, изменяющую данные, которые принадлежат другому сервису. Такие зависимости делают каждый сервис уязвимым к изменениям в других сервисах.
- Отсутствие независимости. Микросервисы должны быть автономными, чтобы их можно было разрабатывать, тестировать и развёртывать независимо друг от друга. Использование общей базы данных приводит к необходимости координации изменений между разными сервисами, что нарушает эту независимость и замедляет процесс разработки.
- Проблемы с масштабируемостью. Когда все сервисы используют одну базу данных, её сложно масштабировать. Один сервис может использовать значительное количество ресурсов, создавая нагрузку на базу данных и замедляя работу остальных сервисов. Это делает независимое масштабирование отдельных компонентов практически невозможным.
- Трудности с тестированием. Тестирование сервисов в изолированном окружении становится гораздо сложнее, так как все они зависят от одной базы данных. Чтобы протестировать один сервис, нужно воссоздать всю структуру данных, что может потребовать значительных усилий.
Лучшие практики для избежания Shared Database
- Database per Service. Каждый микросервис должен владеть своей собственной базой данных. Это позволяет сохранять автономность сервисов и исключает возможность прямого доступа к данным другого сервиса.
- Событийная синхронизация. Если данные одного сервиса нужны другому, лучше использовать ../../../../_inbox/Событийно-ориентированное программирование. Сервис, владеющий данными, может отправлять события, на которые подписываются другие сервисы, что помогает синхронизировать информацию без необходимости прямого доступа к общей базе данных.
- Использование API для доступа к данным. Вместо того чтобы обращаться к базе данных другого сервиса напрямую, следует использовать публичные API. Это позволяет соблюсти инкапсуляцию данных и уменьшить связанность между сервисами.
Мета информация
Область:: ../../../../wiki/zero/00 Микросервисная архитектура Родитель:: Источник:: Создана:: 2024-11-24 Автор::