基于Java (GWT、Spring、Hibernate)的SaaS /多租户方法

Question

我目前正在考虑将一个基于Java的单租户web应用程序转换为一个成熟的SaaS风格应用程序，该应用程序使用Spring、GWT、Hibernate、Jack兔子、Hibernate Search / Lucene (等等)。

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

1. 应用程序必须支持多租户。
2. 应用程序必须有某种级别的自助服务注册。
3. 必须建立订阅/计费机制。
4. 应用程序必须能够有效地扩展。
5. 必须有相应的功能来监视、配置和管理应用程序和租户。
6. 必须有一种机制来支持唯一的用户标识和身份验证。
7. 必须有一种机制来支持每个租户的某种程度的自定义。

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

首先，我确信我对如何在模型级别处理多个租户有很好的处理能力。我正在考虑将一个租户ID添加到我们的所有表中，然后使用Hibernate过滤器(以及Hibernate搜索的完整文本过滤器)对所有查询使用登录用户的租户ID进行筛选。

然而，我对性能也有一些担忧，特别是当我们的租户数量增长相当高的时候。

任何关于如何实施这样一种解决方案的建议都会受到极大的赞赏(如果这个问题有点过于开放的话，我很抱歉)。

Answer 1

我建议您设计您的应用程序来支持所有4种类型的租户隔离，即每个租户的单独数据库、每个租户的单独模式、每个租户的单独表和所有租户ID的共享表。这将使您可以灵活地随着您的成长而水平地划分您的数据库，有多个数据库，每个数据库都有一组较小的租户，还可以为一些大租户创建一个单独的数据库。您的一些大型租户还可以坚持他们的数据(数据库)应该驻留在他们的前提中，而应用程序可以在云上运行。

下面列出了一些非功能和基础设施级别的特性，您可能希望在构建应用程序时考虑这些特性(其中有些功能和基础结构特性您可能不需要立即考虑，但是如果您的竞争对手开始提供这些功能和基础设施级别的功能，您可以考虑一下如何处理这些需求)。

1. 租户级自定义( a) UI主题和徽标b)表单和网格，c)数据模型扩展和自定义字段，d)通知模板，e)获取列表和主数据
2. 租户级别创建和管理角色和权限、字段级访问权限、数据范围策略
3. 租户级别的模块和功能访问控制设置，以便可以根据订阅包启用/禁用特定模块和功能。
4. 一旦超出采购配额，就测量和监视任务/事件/事务，并限制访问控制。当您的业务模式发生变化时，您能够在将来度量任何新的实体。
5. 将业务规则和工作流从代码库中外部化，并将它们表示为元数据，这样您就可以为每个租户组/租户定制它们。
6. 查询生成器，用于创建了解租户的自定义报表以及特定租户添加的自定义字段。
7. 租户封装和框架级连接字符串管理，这样您的开发人员在编写查询时不必担心租户ID。

所有这些都是基于我们在构建通用多租户框架方面的经验，该框架可以用于任何领域或应用程序。不幸的是，您不能使用我们的框架，因为它是基于.NET的

但是，无论您使用什么技术栈，任何多租户SaaS产品(新的或迁移的)的工程需求都是相同的。

Answer 2

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

不过，对于按租户ID拆分数据库(可能还有其他事情)，我确实有一些反馈。如果你知道你最终可能会有很多房客(比如说几千人或更多人，尤其是他们很小的话)，那么你建议的也许是最好的。但是，如果租户数量较少(特别是较大的租户)，则可能需要考虑每个租户的数据库，因此每个租户都有自己的表空间。我指的是一个数据库安装，其中包含同一个模式的多个实例，每个租户一个。

有几个原因，这可能是一个优势。一个是你提到的表演。在每个表中添加一个租户ID会增加磁盘访问、查询时间和增加代码复杂性的开销。数据库中的每个索引也需要包括租户ID。如果您不小心，那么在租户之间混合数据会带来额外的风险(尽管Hibernate过滤器有助于减轻这种风险)。对于每个租户都有一个数据库，您可以限制对正确数据库的访问。移植当前的应用程序可能也要容易得多，基本上，您只需要在某个地方拦截您的请求，就可以根据URL决定租户并指向正确的数据库。对于每个租户来说，备份也很容易完成，如果您打算允许它们下载备份的话，那么备份尤其有用。

另一方面，我们也有理由不这样做。您将需要处理许多数据库模式，并且必须独立地更新它们(如果您希望避免在模式更改时让所有租户下来，这实际上是一种优势，您可以逐步推出它们)。它允许您有一些特殊情况，这些特殊情况可能会偏离将平台作为一个真正的多租户SaaS部署来对待的问题，这种部署会同时升级，从而导致生产中的多个版本的管理。最后，我听说，几乎每个数据库供应商在一次安装中所支持的模式实例数量上都有一个临界点(据说有些可以达到几十万)。

当然，这取决于您的用例。你提到了单租户，这让我相信你现在没有太多的房客，但是你确实提到了很多租户的成长。我不确定你指的是上亿还是数百万，但我希望这能帮助一些人解决你的问题。祝你好运！

Answer 3

没有简单的答案。我可以描述我自己的解决方案。它可能会给其他人带来灵感。

• 每个数据库的租户(postgres)
• 租户之间共享的另一个数据库
• 弹簧+ MyBatis
• 弹簧安全认证

详细信息：http://blog.trixi.cz/2012/01/multitenancy-using-spring-and-postgresql/