5

我们为一个客户编写的 Web 应用程序将被产品化并出售给数十家公司，我们将进行托管。

关于为每个客户推出单独的实例与使用单个（或极少数）多租户实例的优缺点，我可以使用一些指导。

起初，随着我们的增加，我将不得不为每个新客户推出一个单独的应用程序实例（他们将一次上线一个），因为这是唯一直接的选择。我想这在维护方面不会很好地扩展——一旦有超过 4 或 5 个实例，推出更改将变得非常乏味并且可能容易出错。除非我们以某种方式自动化。

此外，如果人们需要定制，单实例哲学似乎可能会导致一堆分叉。避免这种情况会很好。

那么你有什么经验呢？

额外的问题 #1： 10 个 SQL Server 与每个 2m 记录的 SQL Server 与一个巨大的 20m 记录之间的性能差异是什么？假设它们都在一个表中，我们主要对单个记录进行插入和选择。有时选择在索引的 varchar(12) 或日期字段上。

额外问题 #2：我想为了避免分叉，我们必须使自定义项可配置，或者构建一个插件架构。但是，这可能会增加进行定制的成本，我不想成为那些需要一周时间来调整文本框大小的商店之一，我不想过度投资于基础设施。对此有什么想法吗？

秤详细信息

每个客户都将拥有相当数量的数据——多达几百万条记录。

将有非常少量的并发用户，每个客户只有几个，加上我们这边的少数内部代表。

目前尚不清楚每个客户是否需要定制，但我想说其中一些可能会，也许其中一些更改将是其他客户不希望看到的东西。

4

6 回答 6

3

当面临类似的挑战时，我们是这样做的：

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

  2. 如果客户有美元，我们会将它们安装在他们自己的服务器上，并为他们维护一个单独的 iis 服务器。这适用于每月支付更多钱的最大客户（多出 10 倍的钱）。但是，我们没有给它们单独的代码库。如果他们需要一个模组，我们会在每个客户的基础上使其可见（参见#3）

  3. 自定义编程通常会产生可配置的选项。即使是付钱让我们拥有自己的服务器的人也得到了相同版本的代码。有时它就像代码中的一个子句一样简单，上面写着“如果客户=”我们的大客户然后打开这个选项”。是的，那是笨拙的硬编码，但如果客户有足够的钱，那对我来说很好。

  4. 我没有完全从你的问题中得到你是否想将不同客户的数据混合到一个大数据库中......我们的规则是我们永远不会这样做（永远不会）。这是我们做过的最明智的选择之一。它使数据操作的风险大大降低，并且更容易恢复数据。

于 2009-09-14T14:26:04.947 回答
2

我认为您的两种选择中的任何一种都没有充分的理由。我认为真正的答案在中间的某个地方：拥有多个实例，每个实例托管多个客户端。

这增加了另一层自动化处理，但这意味着您可以保持主机便宜（您不需要很快出去购买 Cray）并且（希望）这种心态意味着您可以相当轻松地进行故障转移备份.

但是，我们不要超越自己……我们正在谈论一个网络应用程序，对吧？在不同的机器上获取您的数据库和 aspnet。集群您的数据库，您将在各种前端场景中玩得更开心。您还可以升级先用完粉扑的区域。

听上去，如果不是一打数据库机器的话，你最终会得到一个集群数据库超过一半，而且只有几个前端机器。

至于定制，你已经搞定了。您要么提供一组完全由数据库托管的可编辑模板，要么必须自定义 who 实例。我都是第一个。这是很多工作（没有太多回报），但它非常值得，因为您只需要在（您将！）进行升级时更改核心代码。搜寻一百个客户的自定义实例以确保他们安全升级会杀死开发人员！模板就是答案。至少，您可以轻松地允许自定义 CSS（但他们需要了解他们的东西的人）。

编辑：我已经看到了一些关于多合一方法的帖子。将实例拆分到多台机器上可以使您免受几件事的影响：

  • 如果你引入了一个没有在测试中发现的错误，那么一次只会影响几个客户端

  • 硬件故障。一台大型服务器翻倒会同时惹恼很多人。拥有故障转移大型服务器非常昂贵。每三到四台正在运行的服务器配备一个备用故障转移盒要便宜得多，而且惹恼的人也更少。

  • 可以在逐个客户端的基础上平衡盒子之间的性能，因此您可以将一些轻量级客户端与重度客户端放在一起，或者只用一些中型客户端填充一个盒子，等等。

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

