использовать схему mon goose для нескольких микросервисов - PullRequest
Новая
       7

использовать схему mon goose для нескольких микросервисов

3 голосов
/ 06 апреля 2020

мое приложение разделено на несколько микросервисов , которые работают на heroku dynos (они не могут получить доступ к файлам друг друга). Иногда существует несколько микросервисов, работающих с одной коллекцией. Следовательно, оба микросервиса нуждаются в соответствующей схеме mon goose.

Однако не обоим микросервисам нужна схема full . Например, микросервису A нужна полная схема, тогда как микросервису B нужны только несколько полей этой схемы.

Пример схемы внутри микросервиса A: 

var AccountSchema = mongoose.Schema({
    email: { type: String, required: true, unique: true },
    password: { type: String, required: true },
    phone: { type: String, required: true, unique: true },
    forename: { type: String, required: true },
    surname: { type: String, required: true },
    middleInitals: { type: String, required: false },
    failedLoginAttempts: { type: Number, required: true, default: 0 },
    lockUntil: { type: Number },
    createdAt: { type: Date, default: Date.now }
})

Пример схемы внутри микросервиса B: 

var AccountSchema = mongoose.Schema({
    email: { type: String, required: true, unique: true },
    password: { type: String, required: true },
    failedLoginAttempts: { type: Number, required: true, default: 0 },
    lockUntil: { type: Number },
    createdAt: { type: Date, default: Date.now }
})

Мой подход

Я бы просто на go вперед и создал бы новую схему в каждом микросервисе, содержащую только необходимые поля. Однако я не уверен, будут ли какие-либо проблемы, когда несколько микросервисов зарегистрируют новую схему в базе данных MongoDB? Например, оба микросервиса будут пытаться создать индекс для поля unique. Будут ли проблемы с производительностью?

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

Заранее спасибо:)

Ответы [ 2 ]

1 голос
/ 17 апреля 2020

Это правильный подход. Вы можете иметь 2 схемы, указывающие на одну и ту же коллекцию. Я проверил его, и он работает.

Пн goose - библиотека объектного моделирования данных (ODM) , и вы можете иметь 2 объекта, смотрящих на одну коллекцию / (таблица или представление) в SQL) - с этим проблем нет.

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

Возможно, вы захотите добавить ключ типа, поэтому вы можете найти только учетные записи type1 / type2 по запросу get. При поиске вы можете ограничить получение правильных полей проекцией.

Я думаю, у вас должно быть только 2 ключа в индексе - электронная почта + пароль. Если у вас есть телефонный указатель и микросервис B: не включайте телефон - у вас будет нарушение по уникальному указателю телефона .

Но если вам действительно нужен уникальный индекс телефона, вы можете сделать переопределение. Вы можете сгенерировать временное уникальное значение для телефона для mircoservice B (используя автогенерацию или дублировать значение электронной почты), вы проигнорируете это значение на mircoservice B и найдете / обновите / представите телефон только в микросервисе A, где у вас есть действующий телефон. Когда пользователь меняет тип учетной записи B на тип учетной записи A - необходимо обязательно заменить неправильный номер телефона действительным.

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

0 голосов
/ 11 апреля 2020

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

...