Как структурировать доменную архитектуру моего веб-приложения? - практический совет - PullRequest
1 голос
/ 06 октября 2010

Итак, я создаю веб-приложение, которое предоставит каждому зарегистрированному пользователю уникальное «рабочее пространство».Это рабочее пространство должно быть доступно любому, кому они дают разрешение.

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

Должен ли я купить универсальные домены, которые я затем использую, чтобы позволить пользователям выбрать один из них для своего рабочего пространства и создать там уникальный поддомен, или как мне подходить к этому?Приложение написано на Rails.

1 Ответ

0 голосов
/ 06 октября 2010

Термин «Домен» имеет несколько значений - я предполагаю, что вы имеете в виду «Домен», как в имя хоста в Домене или URL, также известном как «домен третьего уровня». имя "(например: www.mysite.com - где mysite.com - имя хоста).

Я пытаюсь понять, как управлять доменом управление самим веб-приложением

Ранее я использовал домены 4-го уровня (также известные как локальные имена хостов, например: images.mysite.com, admin.mysite.com), но они были предоставлены службой поддержки в телекоммуникационной компании, которая управляла A-Records для наше доменное имя, поэтому это не был быстрый и простой автоматизированный процесс.

Я также видел, что хостинговые фирмы предоставляют веб-инструменты, которые позволяют вам делать это самостоятельно - там, где они управляют A-Record.

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

Должен ли я купить общие домены, которые я затем используйте, чтобы позволить пользователям выбирать один из них для их рабочего пространства, и создать уникальный поддомен там, или как мне подойти к этому?

Это зависит. Даже если вы размещаете приложение, нет никаких причин, по которым клиент не может настроить домен 4-го уровня, который указывает на ваш сервер, а не на его собственный; это будет означать, что вашему приложению нужно будет искать домен 4-го уровня только потому, что нет никакой гарантии, что они будут использовать домен 3-го уровня, о котором ваше приложение «знает».

Скажите, Джон Браун из знаков «Студия ABC» на mysite.com, что мне делать? Дайте им studioabc.mysite.com или mysite.com/studioabc

Это зависит от того, чего вы хотите достичь и от чего вам комфортнее:

  • Опция "mysite.com/studioabc" должна быть проста для автоматической инициализации через ваше приложение, поэтому в некоторых случаях с ней было бы легче работать.
  • Проблема с параметром «mysite.com/studioabc» заключается в том, что (в зависимости от степени вашего контроля над веб-сервером) все ваши файлы (от всех клиентов) будут находиться в одном месте - это сделает его более сложный в управлении (резервные копии и т. д.).
  • «studioabc.mysite.com» будет труднее и медленнее подготовить (поскольку изменения DNS требуются), но у вас есть преимущество в том, что вы можете запускать их как отдельные сайты, если хотите. Например, если «thebeatles.mysite.com» сработает, вы сможете переместить его на другой физический веб-сервер с более высокой производительностью, но вы не сможете так легко переместить «mysite.com/thebeatles». *

В обоих случаях ваше приложение будет мультитенантным (за исключением таких случаев, как studioXXX.mysite.com, где сайт размещен в другом месте); доступ к данным становится проблемой - хранение данных клиентов отдельно. Для этого есть разные подходы, см. Эту статью в Многопользовательская архитектура данных . (Кстати, я знаю, что это статья для MS, и вы работаете в Rails! - но это отличная статья, которая будет вам полезна).

Покупка родового имени, ну, в общем, родового. Если вы хотите создать сообщество клиентов вокруг определенной вещи, тогда получите доменное имя, которое имеет для этого смысл; если вы используете свое собственное доменное имя, оно фактически будет формой рекламы.

И вместо того, чтобы быть mysite.com, это должно быть obscuredomain.com, что фактическое веб-приложение находится в и поэтому дает поддоменов, потому что mysite.com это маркетинг сайт.

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

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

Наконец, у вас может быть несколько доменов, каждый из которых предоставляет свой уровень обслуживания (и каждый может иметь домены 4-го уровня, висящие за ним вместо www):

  • www.mysite.com
  • www.mysitepremium.com
  • www.mysitecheapskate.com
...