Обеспечение согласованности для иностранных ключей / владельцев микросервисов - PullRequest
Новая
       24

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

0 голосов
/ 11 июня 2018

У меня есть два ограниченных контекста, которые ведут к двум микро-сервисам

  • PersonalManagement
  • DocumentStorage

Я сохраняю здесь простую модель сущностей.

PersonalManagement: 

Entity/Table Person:
@id - int
tenantId - int
name - string
...

DocumentStorage 

Entity/Table Document:
@id - int
tenantId - int
personId - int
dateIssued - string
...

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

Я хочу сохранить новый документ с помощью REST / JSON.

Это POST для / арендаторов / 1 / персон / 5 / документов 

with the body
{
    "dateIssued" : "2018-06-11"
}

Навнутренняя сторона - я проверяю тело ввода.

Одной из проверок может быть «если указанный человек существует и действительно принадлежит данному арендатору».

Поскольку эта информация хранится в PersonalManagement-MicroService,Мне нужно предоставить операцию, подобную этой: 

"Does exists (personId=5,tenantId=1)"

в PersonalManagement, чтобы обеспечить согласованность, так как вызывающий абонент может быть злым.

Или вообще:

Что лучше всего делатьпроверить "право собственности" на объекты крбаза данных oss в микро сервисах

Возможно также, что при создании нового человека (tenantId, personId) эта информация дополнительно (!) сохраняется в DocumentStorage, но вы хотите избежать этой избыточности.

Ответы [ 2 ]

0 голосов
/ 11 июня 2018

только для проверки аренды, это можно сделать с помощью токена JWT (токена, который может хранить информацию об арендаторе и другие метаданные).

Позвольте мне привести еще один пример того же сценария, который не может быть решенс JWT.

Предположим, что один Заказчик хочет создать Заказ, а наша система хочет проверить, существует ли клиент при создании заказа.

Поскольку Заказ и Служба поддержки клиентов отделены друг от друга, и мыхочу минимальных зависимостей между ними, есть несколько sol.Для решения вышеуказанных проблем:

  • создайте Заказ в «состоянии проверки» и при проверке события OrderCreated на действительность клиента и обновите состояние клиента до «Действительный»
  • еще до создания проверки заказа дляклиент (это не правильный путь, поскольку он создает зависимость, пока и если это не критично, не делайте этого)
  • последний способ - это создание заказа, тот, кто окончательно проверит заказ на доставку, проверитклиент удалит
0 голосов
/ 11 июня 2018

Я не собираюсь расширять этот ответ, чтобы определить, правильно ли определены ваши ограниченные контексты и конечные точки службы, поскольку ваш вопрос, кажется, упрощает проблему, чтобы сохранить четко определенную область, но относительно вашего конкретного вопроса:

Какова наилучшая практика для проверки "владения" сущностями, находящимися в нескольких базах данных в микро-сервисах

В микросервисных архитектурах используется принцип "ничего не делить".И это обычно распространяется от кодовой базы к базе данных.Таким образом, вы правы, предполагая, что вы проверяете это ограничение «кросс-БД» в своем сценарии.

У вас есть несколько вариантов в этом конкретном случае, каждый со своим набором недостатков:

1) Ваш предложенный «существует» (personId = 5, tenantId = 1) » вызов от DocumentContext к PersonContext не является ошибочным сам по себе,но вы создадите прямую зависимость между этими двумя микросервисами, поэтому вы должны спросить себя, нормально ли вам не принимать новые документы, если микросервис PersonManagement находится в автономном режиме.

В определенных ситуациях такие зависимости могут быть приемлемыми, но чем больше их у вас есть, тем меньше ваша микросервисная архитектура будет вести себя как один и более как «распределенный монолит», который сам по себе является антипаттерном.

2) Другой основной вариант, который у вас есть, заключается в том, что вы должны понимать, что DocumentContext очень сильно интересует некоторая информация / поведение, относящиеся к People , поэтомудолжно быть в порядке с моделированием Person Entity внутри его границ.

Это означает, что вы можете подписать DocumentContext на изменения в PersonContext , чтобы знать, какие Люди существуют в настоящее время и каковы их характеристикии, следовательно, иметь возможность хранить локальную копию такой информации.

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

Но в конце вы также обнаружите, что "не делится ничем" *Принцип 1046 * обычно обходится вам в том, что кажется избыточностью, но на самом деле это независимость от контекста.

...