Как реализовать мультитенантную систему на asp.net mvc?
Всем привет. В общем передо мной встала проблема реализации мультитенантной облачной системы. Разделять данные хочется на уровне баз данных (т.е. для каждого клиента своя база данных), но я не совсем представляю как это реализовать. Сейчас для доступа к данным использую Entity Framework, есть мысль подменять connectionString для разных тенантов, но возможно это не совсем верный ход мыслей?
И вторая часть вопроса. Хочется организовать доступ к данных с разных адресов, т.е. у клиента1 домен вида site1.ru, у клиента2 домен site2.ru и т.д. Сайты могут отличаться друг от друга визуально, но функционально все одинаковые. Возможно ли реализовать такую схему в asp.net mvc? Причем хочется добавлять новых клиентов без перекомпиляции всей системы. Мне приходит вариант с area'ми, но тогда при добавлении нового клиента придется все перекомпилять.
Буду благодарен за любую информацию, заранее спасибо!
Логику вынести в API (WebAPI), к ней обращайться из ASP.NET MVC приложений, которые хостятся под разными доменами и при каждом обращении API будут передавать помимо прочих параметров два дополнительных - откуда запрос (чтобы идентифицировать домен) и кто спрашивает (чтобы идентифицировать пользователя).
Логика в API на основании домена и пользователя будет соответственно использовать нужную базу данных. Можно соответствие домена/пользователя и его базы хранить в служебной базе данных. Там же - хранить данные о пользователях и прочую общую служебную информацию.
Если структура баз данных для каждого пользователя одинаковая, то логикак обработки будет единой. При добавлении нового пользователя - достаточно будет задеплоить на домен новое ASP.NET MVC приложение, настроить его на адрес API, в служебной завести необзодимые данные. Если база под каждого пользователя создается автоматически программно - то все. Если нет - еще базу создать.
Спасибо! В итоге именно к такому решению и пришел.
Это не совсем CMS, просто планируется делать сайты с определенным функционалом, но уникальным внешним видом. И хочется обновлять их централизованно :)
BloodyBlade: тогда все правильно - отделить UI от логики через API. Основной риск в таких случаях, что в какой-то момент понадобится, чтобы для некоторых UI - были особенности в базе и какая-то специфичная логика в API. Потому я бы советовал в служебной базе предусмотреть такую вещь как версия базы, а для специфичной логики в API - либо выносить специфику в отдельные API проекты, которые будут также использовать базовый API + еще свое что-то, А лучше вообще API изначально проектировать как набор мелких сервисов (пакетов), тогда комбинируя их можно более гибко управлять доступным функционалом. Подход называется micro services - почитайте про них. Версионность API также надо учесть - обязательно будет ситуация когда 10 сайтов должны использовать старую версию API а десять других - новую.
И вторая часть вопроса. Хочется организовать доступ к данных с разных адресов, т.е. у клиента1 домен вида site1.ru, у клиента2 домен site2.ru и т.д. Сайты могут отличаться друг от друга визуально, но функционально все одинаковые. Возможно ли реализовать такую схему в asp.net mvc? Причем хочется добавлять новых клиентов без перекомпиляции всей системы. Мне приходит вариант с area'ми, но тогда при добавлении нового клиента придется все перекомпилять.
В общем виде можно сделать так:
Завести таблицу в базе типа ClientSettings, а в ней поля domain, template и пр, которые влияют на содержимое и отображение. Даль по HTTP_HOST вытаскивать настройки из этой таблицы и на их основе показывать нужный контент в нужном дизайне. Обработчик при этом остается единым.
Спасибо за ответ! Само по себе получение нужных данных из базы кажется понятным. Мне, скорее, непонятно как связать воедино систему, в которой есть один сервер и много клиентских сайтов, которые, в принципе могут вообще находиться на разных хостингах и сервер про них, в идеале, ничего не знает.
Я рассматривал вариант сделать контроллер Web Api и на каждом сайте делать к нему запрос для получения и обновления данных. В целом вариант кажется живым: можно создавать отдельные проекты, написанные на html, css и js, при этом сервер будет предоставлять нам только api и знать про них ничего не будет.
Однако я боюсь, что возникнет проблема с поисковиками, т.к. контент будет подгружаться с помощью js. Что вы думаете по этому поводу?
Можно делать клиентские сайты с использованием серверных языков/технологий...ASP.NET, PHP, Ruby и пр, и обращаться к Web Api через через Curl, HttpWebRequest и пр... тогда поисковики будут видеть контент. Самым узким местом мне видится быстродействие, насколько сервер будет оперативно отдавать json сайтам-сателлитам, чтобы они не выглядели тормознутыми... Особенно, если сайтов будет много, а передаваемые объемы большие
Артур Нуруллин: Собственно, я указал, что будут проблемы с быстродействием и постоянной долбежкой. Как вариант, запускать WebRequest с некоторым периодом, писать в базу на локальных сайтах. Периодически перезапускать, чтобы поддерживать актуальность данных. Если есть более интересные предложения - поделитесь.
BloodyBlade: библиотека для организации open id connect сервера, который хранит данные для аутентификации и авторизации клиентов (например, по аналогии с приложениями вконтакте), и примеры.
Сервер аутентификации и авторизации занимается раздачей прав для различных приложений и сайтов, а сайты или web api на других серверах работают в соответствии с этими правами.
В общем покапайтесь в примерах, это как раз решение для подобных задач.
Средний
