通过多个部署和独立模式实现多租户的优缺点



我正在尝试使用Spring mvc创建java web应用程序。此应用程序的目的是为来自企业中不同业务单位的不同用户组提供服务。例如,如果你把它想象成一个购物体验类的应用程序,应用程序的功能是关于

  • 选择你想要的
  • 将您选择的商品添加到购物车
  • 从购物车结账

然后,我需要列出管道部门的管道项目,电气部门的电气项目等等。

因此,我决定使用两个具有相同表结构的不同模式。因此,模式'PLUMB'将存储可以使用该应用程序的管道深度用户,以及PLUMB模式的users和items表中与管道相关的项。同样,电气部门也有自己的模式。这是针对数据库端的多租户。

对于应用程序/部署端,web应用程序的代码保持不变,除了一个属性告诉应用程序需要查询哪个模式(这在每个实例上显然是不同的)。所以,我在考虑部署

  • http://mycompany.com/plumbingapp
  • http://mycompany.com/electricalapp

对于这种架构是否存在已知的反模式?我看到的一个缺点是,我现在将有多个环境来管理-如dev.mycompany.com/plumbingapp和test.mycompany.com/plumbingapp。除此之外,我认为这允许更清晰的分离,而不是让一个应用程序验证用户,然后要求他从他想要去的部门中选择,并根据他选择的部门,我将填充网页。

你以前用过这种结构吗?这种设计/架构有什么已知的缺点吗?如果我部署多个实例,它还是一个多租户应用程序吗?

取决于用户和他的权限,在他登录后,您将创建/plum或/electrical modelAndView。在DB中,除了user table和user_roles之外,可以创建plum_table和elec_table表。另一种方法是创建虚拟机和代理到不同的机器依赖于/plum或/electrical

问题中列出的方法非常适合两个或几个租户。但不容易缩放。

不需要单独的部署包。租户标识和分离只能在DB模式级别、角色和任何业务规则上进行。其余的系统组件可以是通用的。没有必要为每个租户创建一个单独的应用程序。

这些帖子可以提供帮助:

在云上构建企业Web (RIA)应用程序的数据库架构(单个db vs客户端特定的db)

基于SaaS的在线门户架构

最新更新