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