您如何在多租户系统中管理可扩展性？

我现在有一些基于Web的大型多租户产品，很快我就会发现会有很多针对租户的自定义设置。

这里或那里的额外字段，可能是工作流程中间的额外页面或某些额外的逻辑-诸如此类。

其中一些自定义项可以纳入核心产品，这很棒。其中一些是非常具体的，并且会妨碍其他人。

我有一些想法可以解决这个问题，但是似乎没有一个很好的扩展。显而易见的解决方案是引入大量的客户端级别设置，从而允许基于每个客户端启用各种“功能”。这样做的缺点当然是庞大的复杂性和混乱性。您可能会引入大量的设置，并且随着时间的流逝，各种类型的逻辑（演示，业务）可能会失控。然后是特定于客户的字段的问题，这比起在现有表中添加一堆可以为空的字段来讨价还价。

那么人们在做什么来管理呢？Force.com似乎是可扩展性的主人。显然，他们已经从头开始创建了一个超级可扩展的平台。您可以使用其基于Web的用户界面添加几乎所有内容。FogBugz做了一些类似的事情，他们创建了一个健壮的插件模型，考虑到它，可能实际上是受Force启发的。我知道他们在上面花了很多时间和金钱，如果我没记错的话，目的是在内部实际使用它来进行未来的产品开发。

听起来像我可能会尝试构建的那种东西，但可能不应该这样做。:)

在可插拔架构上进行大量投资是唯一的方法吗？您如何处理这些问题，并且看到了什么样的结果？

编辑：看起来FogBugz确实通过构建一个相当健壮的平台，然后使用它来组装屏幕来解决了该问题。要扩展它，您将创建一个包含实现ISearchScreenGridColumn之类的接口的类的DLL，该DLL成为一个模块。考虑到他们拥有大量的开发人员，并且他们从事了几个月的开发工作，我确信构建起来非常昂贵，而且它们的表面积可能是我应用程序大小的5％。

现在，我很想知道Force.com是否是处理此问题的正确方法。我是ASP.Net的核心人物，所以这是一个很奇怪的职位。

我遇到了类似的问题，我将告诉您如何解决这个问题。

1. 首先，有一个“核心”库或引擎。正如您已经弄清楚的那样，这基本上可以运行该节目。它处理每个系统通用的事务，从动态呈现表单，用户和帐户管理，角色（您命名，做到）开始。

2. 系统的每个部分都包含在一个模块中。一个模块具有依赖关系（它依赖于其他模块）。例如，“核心”系统具有安全性（用户，组，角色，密码策略），区域设置（翻译，国家/地区，文化），文件存储库，电子邮件等，等等。每个模块都使用xml文件定义自身。xml文件基本上指定了架构，表，计算类，屏幕定义等。如果文件日期已更改，则会在应用程序启动时读取这些内容。

3. 客户特定的模块具有自己的xml文件和自己的DLL。它全部加入其中，并在系统的其余部分中透明地运行。直接使用自定义代码，自定义视图模型将现有的MVC视图替换为自定义视图。

4. 如果客户希望扩展现有功能，则xml / system提供一种方法，我可以从另一个“派生”一个模块。新模块具有所有现有功能，但在新DLL中具有客户的特定要求，并且具有可以进行修改的扩展XML文件。需要注意的是，他们实际上无法删除该系统中的现有字段，但是我们可以扩展它并提供全新的对象和功能。

具有许多版本控制逻辑和要管理的代码层并不能增加您的Web应用程序/站点的价值。它还需要更多的脑力才能了解正在发生的事情，并使您从正在做的事情的核心中分散注意力。

我建议不同。我建议保持简单而不是复杂。

维护一个对每个人都相同的代码库。您添加的每个功能都是所有功能。仅限制项目或存储或某些可量化事物的数量，而不限制功能。之所以要进行量化，是因为要对诸如存储，数据条目数量之类的东西进行量化非常容易编程，并且可以将其应用于少数确实限制用户在应用程序上狂奔的事情。它仅需在添加项时进行编程，而无需执行某些功能逻辑。如果功能与其他功能捆绑在一起怎么办？为此编写代码变得非常复杂。

为了确定答案，我建立了一个针对许多客户的电子商务框架，并且了解了尝试维护其所有特性的艰难方法。我最终打破了链条，并创建了一个单一的管理网站，该网站对电子商务是多租户的。然后，我有了一些网站，这些网站从Web服务调用中提取数据。这使不同技术的不同团队可以为电子商务站点实现特定功能，而我每个月都在相同的基础结构上获得报酬，而我不在乎他们在做什么。我只是用数字来限制用法，而不是功能。它的方式更容易。客户可以选择自己的供应商来构建他们的网站，而我不再参与那些决定。

我还为内容管理SAAS提供订阅服务。这也可以通过使用层来实现，并且如果我愿意，客户端可以添加自己的插件，而我让我的团队为所有插件添加更多功能。

这只是我的经历，经过很长时间将我的头撞到墙上，然后绊倒在更简单的东西上。

如果某些事情总是要针对每个客户而定，请不要为其建立框架。将其分解为最简单的部分，以便框架部分适用于所有对象，然后将其余部分切掉，以便您可以针对个人进行扩展。

我使用的软件产品具有用于用户扩展的其他字段。这些字段的每个数据项都可以键入应用程序主表中的现有行。例如，如果您的软件包含客户，并且每个客户都有一个订单列表，那么可定制数据表将具有一列客户表和订单表的外键，其中只有一个为非空。一个或多个表，每个表都有一个表的自定义字段。

这是一种为用户存储额外数据的简单高效的方法。需要存储有关这些字段的名称和类型的其他信息。

这涵盖了客户的自定义字段。对于自定义行为，Web服务API将允许扩展。

1）在您自己的盒子上运行别人的代码是一个非常棘手的问题。您可以信任他们，也可以合理地推迟责任，您将不得不非常沙盒化他们的代码，并且对安全的奉献要高于平均水平。随着您的插件系统允许更多功能，使其安全的难度也随之增加。拒绝服务（插件消耗太多资源），信息泄漏（插件可以访问其他租户的数据）等事情可能是非常真实且麻烦的事情，除非让人们非常熟悉，否则我不会参与其中。这些问题或非常有能力的人有很多时间来解决问题。

2）是的，模块化和可定制性很难。诸如Strategy模式之类的事情可以提供帮助（函数指针的奇特名称；在Java中，通常是通过声明一个接口，类的用户可以实现该接口来定制代码的行为来实现），但是您将需要非常隔离和分离代码以使其正常工作。

3）在数据方面，这可能是无模式存储有用的示例之一。如果您有一个关系数据模型，那么为不同的客户提供具有很多列的表是有问题的（是的，您最终会得到很多可为空的列，这很糟糕；原因之一是很难或不可能设置正确的约束[即不允许出现无效的无效组合的约束]）。添加特定于客户的表（即users和foo_users，并users保留对所有客户有效的字段并foo_users具有Foo特定的字段）会更好；您可以轻松地拥有正确的约束，但是您的RDBMS可能无法优雅地处理它（由于加入爆炸，表数量限制等），并且在您的代码中看起来很丑陋。

您可能最终会在RDBMS中实现键值存储，这会使您的数据模型不那么具有关系性，并且会引起不适（即关系数据库最适合于具有关系性的模型）。我不确定NoSQL解决方案是否能整体解决问题，但是大多数实现的无模式性可能是一个优势。