基于Java(GWT,Spring,Hibernate)Web应用程序的SaaS /多租户方法

Question

我目前正在考虑将使用Spring,GWT,Hibernate,Jackrabbit,Hibernate Search/Lucene(以及其他)的单租户基于Java的Web应用程序转换为完全成熟的SaaS风格应用程序.

我偶然发现了一篇文章,其中强调了以下7个"事物"作为对单个租户应用程序进行重要更改以使其成为SaaS应用程序:

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

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

作为一个开始,我很确定我能够很好地处理如何在模型级别处理多个租户.我正在考虑为所有表添加租户ID,然后使用Hibernate过滤器(以及Hibernate Search的全文过滤器)根据登录用户的所有查询的租户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 部署，从而在生产中管理多个版本。最后，我听说几乎每个数据库供应商在一次安装中支持的模式实例数量都存在一个突破点（据推测有些可能会达到数十万个）。

当然，这实际上取决于您的用例。您提到了单一租户，这让我相信您现在没有太多租户，但您确实提到了要增加很多租户。我不确定你的意思是数百还是数百万，但无论哪种方式，我希望这对你的考虑有所帮助。祝你好运！