Использовать базу данных пользователей в нескольких проектах / серверах?

Question

У меня есть проект и какой-то подпроект. Теперь я хочу, чтобы подпроект использовал те же данные пользователя для входа в систему, что и основной проект. По сути, я хочу использовать таблицу пользователей основного проекта (и, возможно, вторую таблицу, которая также относится к пользователям). Однако это не односторонний путь, я хочу, чтобы пользователи также могли создавать учетные записи в подпроекте, которые также действительны для основного проекта.

Подвох: проекты используют разные выделенные серверы для своих баз данных SQL. (Оба MariaDB, хотя, в версии 10 или 10.1)

Я рассмотрел следующие варианты:

1) Я мог бы просто открыть 2 экземпляра mysql в подпроекте, один для доступа к данным подпроектов и один для доступа к данным пользователя из основного проекта. Это связано с большим недостатком: а) у меня открыто 2 соединения, что, вероятно, также приводит к снижению производительности, и б) я вообще не могу использовать JOIN-соединения в таблице пользователей.

2) Я слышал о механизме FEDERATED, который можно использовать для автоматического выполнения удаленных вызовов, когда в некоторых запросах участвует таблица, использующая механизм FEDERATED. Тем не менее, похоже, что этот движок больше не поддерживается MariaDB. (Я также не пришел, чтобы проверить его, чтобы увидеть, с какими другими недостатками он может идти. Я читал где-то, что есть потенциальные проблемы безопасности с этим методом, так как легко прочитать информацию о соединении с главным сервером?)

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

4) Центральная форма входа через OpenID или Oauth в настоящее время не является желательным вариантом. Сейчас я хочу, чтобы у каждого проекта были свои формы регистрации / входа.

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

Answer 1

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

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

Теперь ваш основной проект и ваш подпроект выдают REST-запросы к уже работающему промежуточному сервису. Запросы могут быть очень простыми: действительны ли эти учетные данные? Если да, то установите сеанс в вашем проекте. Если переносимость сеанса важна, используйте общую библиотеку для распознавания значений сеанса из каждого.

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