通过多重部署和独立模式实现多租户的利弊
我正在尝试使用Spring mvc创建一个java web应用程序。此应用程序的目的是为企业中不同业务部门的不同用户组提供服务。举个例子，如果你认为它是一种购物体验类的应用程序，那么这个应用程序在功能上是关于
- 挑选你想要的
然后，我需要列出管道部门的管道项目，电气部门的电气项目等等。
所以，我决定使用两个具有相同表结构的不同模式。所以模式“PLUMB”将存储可以使用应用程序的管道部门用户，以及与管道相关的项目，在PLUMB模式的USERS和ITEMS表中。同样，电气部门也有自己的模式。这是为了数据库端的多租户。
对于应用程序/部署端，webapp的代码保持不变，除了一个属性告诉应用程序它需要查询哪个模式（这在每个实例上都明显不同）。所以，我正在考虑部署
- http://mycompany.com/plumbingapp
- http://mycompany.com/electricalapp
这种架构是否存在已知的反模式？我看到一个不利的一面是，我现在将有多个环境需要管理——比如dev.mycompany。com/plumbingapp和测试。我的公司。com/plumbingapp。除此之外，我认为这允许更干净的分离，而不是有一个单一的应用程序验证用户，然后让他选择他想去哪个部门，根据他选择的部门，我会填充网页。
你以前用过这种结构吗？这种设计/架构有哪些已知的缺点？如果我部署了多个实例，它还会是多租户应用程序吗？
共有2个答案
问题所列的方法非常适合两个或几个租户。但不容易扩展。
不需要单独的部署包。租户标识和分离只能在DB模式级别、角色和任何业务规则上进行。其余的系统组件可以是通用的。没有理由为每个租户创建单独的应用程序。
这些帖子可以帮助：
用于在云上构建企业Web（RIA）应用程序的数据库体系结构（单db vs客户端特定db）
基于SaaS的在线门户的体系结构
根据用户和他的权限，在他登录后，您将创建 /plum或 /electrical模型和视图。在您的数据库中，您可以创建plum_table和elec_table的表，除了用户表和user_roles。另一种方法是根据 /plum或 /electrical创建虚拟机和代理到不同的机器
-
单机部署 要在单台机器上托管多个租户，为每个租户运行一个MinIO server,使用不同的HTTPS端口、配置和数据目录。 示例1：单主机，单磁盘 以下示例在一块磁盘上托管三个租户。 minio --config-dir ~/tenant1 server --address :9001 /data/tenant1 minio --config-dir ~/tenant2 server --add
-
我正在构建一个应用程序，它应该服务于多个租户，并存储他们非常敏感的数据。每个租户都有多个用户。我的后端堆栈是用spring boot Hibernate5构建的。我希望hibernate处理多租户问题，所以我有两个问题要问专家： 如果我使用的是每租户模式范式，如何在登录时将用户名与租户关联？每个租户都有自己的用户表，那么我如何知道用户名属于哪个租户呢？ 在注册时，什么是正确的方法来动态创建新模式？
-
任何帮助都将真正用于如何实现这一目标。 我目前有三个独立的应用程序，两个前端运行vue.js和一个后端应用程序，与laravel租赁，只服务于API的，没有前端。 主基URL或后端URL设置为example。com，这是租赁申请。它会自动生成URL子域。实例为租户提供的com 另一个安全域设置。实例com指向我们注册的另一个vue应用程序。效果非常好。 现在我在vue上有了第三个应用程序。js，对
-
独立部署即为在后端运行程序，让程序跑在后台。 linux 在 linux 下面部署，我们可以利用 nohup 命令，把应用部署在后端，如下所示： nohup ./beepkg & 这样你的应用就跑在了 Linux 系统的守护进程 Windows 在 Windows 系统中，设置开机自动，后台运行，有如下几种方式： 制作 bat 文件，放在“启动”里面 制作成服务
-
如何使用django租户模式将数据从共享模式迁移到多租户模式？ 我们有一个saas，最初没有使用django租户模式，而是使用共享数据库、共享模式的方法。我们现在发现了django租户模式，并认为这是正确的选择。 现在的问题是如何将数据从单一的模式迁移到独立的租户模式。 文档说明如下： 注意：如果这是您第一次运行此命令，您的数据库应该是空的。 在我现有的应用程序中，我有一个租户表，所有其他模型都有
-
我正在学习多租户应用程序，以及如何使用PostgreSQL的模式来实现这一点。 在研究这个主题时，我发现了一篇文章，作者描述了在多租户应用程序中使用PostgreSQL模式时的糟糕体验。主要问题是迁移性能差和数据库资源使用率高。 似乎只有一个模式（在租户之间共享表）会比每个租户有一个单独的模式带来更好的性能。但我觉得很奇怪。我的想法正好相反，因为较小表上的索引往往比较大表上的索引轻。 为什么在许多