Как добавить отношения «многие-ко-многим» между таблицами из разных баз данных?

Question

[Elnurhan]

Пишу пет-проект интернет-магазин на голанг. Разбил монолитную архитектуру на микросервисную и для каждого микросервиса использую отдельную БД postgres.
У меня есть два микросервиса: микросервис продуктов и микросервис категорий
Таблицы для них выглядят так:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

create table if not exists products
(
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    name TEXT NOT NULL,
    description TEXT NOT NULL,
    price NUMERIC NOT NULL,
    created_at TIMESTAMP NOT NULL DEFAULT now(),
    updated_at TIMESTAMP
);
create table categories
(
    id serial primary key,
    name text not null,
    slug text not null,
    created_at timestamp not null default now(),
    updated_at timestamp
);

Как я могу добавить поле категория в таблицу продукта, если они находятся в разных базах данных? Есть ли такая возможность, либо эти таблицы должны быть в одной базе данных?

Comments

[Everything_is_bad]

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

Answer 1

[nApoBo3]

Первое. Обеспечение целостности данных в микросервисной архитектуре по большей части переходит в слой приложения. И это одна из самых сложных задач во всем микросервисном подходе. Так или иначе приходится реализовывать какой-то механизм, обычно приходят к подходу eventual consistency, когда в каждый момент времени какая-то часть данных может быть не согласована, но в итоге все данные будут приведены к согласованному виду.
Второе, где проводить границу между сервисами.

В данном конкретном случае, таблица категорий продуктов может быть как частью сервиса продуктов, так и внешней сущностью по отношению к нем. Если таблица категорий является внешней сущностью, то самому сервису продуктов должно быть абсолютно без разницы что содержится в этом поле, он внутри себя сохраняет функциональность и целостность своих данных даже если записать в это поле произвольный набор.
Обеспечение не противоречивости данных в этом случае может быть реализовано множеством способов. Как один из самых простых, падение и мониторинг в том месте где эти данные будут агрегироваться.

Answer 2

[ky0]

для каждого микросервиса использую отдельную БД postgres

Напрасно, это в вашем случае не добавляет "микросервисности".

Comments

[Elnurhan]

Почему?
Прочитав различные статьи на эту тему, пришёл к выводу, что это неплохое решение. Как для дальнейшего масштабирования, так и для отказаустойчивости.

[ky0]

Elnurhan, если у вас между базами данных есть связи на уровне логики - значит, ни о какой отказоустойчивости речи не идёт. Выходит из строя одна СУБД - перестаёт работать несколько сервисов.

Масштабирование Постгреса начинается с других способов, разнесение данных по разным базам - ближе к концу списка.

[Сергей Горностаев]

ky0, связи между базами обычное дело. Большая, часть книг про микросервисы и DDD про эти связи.

[nApoBo3]

ky0, где вы здесь обнаружили связь на уровне логики? категория может быть волне себе справочным полем.
Вопрос в том где провести границу сервиса, но из контекста вопроса это не понято, таблица с категориями может быть как часть микросервиса продуктов, так и внешней сущностью, это зависит от множества факторов.

Answer 3

[Виктор Кожухарь]

Если вы разделяете проект на микросервисы, но связываете при этом их данные, то вы просто делаете распределённый монолит. А когда вы ещё и базу разрываете на два куска, при этом пытаясь сохранить между ними традиционные связи, как внутри одной базы данных, то вы:
1. Не решаете абсолютно ни одной из задач микросервисов, т к. сервисы остаются жёстко связанными. Всё можно было бы решить просто при помощи "Clean architecture", DDD и т.д.
2. Вы добавляете себе невероятное количество головной боли, связанной с самой микросервисной архитектурой, но и плюс все прелести из п.1.
3. И тогда нафига козе баян?

- Микросервисы должны иметь полностью независимые базы данных
- Все взаимодействия должны осуществляться исключительно по API (это мой ответ на ваш вопрос). Как только вы связываете схемы данных, вы теряете весь смысл микросервисов.
- Вы должны обязательно реализовать распределенные транзакции. Вы должны сами писать код для таких транзакций. А вспомните, как приятно и просто делать транзакции в монолите с одной базой данных.
- Взаимодействие между микросервисами должно осуществляться на базе строжайших контрактов, которые можно менять только после обсуждения со всеми людьми, разрабатывающими данные микросервисы. Вам неплохо было бы выдумать или позаимствовать какой-то фреймворк, где четко будут описаны общие и частные принципы общения микросервисов.
- Вы должны обеспечить мониторинг всего и вся, оповещение об отказах и деградации микросервисов
- Вы должны обеспечить распределенное логирование, чтобы уметь отслеживать даже, например, простые запросы между логами из нескольких независимых систем.
- И т.д. и т.п.

Оно вам надо?

Answer 4

[rPman]

Если это сделано специально то не надо так делать.

Одновременная работа с двумя базами данных лишает пользователя встроенного механизма транзакций и заставляет самому следить за согласованностью данных.

Если прямо очень надо, то для начала нужно понять, какая сторона будет 'главной', кто будет выдавать идентификаторы и следить за их согласованностью. Если главного выбрать не получается, то идентификаторы можно создавать двумя способами:
- генерация GUID, который специально разработан быть статистически уникальным, на чьей бы стороне он не был создан (128бит)
- добавление в идентификатор объекта идентификатора ноды, алгоритмы бывают разные, самый простой, определить максимальное количество нод и выделить в идентификаторе несколько бит для их номера (например максимальное количество нод 256, это 8бит в идентификаторе, пусть будут младшие)