用于基于Java（GWT、Spring、Hibernate）的web应用程序的SaaS/多租户方法

我目前正在考虑将一个使用Spring、GWT、Hibernate、Jackrabbit、Hibernate Search/Lucene（以及其他）的基于Java的单租户web应用程序转换为一个成熟的SaaS风格的应用程序

我偶然发现了一篇文章，其中强调了以下7个“事项”，它们是对单一租户应用程序进行的重要更改，使其成为SaaS应用程序：

应用程序必须支持多租户

应用程序必须具有一定级别的自助注册

必须建立订阅/计费机制

应用程序必须能够有效地扩展

必须具备监控、配置和管理应用程序和租户的功能

必须有一个机制来支持唯一的用户标识和身份验证

必须有一种机制来支持每个租户的某种程度的定制

我的问题是，是否有人在SaaS/多租户应用程序中使用与我列出的技术类似的技术实现了上述7项功能中的任何一项？在我走上我目前正在考虑的道路之前，我渴望得到尽可能多的关于最佳方式的意见

首先，我非常确信我能够很好地处理模型级别的多租户。我正在考虑将租户ID添加到所有表中，然后使用Hibernate筛选器（以及Hibernate搜索的全文筛选器）根据登录用户的租户ID对所有查询进行筛选

不过，我对业绩也有一些担忧，尤其是当我们的租户数量增长相当高时

---

如果您对如何实现这种解决方案提出任何建议，我们将不胜感激（如果这个问题过于开放，我深表歉意）。

您列出的所有技术对于单租户和多租户应用程序都非常常见和合理。我想说，支持SaaS的7个“东西”更重要的是你如何使用这些技术，而不是使用哪种技术。听起来您已经有了一个可以运行的单租户应用程序。因此，可能没有太多理由偏离那里的技术选择，除非有些东西已经不能很好地工作了。不过，你的问题在其他方面是相当开放的，所以很难再具体化了

不过，我确实有一些关于按租户ID拆分数据库（可能还有其他东西）的反馈。如果你知道你最终可能会有很多租户（比如说几千或更多，特别是如果他们很小的话），那么你的建议可能是最好的。但是，如果你的租户数量较少（特别是如果他们是大的），你可能想考虑每个租户的数据库，所以他们每个都有自己的表空间。我指的是一个数据库安装，其中包含同一模式的多个实例，每个租户一个

这是一个优势，有几个原因。一是你提到的性能。向每个表中添加租户ID会增加磁盘访问、查询时间和代码复杂性方面的开销。数据库中的每个索引也需要包含租户ID。如果不小心的话，您将面临在租户之间混合数据的额外风险（尽管Hibernate过滤器有助于缓解这一风险）。使用每个租户的数据库，您可以将访问权限限制为仅正确的一个。移植您当前的应用程序可能也会容易得多，您基本上只需要提前在某处拦截您的请求，以便根据URL确定租户并指向正确的数据库。每个租户也可以轻松地进行备份，如果您打算让他们下载备份，备份尤其有用

另一方面，有理由不这样做。您将有许多数据库模式需要处理，并且它们必须独立更新（如果您不想让所有租户都参与模式更改，这实际上是一个优势，您可以以增量方式将它们推出）。它允许您遇到一些特殊情况，这些情况可能与将平台视为一次升级的真正多租户SaaS部署不同，从而导致在生产中管理多个版本。最后，我听说几乎每个数据库供应商在一次安装中支持的模式实例数量上都有一个突破点（据说有些可能达到数十万）

---

当然，这取决于您的用例。你提到了单一租户，这让我相信你现在没有太多的租户，但是你提到了越来越多的租户。我不确定你指的是成百上千万，但不管怎样，我希望这对你的考虑有所帮助。祝你好运

我建议您设计应用程序，以支持所有4种租户隔离类型，即每个租户的独立数据库、每个租户的独立架构、每个租户的独立表和所有租户的共享表，并提供租户ID。这将使您能够灵活地在成长过程中对数据库进行水平分区，拥有多个数据库，每个数据库都有一组较小的租户，并且能够为一些大型租户提供单独的数据库。您的一些大型租户也可以坚持他们的数据（数据库）应该驻留在他们的房屋中，而应用程序可以脱离云端运行

这是一个非功能性和基础设施级别的检查列表，在构建应用程序时，你可能需要考虑这些（其中一些可能不需要立即考虑，但如果你的竞争对手开始提供它的话，你将如何处理这样的需求）

租户级定制a）UI主题和徽标b）表单和网格，c）数据模型扩展和自定义字段，d）通知模板，e）提货清单和主数据

租户级创建和ad