Ответ
Противоположный подход — Shared Database (Общая база данных), когда несколько микросервисов работают с одной и той же базой данных.
| Сравнение подходов: | Критерий | Database per Service | Shared Database |
|---|---|---|---|
| Связанность | Низкая (сервисы независимы) | Высокая (изменение схемы БД затрагивает многие сервисы) | |
| Согласованность | Сложная (требует саг или событий) | Простая (ACID-транзакции) | |
| Масштабирование | Горизонтальное (по сервисам) | Ограниченное (масштабирование самой БД) |
Проблемы Shared Database:
- Хрупкость: Изменение схемы таблицы может сломать несколько сервисов.
- Блокировки: Высокая конкуренция за ресурсы БД от разных сервисов.
- Нарушение инкапсуляции: Сервисы знают внутреннюю структуру данных друг друга.
Современные альтернативы для решения проблем распределенных данных:
- Паттерн Saga: Оркестрация или хореография длинных транзакций через события.
- CQRS (Command Query Responsibility Segregation): Разделение моделей для записи (команды) и чтения (запросы).
- Event Sourcing: Хранение состояния как последовательности событий.
Ответ 18+ 🔞
А, слушай, смотри, тут два подхода, как эти ваши микросервисы с данными общаются. Первый — модный, «каждому сервису по своей базе». Второй — старый, как говно мамонта, «общая база на всех».
Ну, Shared Database, блядь, это когда все твои сервисы, как голодные псы на одной миске, лезут в одну и ту же базу данных. Кажется, что просто и удобно, ага, щас.
Так, а в чём разница-то, спросишь? Да вот, смотри таблицу, она не для красоты:
| Критерий | Каждому сервису своя база (Database per Service) | Общая помойка (Shared Database) |
|---|---|---|
| Связанность | Низкая, сервисы друг про друга нихуя не знают | Высокая, как в коммуналке: чихнул один — все заболели |
| Согласованность | Сложная, пиздец, надо саги или события городить | Простая, классические ACID-транзакции, и все довольны |
| Масштабирование | Горизонтальное, каждый сервис масштабируй как хочешь | Ограниченное, всю эту махину-базу потом раскачивай |
А теперь, блядь, почему общая база — это пиздец и боль:
- Хрупкость, ёпта! Захотел ты в таблице
usersколонкуmiddle_nameпереименовать вpatronymic. А там, сука, пять сервисов на неё завязаны. И все они разом ложатся, как подкошенные. Один фикс — и пять деплоев, волнение ебать! - Блокировки. Представь, сервис заказов долбит по
inventory, а сервис аналитики в это же время агрегации там строит. И всё это начинает друг другу мешать, как мухи в банке. Производительность падает ниже плинтуса. - Нарушение инкапсуляции. Это вообще, в рот меня чих-пых! Получается, что сервис «Отзывы» лезет прямо в таблицы сервиса «Каталог». Он там всё про товары знает! А должен бы через API, как культурный человек. Так нет же, проще же схему посмотреть и JOIN натянуть. Кошмар, а не архитектура.
Ну и что делать-то, если не общая база? — спросит пытливый ум. А вот, блядь, современные альтернативы, чтобы не быть говнарем:
- Паттерн Saga. Это когда у тебя нет одной транзакции, а есть цепочка событий. Сделал шаг — опубликовал событие, следующий сервис его подхватил. Если где-то пиздец, запускаются компенсирующие события, чтобы откатить всё назад. Сложно? Зато честно.
- CQRS (Command Query Responsibility Segregation). Гениальная, блядь, идея. Ты для записи (команд) используешь одну модель, а для чтения (запросов) — другую, оптимизированную под конкретные вьюхи. Запись идёт в одно место, а данные для чтения кешируются или материализуются отдельно. И никто никому не мешает.
- Event Sourcing. Вообще, ебать, мощная штука. Ты вообще не хранишь текущее состояние. Ты хранишь лог всех событий, которые с объектом произошли («Заказ создан», «Товар добавлен», «Оплата прошла»). Чтобы получить текущее состояние, нужно проиграть все события по порядку. Звучит как мазохизм, но зато даёт овердохуища возможностей для аудита и восстановления.
Короче, общая база — это как жить с тёщей в одной комнате. Какое-то время терпимо, но рано или поздно кто-то кого-то прирежет. Думай головой, э бошка!