Bri*_*Kay 5 asp.net scaling multi-tenant
我们为一个客户编写的Web应用程序将被产品化并出售给数十家公司,我们将进行托管.
我可以使用一些关于为每个客户推出单独实例与使用单个(或非常少数)多租户实例的优缺点的指导.
首先,随着我们的提升,我将不得不为每个新客户推出一个单独的应用程序实例(它们将一次上线一个),因为它是唯一的直接选项.我认为,就维护而言,这不会很好地扩展 - 一旦有超过4或5个实例,推出更改将变得非常繁琐并且可能容易出错.除非我们以某种方式自动化.
此外,如果人们需要自定义,单实例哲学似乎可能导致一堆分叉.避免这种情况会很好.
那你有什么经验呢？
奖金问题#1: 10个记录每个记录2m的SQL Server与20m记录的巨大记录之间的性能差异是什么？假设它们都在一个表中,我们主要在单个记录上进行插入和选择.有时,选择位于索引的varchar(12)或日期字段上.
奖金问题#2:我想,为避免分叉,我们必须使自定义可配置,或构建插件架构.但是,这可能会增加进行自定义的成本,而且我不想成为需要一周时间来调整文本框大小的商店之一,而且我不想过度投资基础架构.有什么想法吗？
比例细节
每个客户将拥有相当数量的数据 - 高达数百万条记录.
将会有非常少量的并发用户,每个客户只有少数用户,以及我们最终的少数内部代表.
目前还不清楚每个客户是否需要定制,但我想其中一些可能会定制,也许其中一些变化将是其他客户不希望看到的东西.
我认为您的两个选择都没有充分的理由。我认为真正的答案位于中间的某个地方：拥有多个实例，每个实例托管多个客户端。
这增加了另一层自动化处理，但这意味着您可以保持托管便宜（您不需要很快出去购买 Cray）并且（希望）这种心态意味着您可以相当轻松地进行故障转移备份。
但我们不要超前...我们正在谈论一个网络应用程序，对吧？在不同的机器上获取数据库和 aspnet。集群您的数据库，您将在各种前端场景中度过更愉快的时光。您还可以升级最先耗尽烟气的区域。
听起来，您最终将得到一个集群数据库，超过一半（甚至是一打数据库机器）和几个前端设备。
至于定制，你已经搞定了。您要么提供一组完全由数据库托管的可编辑模板，要么必须自定义 who 实例。我完全赞成第一。这是一项繁重的工作（没有太多回报），但这是非常值得的，因为您只需要在（您会！）进行升级时更改核心代码。搜寻一百个客户的自定义实例以确保它们安全升级将会杀死开发人员！模板就是答案。至少，您可以轻松地允许自定义 CSS（但他们需要了解其知识的人）。
编辑：我看过几篇关于一体化方法的帖子。将实例拆分到多台机器上可以使您免受以下几件事的影响：
如果您引入了测试中未发现的错误，则只有少数客户端会同时受到影响
硬件故障。一台大型服务器崩溃会立即惹恼很多人。拥有一台故障转移大型服务器非常昂贵。每三到四台正在运行的服务器配备一个备用故障转移盒会便宜得多，而且会减少人的烦恼。
可以在每个客户端的基础上平衡各个盒子之间的性能，因此您可以将一些轻度使用的客户端与重型客户端放在一起，或者只用一些中等使用的客户端填充一个盒子，等等。
同样的想法，使用高峰或其他放缓只会影响同一盒子上的客户端。当然，这对于数据库来说并不意味着相同，但是当您到达那里时，您可以将其拆分为一个集群。