我对即将开始的订阅服务的架构有几个问题，我正在寻找一些关于如何最好地设置它的反馈。
我不会像 Basecamp 那样拥有大量客户，可能只有几百个，我想知道建立客户站点的可靠架构是什么。我在专用机器上运行 SQL Server 和 .NET。应该为每个客户创建一个新数据库以控制和隔离数据还是将它们全部保存在一个数据库中？
我也在考虑为每个客户创建一个子域，以便可以根据需要对每个站点进行修改。客户 URL 如下所示：
我将能够“插入”将上传到站点的报告，以便每个客户都可以根据需要进行自定义。在我的脑海中，这需要将每个子域都放在自己的代码库上，以便上传这些报告。
因此，在主站点上，客户将注册他们的新订阅，我将以编程方式从主代码库为客户创建一个新目录，然后为客户创建一个指向新目录的子域，最后是他们的数据库。
这听起来对吗？我在正确的轨道上吗？其他此类网站如何完成同样的事情？
谢谢你让我弯下你的耳朵。
从维护的角度来看，每个客户都有一个虚拟目录让我感到害怕。做了类似的事情后，我会在你暗示的时候创建单独的域指针。然后您可以检查引荐标头以查看应显示的内容。我可能会创建一个主站点模板并为每个客户动态地标记它。您仍然可以为客户特定的报告创建单独的文件夹，或者如果您确实需要该客户独有的自定义页面。我只是不会让每个人都有自己的网站。
独立站点（包括数据库）的优势在于一个客户端的命运不受其他所有客户端的约束。在部署到其他所有人之前升级（试用）到子集会更容易。正如 Scot 所指出的，这里最大的问题是时间。您希望使事情尽可能自动化（并且经过良好测试）等。当客户离开时也很容易。您可以随时备份他们的数据库并将其发送给他们（例如）。
自动配置新站点和数据库并不容易，并且这样做的帐户将需要大量权限 - 因此您的安全测试需要比平时更好。
多租户方法有助于最大限度地减少您的时间，但您必须小心，您不希望客户数据混淆。
在一个应用程序（和数据库）中可行的一种方法是使用 HttpHandlers（也许是 MVC 框架），以便某种客户端标识符是 URL 的一部分 - 但文件夹不必物理上存在（或实际上在 IIS 意义上）。这样您就不必担心获得正确的文件夹权限；但是您必须小心正确识别客户、他们的 ID，并确保客户不能使用不属于他们的 ID 拨打电话。
https://www.foobar.com/[clientid]/subscriptions
这样做的好处是它相对简单：一切都在应用程序中，您不必担心添加新的 DNS 记录、设置目录和/或数据库权限等。