于 2009-09-14T14:18:19.000 回答
1

我强烈建议您使用贵公司托管的单个实例。这具有以下优点：

  • 您可以物理访问所有代码和数据库以进行更改和更新。
  • 您可以控制运行它的硬件的质量。
  • 当您修复公共代码中的错误时，您已经为所有客户修复了一次。
  • 您可以重构应用程序设计以更好地支持客户特定代码并避免分叉。
  • 随着客户数量的增长，您可以纵向扩展和横向扩展您的服务器以满足性能/响应性要求。
  • “好奇”的客户不能篡改您的应用程序代码和数据库。

我不得不说，与它有多少单独的实例相比，你的应用程序在哪里运行几乎更重要。

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

Joel Spolsky 在StackOverflow 播客 67上也谈到了这一点。

乔尔从销售 Fogbugz 中学到的一件事：设计为安装在客户站点内部服务器上并由该客户完全控制的软件几乎不值得麻烦

2000 万条记录相对来说并不是一个庞大的 SQL Server 数据库。一个配置良好的 SQL Server 可以轻松处理这种大小。然而，更重要的是对数据库的并发访问次数。但是，您说每个客户只有几个用户，因此在并发级别提高之前不太可能打击您。

于 2009-09-14T14:22:02.213 回答
1

以上所有观点都很好，但是您缺少两个关键问题。提供的服务价格是多少？您最终需要支持多少客户（数量级）（即市场规模）？在 3 年内，您将拥有最多 10 个客户，每个客户每年向您支付 500,000 美元，还是有 500 个客户每年向您支付 10,000 美元？对于一小部分高薪高级客户来说，单独部署的优势是显而易见的，而较低的价格和较大的客户群需要共享解决方案（la Oli 的评论）是最好的选择。或者使用云平台，尽管我只阅读了炒作和修补，而不是在现场部署。

奖励问题 1：表布局、索引、读/写次数、存储过程的效率和复杂性（您正在使用 procs 或至少准备好的语句，对吗？）所有这些都比物理记录的数量重要得多数据库到一个点。除此之外，您可能会发现自己需要为每个客户或一组客户提供单独的 SQL Server 实例，这再次取决于我上面提出的一些问题。

额外问题 2：在这种情况下，将时间用于模板和插件架构的设计是必不可少的，您需要尽早而不是稍后进行。一旦您开始为付费客户定制代码，您可能没有时间把它做好。这一点怎么强调都不过分。模板和管理工具可让您快速深入地访问产品中的数据驱动更改，这将为您节省大量时间。随着您的公司/集团的扩展，您可以添加更少的技术人员，他们可以成为“产品专家”，他们可以执行 90% 的定制和维护，从而释放您的核心以继续开发或转移到其他项目。最后，在此规划过程中不要忽视您的数据层。

祝你好运，如果您需要更具体的建议，请随时提供更多详细信息。

于 2009-09-14T14:51:01.760 回答
1

随着每个客户需求的增加，单个实例的最大优势将是横向扩展。例如，如果您在一台服务器上运行，而一个客户突然需要更多性能，那么您就吃不消了。但如果他们都是独立的，那么将客户转移到闪亮的新服务器上相对容易。

最大的缺点是单独管理所有实例。（无论它们是否都在同一台服务器上运行）。

无论如何，您应该只拥有一个代码库实例。并且定制都应该通过插件和配置来控制。前端自然应该与内容分开。尽管进行更改的成本可能更高，但我敢肯定，您可以为其他客户提供的功能（这只是您被要求进行的定制）所带来的好处将得到回报。也就是说，管理单个代码库要比管理多个代码库容易得多。

于 2009-09-14T14:17:37.987 回答
0

根据这里收到的一些建议，我们最终实现了应用程序的单片多租户版本。

我很高兴我们做到了。到完成时，我们已经有了 3 或 4 个代码库的分支（主要是自定义皮肤和我们没有 n 级支持的东西，还有一些实际功能），而且只会变得越来越疯狂。

我们推出了多租户版本并成功地将所有内容都折叠起来。最终有很多事情要考虑，要跟踪很多事情，但我们的客户甚至都不知道他们已经转移到了一个新系统。

我会说，实际的客户迁移有点让人头疼。起初我以为我们可以在后端手动完成，但最终我不得不编写一些相当复杂的脚本来完成这项工作。身份列太多了，当您导入实时制作系统时，您不能暂时关闭约束。

于 2009-12-04T17:04:58.993 回答