一个应用程序的大型实例,还是多个中型应用程序?

我看不出你两个选择中任何一个的好理由。我认为真正的答案就在中间:拥有多个实例,每个实例承载多个客户机。

这又增加了自动化处理的另一层,但这意味着你可以保持廉价的主机(你不需要很快出去买一台Cray),而且(希望)这种心态意味着你可以很容易地进行故障转移备份。

但我们不要超过自己…我们说的是网络应用,对吧?在不同的计算机上获取数据库和ASPNET。集群您的数据库,您将有一个更快乐的时间玩各种前端场景。你也可以在任何一个区域先用完烟支的情况下进行高档化。

听上去,您最终将得到一个超过一半的集群数据库,如果不是一个完整的十几台数据库机器,而且只有几个前端设备。

至于定制,你已经做到了。您要么提供一个完全由数据库承载的可编辑模板集,要么必须自定义WHO实例。我是第一个。这是一个很大的工作(没有很多回报),但它是值得的,因为您只需要在(您愿意的)时候更改核心代码。你需要升级。 搜索100个客户的自定义实例以确保安全升级将杀死开发人员! 模板就是答案。至少,您可以不费吹灰之力就允许自定义CSS(但他们需要知道他们的东西的人)。

编辑:我看到过一些关于一体式方法的帖子。在多台机器上拆分实例可使您与以下几项隔离:

• 如果您引入了一个测试中没有发现的bug,那么一次只影响少数客户机

• 硬件故障。一个超级服务器崩溃会同时让很多人恼火。拥有一个故障转移大型服务器是非常昂贵的。每运行三到四台服务器就有一个备用故障转移箱 许多的 更便宜,让人讨厌的人更少。

• 性能可以在每一个客户机的盒子之间进行平衡,因此您可以将一些轻量级的客户机与一个重的客户机放在一起,或者只将一些中等用途的客户机放在一个盒子中,等等。

• 同样的想法,使用高峰或其他减速只影响同一个盒子上的客户机。当然,对于数据库来说,这并不意味着相同,但是当您到达那里时,可以将其划分为一组集群。

当面临类似的挑战时,我们做了以下工作:

1. 我们有一个带有多个SQL服务器的代码库。我们确实使用相同代码库的副本维护多个IIS服务器。我们可以自由地将客户机从SQL Server移动到SQL Server以最大限度地提高性能。

2. 如果客户有美元,我们将在他们自己的服务器上安装它们,并为他们维护一个单独的IIS服务器。这可以满足那些每月支付更多钱(10倍以上)的最大客户。但是,我们不会给它们单独的代码库。如果他们需要一个mod,我们会在每个客户的基础上使其可见(参见3)

3. 自定义编程通常会产生一个可配置的选项。甚至那些付钱让我们拥有自己服务器的人也能得到相同版本的代码。有时,它就像代码中的一个子句那样简单:“如果客户=”我们的大客户然后打开这个选项“。是的,这是笨拙的硬编码,但如果客户有足够的钱,我可以。

4. 我不太明白你的问题,你是否想把不同客户的数据混合到一个大数据库中。我们的规则就是我们 从未 做那件事(从来没有过)。这是我们做出的最明智的选择之一。它使数据操作风险大大降低,数据恢复更加容易。

随着每个客户需求的增加,单个实例的最大优势将逐渐扩大。例如,如果您在一台服务器上运行,而一个客户突然需要更多的性能,那么您就被填满了。但是,如果他们都是个人的,那么将客户转移到一个闪亮的新服务器上就相对容易了。

最大的缺点是单独管理实例。(不管它们是否都在同一服务器上运行)。

无论如何,您应该只有一个代码基实例。而且定制都应该通过插件和配置来控制。前端应该自然地与内容分离。虽然改变的成本可能会更高,但你可以为你的其他客户提供的功能方面的好处(这只是你被要求做的定制)肯定会得到回报。也就是说,与多个代码库相比,管理一个代码库要容易得多。

我强烈建议使用贵公司托管的单一实例。这有以下优点:

• 您可以物理访问所有代码 和数据库进行更改和 更新。
• 你控制的质量 正在运行的硬件。
• 当你在公共代码中修复一个bug时, 你已经一次修好了 客户。
• 您可以重构应用程序 设计以更好地支持客户 具体的代码和避免分叉。
• 随着客户数量的增长, 可以放大和缩小 服务器见面 性能/响应能力 要求。
• 您的应用程序代码和数据库 不能被篡改 “好奇的”顾客。

我不得不说这几乎更重要 哪里 您的应用程序正在运行,而不是它有多少个独立的实例。

当然,由于支持/维护开销,维护多个独立实例并不理想,但是如果这些应用程序。都在你控制的服务器上,生活比需要远程/物理访问不同的客户网络和服务器容易得多。

乔尔·斯波斯基也谈到了这个 StackOverflow podcast 67 .

乔尔学到的一件事 销售FogBugz:设计用于 安装在服务器内部 客户的网站,完全由 那个顾客,几乎不值得 麻烦

相对而言,2000万条记录并不是一个巨大的SQL Server数据库。一个配置良好的SQL服务器可以轻松地处理这个大小。但是,更重要的是并发访问数据库的次数。但是,您说每个客户只有几个用户,所以在并发性级别增加之前,不太可能影响您。

以上这些都是很好的观点,但您遗漏了两个关键问题。服务的价格是多少?最终需要支持多少客户(数量级)(即市场规模)?在3年内,您最多将有10个客户,每个客户每年向您支付50万美元,或500个客户每年向您支付10000美元?对于一小部分高薪的优质客户,单独部署的优势是显而易见的,而较低的价格和较大的客户群则需要一个共享的解决方案(la oli的评论)是最好的选择。或者使用一个云平台,尽管我只是阅读了这些炒作和修补,而不是在现场部署。

额外问题1:表布局、索引、读/写次数、存储过程的效率和复杂性(您使用的是procs或至少是准备好的语句,对吗?)在一定程度上,所有这些都比数据库中的物理记录数量重要得多。除此之外,根据我上面提出的一些问题,您可能会发现自己需要为每个客户或一个客户池提供单独的SQL Server实例。

附加问题2:在这种情况下,将时间投入到模板化和插件架构的设计中是非常重要的,您需要尽早完成。一旦你正在为付费客户定制代码,你可能就没有时间去做正确的事情了。这一点压力不够大。通过模板和管理工具,您可以快速深入地访问产品中的数据驱动更改,从而节省大量时间。随着公司/团队的扩展,您可以增加较少的技术人员,他们可以是“产品专家”,可以执行90%的定制和维护,从而释放核心以继续开发或转到其他项目。最后,在这个计划过程中不要忽略数据层。拥有(几乎)不可变的存储过程和表的核心数据层非常重要,自定义表和存储过程使用良好的命名约定进行了清晰的划分。

祝您好运,如果您需要更具体的建议,请随时提供更多细节。

基于这里收到的一些建议,我们最终实现了应用程序的单块多租户版本。

我很高兴我们做到了。当它完成时,我们有3到4个分叉的代码库(主要是自定义皮肤和我们没有N级支持的东西,还有一些实际的特性),而且它只是变得更加疯狂。

我们得到了多租户版本,并成功地折叠了所有东西。最终有很多事情需要考虑,也有很多事情需要跟踪,但是我们的客户甚至不知道他们已经被转移到了一个新的系统中。

我会说,实际的客户迁移有点麻烦。起初我以为我们可以在后端手工完成,但最后我不得不编写一些相当复杂的脚本来完成这项工作。标识列太多了,在导入到实时生产系统时,不能临时关闭约束。