如何实现“共享数据库,分离模式”多租户策略

发布于 2024-09-11 13:19:26 字数 252 浏览 8 评论 0原文

我必须使用共享数据库单独模式方法来启用多租户 Web 应用程序。该应用程序是使用 Java/J2EE 和 Oracle 10g 构建的。

我需要一个应用程序服务器,使用具有多个架构的共享数据库,每个客户端一个架构。

实现这一目标的最佳实施方法是什么?

  • 中间层(应用程序服务器)级别需要做什么?
  • 每个客户端是否需要有多个主机标头?
  • 如何根据访问应用程序的客户端动态连接到正确的架构?

I have to make a web application multi-tenant enabled using Shared database separate schema approach. The application is built using Java/J2EE and Oracle 10g.

I need to have one single appserver using a shared database with multiple schema, one schema per client.

What is the best implementation approach to achieve this?

  • What needs to be done at the middle tier (app-server) level?
  • Do I need to have multiple host headers each per client?
  • How can I connect to the correct schema dynamically based on the client who is accessing the application?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

熊抱啵儿 2024-09-18 13:19:26

在较高层面上,以下是一些需要考虑的事项:

  • 您可能希望在日常开发中隐藏租赁注意事项。因此,您可能希望尽可能将其隐藏在基础设施中,并将其与业务逻辑分开。您不想总是检查您是否处于哪个租户的上下文中......您只想处于该上下文中。
  • 如果您使用工作单元模式,您将需要确保任何工作单元(除了在纯基础设施上下文中而不是在业务上下文中运行的工作单元)都在一个租户的上下文中执行。如果您没有使用工作单元模式......也许您应该使用。不确定您将如何遵循上述建议(尽管也许您能够找到一种方法)。
  • 您可能希望将租户 ID 放入每个消息或 HTTP 请求的标头中。原则上最好将其排除在主体之外,以使其远离业务逻辑。您可以在幕后将其删除,并确保在幕后将其放在任何传出的消息/请求中。
  • 我不熟悉 Oracle,但在 SQL Server 中,我相信在 Postgres 中,您可以使用模拟作为切换租户的方式。也就是说,您不必在每个 SQL 命令和查询中参数化架构,而是可以只让一个 SQL 用户(没有关联的登录名)将关联租户的架构作为其默认架构,然后将该架构排除在外。您的日常 SQL。您必须拦截对数据库的调用并将它们包装在模拟调用中。就像我说的,我不太确定这在 Oracle 中是如何实现的,但这是 SQL Server 的总体思路。
  • 身份验证和安全性是这里的一个大问题。这远远超出了我在这个答案中可以讨论的范围,但请确保你得到了正确的

At a high level, here are some things to consider:

  • You probably want to hide the tenancy considerations from day-to-day development. Thus, you will probably want to hide it away in your infrastructure as much as possible and keep it separate from your business logic. You don't want to be always checking whether which tenant's context you are in... you just want to be in that context.
  • If you are using a unit of work pattern, you will want to make sure that any unit of work (except one that is operating in a purely infrastructure context, not in a business context) executes in the context of exactly one tenant. If you are not using the unit of work pattern... maybe you should be. Not sure how else you are going to follow the advice in the point above (though maybe you will be able to figure out a way).
  • You probably want to put a tenant ID into the header of every messaging or HTTP request. Probably better to keep this out of the body on principle of keeping it away from business logic. You can scrape this off behind the scenes and make sure that behind the scenes it gets put on any outgoing messages/requests.
  • I am not familiar with Oracle, but in SQL Server and I believe in Postgres you can use impersonation as a way of switching tenants. That is to say, rather than parameterizing the schema in every SQL command and query, you can just have one SQL user (without an associated login) that has the schema for the associated tenant as its default schema, and then leave the schema out of your day-to-day SQL. You will have to intercept calls to the database and wrap them in an impersonation call. Like I say, I'm not exactly sure how this works out in Oracle, but that's the general idea for SQL Server.
  • Authentication and security are a big concern here. That is far beyond the scope of what I can discuss in this answer but make sure you get that right.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文