Вопросы архитектуры веб-сайта подписки + SQL Server & .NET

Question

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

У меня не будет большого количества клиентов, как Basecamp, может быть, несколько сотен, и мне было интересно, какой будет надежная архитектура для создания сайтов клиентов. Я использую SQL Server и .NET на выделенной машине. Следует ли создать новую базу данных для каждого клиента, чтобы иметь возможность контролировать и изолировать данные или хранить их все в одной базе данных?

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

https://customer1.foobar.com

https://customer2.foobar.com

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

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

Звучит ли это правильно? Я на правильном пути? Как другие такие сайты выполняют то же самое?

Спасибо, что позволили мне немного погладить ваше ухо.

Answer 1

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

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

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

Один из подходов, который будет работать в одном приложении (и базе данных), заключается в использовании HttpHandlers (возможно, инфраструктуры MVC), чтобы некоторый вид идентификатора клиента был в части URL-адреса, но папка недолжны существовать физически (или практически в смысле IIS).Таким образом, вам не нужно беспокоиться о правильном разрешении папки;но вы должны быть осторожны с правильной идентификацией клиентов, их идентификаторов и убедитесь, что клиенты не могут совершать звонки с использованием идентификатора, который им не принадлежит.

https://www.foobar.com/[clientid]/subscriptions

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

Answer 2

С точки зрения обслуживания, наличие виртуального каталога для каждого клиента пугает меня. Сделав нечто подобное, я бы создал отдельные указатели домена, как вы намекаете. Затем вы можете проверить реферальные заголовки, чтобы увидеть, что должно отображаться. Я бы, вероятно, создал бы один основной шаблон сайта и динамически маркировал бы его для каждого клиента. Вы по-прежнему можете создавать отдельные папки для пользовательских отчетов или если вам действительно нужны пользовательские страницы, уникальные для этого клиента. Я бы не стал делать каждый свой сайт.