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

Question

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

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

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

msdn 列出了三种不同的模型供您考虑

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

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

Answer 1

取决于应用类型和数据规模。每一个都有缺点。

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

1b) “孤岛”，为每个客户单独的 DB/WCF/Client。您没有同步问题，但您确实有管理每一层的许多不同实例的开销。此外，您将不得不查看 SQL 许可，我不记得单独的 SQL 实例是否单独许可（$$$）。即使您可以安装任意数量的实例，多个实例的开销在某一点之后也不会是微不足道的。

3) 与 1a/b 基本相同的问题，除了许可。

2) 最佳升级/管理方案。你是对的，维护数据隔离是一个巨大的问题（1a 在技术上在更高级别上分享了这个问题）。另一个问题是，如果您的应用程序是数据密集型的，您必须担心数据的可伸缩性。例如，如果每个客户都预计拥有数千万/亿行数据。然后，由于总客户群数量，您将开始遇到个别客户的问题和查询性能。客户对他们自己的数据量造成的减速更加宽容。由于其他 99 个客户数据量大而被告知其速度缓慢通常是不行的。

除非您从一开始就知道您将处理大量数据，否则我现在可能会选择 #2，然后开始考虑集群或在将来需要时迁移到 1a/b 设置。

Answer 2

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

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

2. 数据分离非常非常重要，您不希望最终将一条数据显示给属于其他租户的某个租户。每个查询都必须有一个 WHERE TenandId = ... 在其中，您应该能够在开发期间验证/强制执行。

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

Answer 3

像 Apprenda 的 SaaSGrid 这样提供开箱即用架构的解决方案呢？它们让您在部署和维护时而不是在设计时做出数据库决策。看来他们积极改造和管理数据层，并提供升级引擎。

Answer 4

我有类似的情况，但我的解决方案是两者兼得。

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

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

无论如何，SaaS 模型将所有内容都作为服务器/Web 服务交付，因此无论数据库应作为服务提供给客户端的何处，都只能通过客户端 GUI 呈现。

谢谢

Answer 5

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