Микросервисная архитектура и дизайн базы данных

Question

Я разрабатываю архитектуру микросервисов для решения, которое будет охватывать несколько модулей, которые могут работать отдельно или могут быть подключаемыми в соответствии с приобретением. Моя проблема определения архитектурных / инфра-данных заключается в следующем: просто в качестве примера (не реального решения) давайте рассмотрим его как полное решение для управления резервированием со следующими модулями:

Модуль бронирования отелей

Модуль бронирования развлечений (различные мероприятия: театр, музыкальные шоу и т. Д.)

Модуль бронирования автомобиля

Модуль продажи авиабилетов

Каждый модуль будет иметь свой собственный домен: интеграции, правила и базу данных вашего домена. Проблема, которую я пытаюсь решить в этом моделировании обслуживания / хранения, состоит в том, как разделить общие части в служебной шине и повторно использовать ее для всех модулей. но без создания единой модели данных, например: во всех этих модулях у меня будет пользовательская база (будут другие общие точки), какой лучший подход к созданию уникального, но независимого пользовательского хранилища данных для моделей каждого сервисного модуля?

Я думал о следующих опциях:

1 - иметь служебную шину для управления пользователями в общей базе данных, и каждый модуль будет иметь ссылку на FK пользователя в их схеме непосредственно из базы данных. Используя этот подход https://www.akadia.com/services/ora_references_constraint.html Но каково, например, выполнение JOIN между схемами? Может ли это сделать невозможным?

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

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

Первый вариант кажется лучше, но мне не совсем удобно думать о современной архитектуре.

Что вы предлагаете об этой архитектуре, решение NoSQL будет более подходящим?

Любые чаевые приветствуются.

Answer 1

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

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

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