我们希望为我们的 SaaS 产品客户提供免费试用。因此，客户在注册时输入所需的子域名，他们将获得一个类似 clientname.ourmainsite.com 的网站进行免费试用。我们不想为每个客户手动设置子域名。经过研究，我发现这可以通过为 ourmainsite.com 设置“通配符”DNS 记录来实现，因此我们需要在 ourmainsite.com 的 DNS 中添加一个指向我们服务器的 *. ourmainsite.com 条目。
但这似乎将所有子域都指向单个站点，这与我们当前的设置相反，在当前的设置中，每个客户端域在 IIS 中都有一个单独的网站设置，如 client1.com、client2.com 等。与每个域的单独网站相比，使用单个网站为多个域提供的选项听起来如何？这种方法的优缺点是什么？哪个选项更安全？哪个选项使用更少的资源，例如服务器上的内存？
我主要关心的是，在当前设置中，我们可以为每个站点设置单独的应用程序池。但是，如果我们采用“通配符”DNS 记录的方法，即所有域都指向一个站点，那么如果某个站点受到攻击或流量过大导致服务器上的其他站点速度变慢，那么如何控制或监控这种情况，因为我们无法为每个域设置单独的应用程序池？有没有其他替代方案？我读到过许多 SaaS 公司都遵循“通配符”DNS 方法。那么他们如何处理某些特定站点的加载或攻击？或者他们是否仅对试用站点使用“通配符”DNS 方法设置虚拟子域（如 client1.ourmainsite.com），并在试用后在 IIS 中为其域创建单独的站点（如 client1.com）？
答案1
如果您不想设置单独的网站，您可以让 *.mydomain.com 转到 IIS 服务器的特定 IP 地址，并且您需要在该服务器上的单个网站上进行全能绑定，以便它知道监听未知名称。这听起来很方便，但这个想法很糟糕。不要这样做。
听起来您需要为每个子域创建一个站点并将该客户端的特定子域放入绑定中，并为每个站点创建一个应用程序池以将它们分开。
如果您要拥有很多这些，我建议使用 PowerShell 来帮助您自动创建网站、内容目录和应用程序池设置作为入职工作流程的一部分。
如果您担心某个网站受到重击并拖垮所有其他网站，您可以在应用程序池的高级设置中建立 CPU 限制规则来防止这种情况发生。如果所有流量都流向一个网站，则无法做到这一点。
这种方法的替代方法是设置某种负载平衡（我使用 AWS 应用程序负载平衡器），以根据主机或路径将传入请求定向到特定目标组。然后，目标组将进行健康检查，以密切关注目标组中实例的状态。然后，cloudwatch 事件可以看到不健康的实例，并触发 lambda 函数，该函数将启动添加到该目标组的另一个实例。您仍然可以在后台使用 IIS 作为 Web 服务器，但 AWS 提供了其他方式来按需扩展它。这只是 AWS 示例，但我相信 Azure 或 GCP 也可以做到同样的事情。