我们为一位客户编写的网络应用程序将被产品化并出售给数十家公司，我们将进行托管。
我可以使用一些关于为每个客户推出单独实例与使用单个（或非常少数）多租户实例的优缺点的指导。
首先，随着我们的提升，我将 为每个新客户推出一个单独的应用程序实例（他们将一次上线一个），因为它是唯一的直接选项。我认为，就维护而言，这不会很好地扩展 - 一旦有超过4或5个实例，推出更改将变得非常繁琐并且可能容易出错。除非我们以某种方式自动化。
此外，如果人们需要自定义，单实例哲学似乎可能导致一堆分叉。并且避免这种情况会很好。
那么您的经历是什么？
奖励问题＃1： 10个SQL Server（每个记录2m记录）与一个20m记录的SQL Server之间的性能差异是什么？假设它们都在一个表中，我们主要在单个记录上进行插入和选择。有时，选择位于索引的varchar（12）或日期字段上。
奖金问题＃2：我认为为了避免分叉，我们必须使自定义可配置，或构建插件架构。但是，这可能会增加进行自定义的成本，而且我不想成为需要一周时间来调整文本框大小的商店之一，和我不想过度投资基础设施。有什么想法？
比例详情
每位客户都拥有相当数量的数据 - 最多可达数百万条记录。
将会有非常少量的并发用户，每个客户只有少数用户，以及我们最终的少数内部销售代表。
目前还不清楚每个客户是否都需要定制，但我想其中一些可能会定制，也许其中一些变化将是其他客户不希望看到的内容。
答案 0 :(得分：3)
面对类似的挑战时，我们采取了以下措施：
我们有一个带有多个sql服务器的代码库。我们使用相同代码库的副本维护多个iis服务器。我们可以自由地将客户端从sql server移动到sql server以最大限度地提高性能。
如果客户有$ for it，我们将在他们自己的服务器上安装它们并为它们维护一个单独的iis服务器。这适用于每月支付更多钱（最多10倍钱）的最大客户。但是，我们不会为它们提供单独的代码库。如果他们需要一个mod，我们会在每个客户的基础上看到它（见＃3）
自定义编程通常会产生可配置选项。甚至支付给我们自己的服务器的人都获得相同版本的代码。有时它就像代码中的一个条款一样简单，“如果客户=”我们的客户那么打开这个选项“。是的，这是硬编码，但如果客户有足够的钱，那对我来说没问题。
我不清楚你是否想要将不同客户的数据混合到一个大数据库中。我们的规则是从不那样做（永远不会）。这是我们做过的最明智的选择之一。它使数据操作风险更小，数据恢复更容易。
答案 1 :(得分：2)
我认为你选择两种选择都没有充分的理由。我认为真正的答案在于中间位置：拥有多个实例，每个实例都托管多个客户端。
这增加了另一层自动化处理，但这意味着你可以保持托管便宜（你不需要很快出去购买Cray）并且（希望）这种心态意味着你可以做故障转移备份相当容易。
但是，让我们不要超越自己...我们正在谈论一个网络应用，对吧？在不同的机器上获取您的数据库和aspnet。集群您的数据库，您可以更快乐地玩各种前端场景。你也可以升级任何一个用完的粉扑区域。
听起来，如果不是十几台数据库机器和只有几个前端机箱，你最终会有一半的集群数据库。
至于自定义，你已经钉了它。您要么提供完全由数据库托管的可编辑模板集，要么必须自定义哪些实例。我是第一个。这是一项很多的工作（没有太多的回报），但它非常值得，因为你只需要在（你将会！）进行升级时更改核心代码。 通过一百个客户的自定义实例进行搜索以确保他们安全升级会杀死开发人员！模板就是答案。至少，你可以在没有太多痛苦的情况下允许自定义CSS（但他们需要知道他们的东西的人）。
编辑：我看过一些帖子用于一体化方法。在多台计算机上拆分实例可以使您避免以下几件事情：
如果您引入未在测试中发现的错误，一次只能影响少数客户
硬件失败。让一台巨型服务器倒塌会立刻惹恼很多人。拥有故障转移大型服务器非常昂贵。每三个或四个正在运行的服务器上有一个备用故障转移盒，很多更便宜，并且惹恼了更少的人。
可以在逐个客户端的框之间平衡性能，因此您可以将一些轻量级客户端放在一个繁重的客户端上，或者只填充一些中等用户的盒子等等
同样的想法，使用峰值或其他减速只会影响同一个盒子上的客户端。当然，这对数据库来说并不一样，但是当你到达那里时，你可以将它分成一组集群。
答案 2 :(得分：1)
随着每个客户的需求增加，个别实例的巨大优势将逐渐扩大。例如，如果您在单个服务器上运行，并且一个客户突然需要更多的性能，那么您就会被填充。但如果他们都是个人，那么将该客户转移到一个闪亮的新服务器相对容易。
最大的缺点是单独管理所有实例。 （无论它们是否都在同一台服务器上运行）。
无论你应该只拥有一个代码库实例。应该通过插件和配置来控制定制。前端应该自然地与内容分开。虽然进行更改的成本可能会更高，但是您可以为其他客户提供的功能（这些只是您被要求进行的自定义）的好处将会得到回报。也就是说，管理单个代码库要容易多少，而不是几个代码库。
答案 3 :(得分：1)
我强烈建议您使用贵公司托管的单一实例。这具有以下优点：
我不得不说，运行应用程序的 几乎更重要，而不是有多少单独的实例。
当然，由于支持/维护开销，维护多个单独的实例并不理想，但是如果这些应用程序。所有这些都在您控制的服务器上，生活要容易得到对不同客户网络和服务器的远程/物理访问。
Joel Spolsky也在StackOverflow podcast 67上讨论了这个问题。
相对来说，2000万条记录并不是一个巨大的SQL Server数据库。单个配置好的SQL Server可以轻松处理这个大小。但更重要的是对数据库的并发访问次数。但是你说每个客户只有少数用户，所以在并发性水平提高之前不太可能遇到你。乔尔从中学到了一件事 销售Fogbugz：设计用于的软件 安装在内部的服务器上 客户的网站，完全控制 那个客户，几乎永远不值得 麻烦
答案 4 :(得分：1)
以上所有都是好点，但你错过了两个关键问题。提供的服务价格是多少，您最终需要支持多少客户（数量级）（即市场规模）？在3年内，您最多可以拥有10个客户，每个客户每年将支付500,000美元，还是500个客户，每个客户每年支付10,000美元？对于一小部分高薪高端客户而言，个别部署的优势是显而易见的，而较低的价格和较大的客户群需要共享的解决方案（la Oli的评论）是最好的方式。或者选择云平台，虽然我只是阅读炒作并修改而不是在现场部署。
奖金问题1：表格布局，索引，读/写次数，存储过程的效率和复杂性（您正在使用过程或至少准备好的语句，对吗？）所有这些都比数量多得多数据库中的物理记录到了一个点。除此之外，您可能会发现自己需要为每个客户或一组客户提供单独的SQL Server实例，这再次取决于我上面提出的一些问题。
奖金问题2：在这种情况下，将时间投入到设计中进行模板化和插件架构是必不可少的，您需要尽快完成。一旦您为付费客户定制代码，您可能没有时间做正确的事情。这一点不够强调。模板和管理工具可让您快速深入地访问产品中数据驱动的更改，从而为您节省大量时间。随着您的公司/集团的扩展，您可以添加更少的技术人员，他们可以成为“产品专家”，可以执行90％的自定义和维护，释放您的核心以继续开发或转移到其他项目。最后，在此规划过程中不要忽视您的数据层。拥有（几乎）不可变的存储过程和表的核心数据层非常重要，使用良好的命名约定清楚地划分自定义表和存储过程。
祝您好运，如果您想要更具体的建议，请随时提供更多详细信息。
答案 5 :(得分：0)
根据此处收到的一些建议，我们最终实现了应用程序的单一多租户版本。
我很高兴我们做到了。到它完成时，我们有3或4个代码库的分支（主要是自定义皮肤和我们没有n级支持的东西，但也有一些实际的功能），它只是变得越来越疯狂。
我们获得了多租户版本，并成功地将所有内容折叠起来。最后需要考虑很多事情并且要记住很多事情，但我们的客户甚至都不知道他们已经搬到了新系统。
我会说实际的客户迁移有点熊。我一开始认为我们可以在后端手工完成，但最后我不得不编写一些相当复杂的脚本来完成工作。有太多的标识列，并不像您可以在导入实时生产系统时暂时关闭约束。