Создание веб-портала, который будет сдан в аренду клиентам. Нужно предложение архитектуры

Question

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

Теперь я не хочу, чтобы они получали файлы моего веб-портала, но все же могу использовать собственный фирменный портал.

Одним из решений, которое кто-то предложил здесь, было размещение фирменной версии на моем сервере и все это через Iframe в домене клиента. Однако эта идея мне не очень понравилась.

Один второй подход, который я исследовал и нашел, состоял в том, чтобы разместить портал на новом IP на моем сервере и попросить клиента указать свой домен на этот ip.

Веб-портал будет продан многим клиентам, и все они будут иметь отдельные пользовательские интерфейсы и торговые марки, поэтому это необходимо.

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

Answer 1

iFrames - зло.

С учетом сказанного, я бы, вероятно, выбрал субдомен.Они добавляют субдомен, такой как webportal.somecompany.com, который указывает на вас, и ваш веб-сервер направляет их на правильный размещенный экземпляр вашего приложения на основе субдомена.Таким образом, их www.somecompany.com все еще идет на их сайт.

Answer 2

Мы запускаем приложение SAAS, которое поддерживает брендинг, и мы делаем это, динамически обслуживая CSS.Если у всех ваших клиентов есть уникальное доменное имя, направленное на ваш сервер, вы можете выбрать свои CSS-файлы по доменному имени: если клиент входит в систему по адресу «http://portal.customer.com/login",, вы можете получить его HTML-ссылку на файл» / stylesheets / portal.customer.com.css "и т. д. Кроме того, вы можете создать поддомен для каждого из ваших клиентов и указать их все на своем главном сервере, используя очень похожий код для выбора CSS.

Это позволяету вас есть один IP-адрес для всех клиентов (и только столько серверов, сколько вам нужно для поддержки всех ваших клиентов за этим IP-адресом), вместо одного IP-адреса / сервера на клиента - следует сократить экономию на хостингестоит!

(ПРИМЕЧАНИЕ. Я склоняюсь к подходу с использованием поддоменов, и чем больше я об этом думаю. Если вы используете HTTPS, он позволит вам использовать один сертификат "* .yourdomain.com",вместо того, чтобы пытаться связываться с отдельными сертификатами для каждого клиентского домена.)

Answer 3

Вам не нужно запускать разные IP для разных клиентов.HTTP 1.1 поддерживает Host: например,

GET / HTTP/1.1
Host: example.com

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

Пожалуйста, ради себя не делайте фреймы.В Интернете много информации об архитектуре для мультитенантных приложений.

Answer 4

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

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

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