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

Question

Мне было поручено сделать корпоративное приложение мультитенантным.Он имеет Java / Glassfish BLL с использованием веб-сервисов SOAP и серверную часть PostgreSQL.У каждого арендатора есть своя собственная база данных, поэтому (по крайней мере, в моем случае) «мультитенант» означает поддержку нескольких баз данных на один сервер приложений.

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

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

Моя единственная достойная идея состоит в том, что потребуется база данных "config" - централизованная база данных для управления информацией об арендаторах, напримеркак строки подключения.BLL может запросить у этой базы данных достаточно информации для инициализации необходимых пулов соединений.Но так как у меня есть только имя пользователя для работы, похоже, мне потребуется централизованный поиск имени пользователя, другими словами, таблица UserName с внешним ключом к таблице Tenant.

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

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

Я прошу следующее:

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

ОБНОВЛЕНИЕ: Решение было успешно внедрено и развернуто, а также прошло первичное тестирование.Спасибо @ mikera за его полезный и обнадеживающий ответ!

Answer 1

Несколько быстрых мыслей:

• Вам определенно понадобится некоторая форма общего индекса управления пользователями (в противном случае вы не можете связать логин клиента с нужным целевым экземпляром базы данных). Однако я бы посоветовал сделать его очень легковесным и использовать его только для первоначального входа. Ваш пользовательский объект все еще может быть извлечен из клиентской базы данных, если вы определили, какая это база данных.
• Вы можете сделать первичный ключ [clientID, username] , чтобы имена пользователей не обязательно были уникальными для всех клиентов.
• Помимо этого тонкого пользовательского индекса, я бы хранил большую часть пользовательской информации там, где она находится в клиентских базах данных . Рефакторинг этого прямо сейчас, вероятно, будет слишком разрушительным, сначала вы должны получить базовую мультитенантную возможность.
• Вам необходимо поддерживать общий индекс в синхронизации с базами данных отдельных клиентов. Но я не думаю, что это должно быть слишком сложно. Вы также можете «протестировать» синхронизацию и исправить любые ошибки с помощью пакетного задания, которое может быть выполнено в одночасье или вашим администратором базы данных по требованию, если что-либо когда-нибудь выйдет из синхронизации. Я бы относился к базам данных клиента как к основному и использовал его для перестроения общего пользовательского индекса по требованию.
• Со временем вы можете провести рефакторинг в сторону полностью разделяемого уровня управления пользователями (и даже, в конце концов, полностью совместно используемых клиентских баз данных, если хотите. Но сохраните это для будущей итерации .....