如何构建 Web 应用程序的域架构？ - 实用建议

发布于 2024-09-26 17:27:12 字数 221 浏览 4 评论 0原文

因此，我正在创建一个网络应用程序，它将为每个注册用户提供一个独特的“工作空间”。任何获得其许可的人都应该可以访问此工作空间。

我有我的营销网站的主域，但我正在尝试弄清楚如何管理网络应用程序本身的具体域管理。

我是否应该购买通用域，然后使用它来允许用户为他们的工作区选择其中一个域，并在那里创建一个独特的子域，或者我应该如何处理这个问题？

我的网络应用程序是用 Rails 编写的。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一影成城 2024-10-03 17:27:12

术语“域”有几个含义 - 我假设您的意思是“域”，如主机名中的域名或URL，也称为“三级域名”（例如：www. mysite.com - 其中 mysite.com 是主机名）。

我正在想办法
管理具体域
Web 应用程序本身的管理

我之前使用过 4 级域名（也称为本地主机名，例如：images.mysite.com、admin.mysite.com），但这些是通过管理 A 的电信公司的帮助台提供的-我们域名的记录，因此这不是一个快速且简单的自动化过程。

我还看到托管公司提供基于网络的工具，允许您自己执行此操作 - 他们在其中管理 A 记录。

在这两种情况下，第四级域的管理都是手动执行的。我不知道有人在开发的应用程序中自动执行此操作 - 这显然是可能的，但绝对不简单。

我应该购买我所使用的通用域名吗？
然后用来让用户选择
其中之一用于他们的工作空间，以及
在那里创建一个唯一的子域，或者
我应该如何处理这个问题？

这取决于。即使您托管应用程序，客户端也没有理由不能设置指向您的服务器而不是他们自己的服务器的第四级域；这意味着您的应用程序只需要查找第四级域，因为不能保证它们将使用您的应用程序“了解”的第三级域。

比如“Studio 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（网站托管在其他地方）；数据访问成为一个问题——保持客户端数据分离。为此，您可以采取不同的方法，请参阅这篇有关多租户数据架构<的文章/a>. （顺便说一句 - 我知道这是一篇 MS 文章，而您正在 Rails 中工作！ - 但这是一篇优秀的文章，会很有帮助）。

购买通用名称是通用的。如果您想围绕特定事物建立一个客户社区，那么就获得一个对此有意义的域名；如果您使用自己的域名，它实际上是一种广告形式。

它不是 mysite.com，
应该是obscurdomain.com吗
实际的网络应用程序位于和
因此给出了子域，
因为 mysite.com 是营销
网站。

我认为两者都可以——问题是你认为你的客户会更喜欢什么？这与您的商业模式如何相结合？域名是任何在线形象的重要组成部分（从营销方面来看），因为它有助于定义网站及其使用者的身份 - 因此请谨慎选择。

你想把这个卖掉吗？如果您愿意，您会希望将其建立在您乐意与之一起出售的域名上。因此，考虑到这一点，我将为您的产品/服务提供一个域名，并为您的业务提供一个单独的域名 - 假设您有一天想要出售该网站，而不是您的业务。或者，如果网站是业务，并且您很乐意将它们作为一个整体出售，那么我会将其全部放在同一个域名下。

最后，您可能有多个域，每个域提供不同级别的服务（每个域都可以挂有 4 级域，而不是 www）：

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

The term Domain has a few meanings - I assume you mean "Domain" as in the hostname in a Domain Name or URL, also known as the "third-level domain name" (e.g: www.mysite.com - where mysite.com is the hostname).

I am trying to figure out how to
manage the nitty-gritty domain
management of the web app itself

I've usd 4th level domains before (also known as local hostnames, e.g: images.mysite.com, admin.mysite.com), but these were provisied via a helpdesk at the telco who managed the A-Records for our domain name, so it wasn't a quick and easy automated process.

I've also seen hosting firms provide web-based tools that allwo you to do this yourself - where they manage the A-Record.

In both cases management of the 4th level domains is performed manually. I haven't hread of anyone automating this within an app the have developed - it's obviously possible but definately non-trival.

Should I buy generic domains that I
then use to allow the users to chose
one of them for their workspace, and
create a unique subdomain there, or
how should I approach this?

It depends. Even if you host the application there's no reason why the client can't set-up a 4th level domain that points at your server and not their own; this would mean that your app would need to lookout for the 4th level domain only as there's no guaratee they'll be using a 3rd level domain your app "knows about".

Say John Brown from 'Studio ABC' signs
up at mysite.com, what should I do?
Give them studioabc.mysite.com or
mysite.com/studioabc

It depends on what you want to achieve and what over-heads your comfortable with:

The "mysite.com/studioabc" option should be easy to auto-provision through your app, so in some ways that'd be easier to work with.
A problem with the "mysite.com/studioabc" option is that (depending on how much control you have over the web server) all your files (from all clients) will be in the same place - that will make it more complex to manage (back-ups, etc).
The "studioabc.mysite.com" is going to be harder and slower to provision (as DNS changes are required), but you have the advantage in that you can run them as seperate sites if you want to. For example, if "thebeatles.mysite.com" takes off you'd be able to move it to a different physcial web server that had better performance, but you can't move "mysite.com/thebeatles" so easily.

In both cases your app will be a Multi-tenanted one (except in cases such as studioXXX.mysite.com where the site is hosted elsewhere); data access becomes an issue - keeping the clients data separate. There's different approaches you can take for this, see this article on Multi-Tenant Data Architecture. (BTW - I know it's an MS article and you're working in Rails! - but it's an excellent article which will be helpful).

Buying a generic name is, well, generic. If you wanted to foster a community of clients around a particular thing then get a domain name that makes sense for that; if you use your own domain name it would in-effect be a form of advertising.

And rather than it being mysite.com,
should it be obscuredomain.com that
the actual web app resides at and
therefore gives the subdomains of,
because mysite.com is the marketing
site.

I think either will work - the question is what do you think you're clients would prefer? How does that stack up with your business model? The domain name is an important part of any online presence (from a marketing side) as it helps define the identity of the site and those who use it - so choose carefully.

Do you ever want to sell this off? If you do you'd want to build it on a domain name that you were happy to sell with it. So with that in mind I'd have a domain name for your product / service and a seperate one for your business - assuming that you'd one day want to sell the site but not your business. Alternatively, if the website is the business and you're happy to sell them as a whole package then I'd put it all under the same domain name.

Finally, you might have more than one domain, each providing a different level of service (and each could have 4th level domains hanging off it instead of www):