使用SQL / WCF / Silverlight进行多租户

Question

我们正在构建一个将以SaaS形式提供的Silverlight应用程序。 最终产品是连接到WCF服务的Silverlight客户端。 由于客户端的数量可能很大，因此更新需要很容易，最好是一次可以更新所有实例。

之前没有实施多租户，我正在寻找有关如何实现多租户的意见

• 轻松升级
• 数据安全
• 可扩展性

msdn上列出了要考虑的三种不同模型

1. 单独的数据库。 这很不容易维护，因为所有架构更改都必须分别应用于每个客户的数据库。 还有其他缺点吗？ 优点是数据分离和安全性。 这还允许对每个客户进行轻微的修改（这可能比它的价值还要麻烦！）
2. 共享数据库，单独的架构。 将TenantID列添加到每个表。 确保每个客户获取正确的数据都是潜在的危险。 易于维护，扩展性好（？）。
3. 共享数据库，单独的架构。 与第一个模型相似，但是每个客户在数据库中都有自己的一组表。 难以为单个客户恢复备份。 其他方面的可维护性类似于模型1（？）。

关于该主题的文章有什么建议吗？ 有人使用Silverlight SaaS应用程序探索过类似的东西吗？ 我需要在客户端考虑什么？

Answer 1

我有类似的情况，但我的解决方案是同时利用两者。

数据在哪里以及如何放置是租户的问题。 作为租户，我当然不希望共享数据，我希望数据隔离，安全并且我可以随时获取。

它可能共享的某些数据，例如：公司列表。 因此数据库应该是全局和租户数据库，只需确保锁定了操作的租户数据库架构，并立即更新所有租户数据库的过程即可。

无论如何，SaaS都将以服务器/ Web服务形式交付的所有内容建模，因此无论将数据库作为服务提供给客户端的位置如何，都只能通过客户端GUI进行呈现。

谢谢

Answer 2

取决于应用程序的类型和数据规模。 每个人都有失败。

1a）单独的数据库+ WCF /客户端的单个实例。 保持一切同步将是一个挑战。 您如何同时升级X台数据库服务器，如果一台服务器出现故障，现在不同步并且与客户端/ WCF层不兼容，该怎么办？

1b）“ Silos”，为每个客户单独分配DB / WCF / Client。 您没有同步问题，但确实有管理每个图层的许多不同实例的开销。 另外，您还必须查看SQL许可，我不记得是否单独的SQL实例是单独许可的（$$$）。 即使您可以安装所需数量的实例，多个实例的开销在特定时间点之后也不是小事。

3）除许可外，与1a / b基本相同。

2）最佳升级/管理方案。 正确的是，保持数据隔离是一个巨大的问题（1a从技术上讲在更高级别上具有此问题）。 另一个问题是，如果您的应用程序是数据密集型的，则必须担心数据可伸缩性。 例如，如果期望每个客户拥有数以千万计的数据行。 然后，由于总的客户群数量，您将开始遇到问题并查询单个客户的性能。 客户端对于自己的数据量导致的速度下降更为宽容。 由于其他99个客户端数据很大而被告知缓慢，通常是不可行的。

除非您知道一个事实，否则从一开始就将要处理大量数据，我现在可能会选择＃2，并开始考虑集群化，或者如果将来需要的话，转向1a / b设置。

Answer 3

我们也有SaaS产品，我们使用解决方案2（带有TenandId的共享数据库/共享架构）。 所有共享数据库/相同架构要考虑的一些事项：

1. 如上所述，如果您不小心，一个租户的大量数据可能会影响其他租户的性能。 对于初学者来说，正确/仔细地索引您的表，永远不要执行强制执行表扫描的查询。 监视查询性能，至少规划/设计，以便以后根据对您的域有意义的一些标准对数据库进行分区。

2. 数据分离非常重要，您不希望最终向属于其他租户的某个租户显示一条数据。 每个查询中都必须包含WHERE TenandId = ...，并且您应该能够在开发过程中验证/强制执行此操作。

3. 解决方案1和3可能会为模式提供可扩展性，但是您可以通过设计一种方法来扩展与域中有意义的文档/表相关联的字段（例如，表的元数据为msdn文章提到）

Answer 4

提供像Apprenda的SaaSGrid这样的现成架构的解决方案呢？ 它们使您可以在部署和维护时而不是设计时做出数据库决策。 他们似乎在积极地转换和管理数据层，并提供升级引擎。

Answer 5

现有的答案是好的。 您应该深入研究升级和管理多个数据库的问题。 在不知道特定应用程序的情况下，拥有多个数据库可能会更容易，而不必支付跟踪TenantID的额外费用。 这可能最终不是正确的决定，但是您一定要警惕数据共享的开发成本。