Architecture 使用共享凭据的具有多个客户实例的多租户应用程序

我已经在某处和其他地方寻找帮助，想知道我该怎么做。我看到许多人建议不要这样做，但我有正当和简单的理由，为什么客户会想这样做

所以我想做的是：

我有一个多租户应用程序，它有一个通用框架，用于管理应用程序的多租户方面，如数据存储位置等。每个租户都有“x”个用户，可以访问租户的帐户。但是，每个租户可以将多个实例绑定到其帐户。例如，租户可能有一个生产实例和一个测试或开发实例。每个实例都与一个独立的数据库有一对一的关系。对我来说，最有意义的是，我将根据租户信息在框架级别存储登录凭据，而不是在每个实例中，因为这将使用户名和密码的数量成倍增加

设计相当简单，有一个租户对象，它将有一个用户集合和一个实例集合。将有一个额外的交叉引用对象，它将授权用户访问特定实例。例如，我可能只允许大多数租户用户访问生产实例，但对于系统管理员，他们可以完全访问所有实例

我挂断的部分是：

存储在所有实例中的用户信息实际上应该只包含用户名和密码等基本信息，因为名称、电话号码等详细信息都应该驻留在特定于实例的数据库中。更重要的是，在每个实例中，用户将与另一个实体建立一对多的关系，无论是员工、个人还是联系人对象

我的问题变成：

根据设计，我知道在模型（框架、实例）中链接对象（用户和员工）的最简单方法是什么？更重要的是，我如何在所有实例中保持数据更改或修改的同步，或者我是否应该担心这一点

我非常感谢任何人能提供的反馈，特别是如果你已经解决了这样的问题，或者有过这种型号的经验。我非常关注现有的设计，因为它必须以这种方式工作以满足客户的需求，我需要使技术满足需求

谢谢你的专业知识

---

布伦特重写：

[看起来我的原始答案偏离了目标，而且这与你的答案大致相同。所以…]

如何在所有实例中保持数据更改或修改的同步，或者我甚至应该担心这一点

您是否有要求保持它们同步的要求，或者其他驱动程序？如果不是。。。 假设你这样做了，你需要决定你要同步什么；真相的唯一来源是什么

一个或类型的方法可能是你所追求的

• 实例将更改“发布”到中心系统，其他实例在其正常生命周期内或根据中心系统发布的事件/通知临时获取这些更改
• 或者是一种类似但分散的方法，在这种方法中，变化会立即传播给所有相关方（我认为这要困难得多，而且会出现一系列新的问题）

---

听起来这里有三个相互关联的东西，尽管问题只围绕一个：

数据是如何存储在数据库中的

如何确保每个用户只能访问他们有权访问的实例

如何将数据映射到对象以便在代码中使用

可能有几种方法可以解决每个问题，但以下是我要做的：

数据是如何存储在数据库中的？

由于应用程序的每个租户实例都有一个数据库（每个“环境”-生产、测试等都是租户实例），并且您有属于所有租户实例的数据，所以我也会将“公共”数据存储在单独的数据库中

让我们将该数据库称为SystemConfiguration数据库。在这种情况下，您将：

• 系统中所有租户的列表
• 每个实例的全局配置设置（例如，数据库名称、服务端点等）的列表，每个实例映射到租户
• 系统中所有用户的列表，每个用户映射到一个租户（假设单个用户不能跨租户…这可能很复杂，但并非不可能）
• 用户到每个用户有权访问的每个实例的ID的映射

将此SystemConfiguration数据库作为自己的东西分离意味着您不必在任何地方尝试保持公共用户信息同步。如果存在每个实例的用户信息（例如，用户设置或其他信息），则会进入实例数据库，但名称、密码哈希等都会进入该中心数据库

从技术上讲，您可以用其他方式对此进行分区，比如也有一个单独的用户数据库，并且只在SystemConfiguration数据库中保留租户/系统配置，但这至少让您有了这样的想法

如果租户决定离开，查询出与特定租户相关的任何信息并将其从SystemConfiguration数据库导出将非常容易。与实例数据库中特定于租户的数据量相比，不应该有太多

如何确保每个用户只能访问他们有权访问的实例？

我认为基于声明的身份验证/授权会使这个问题简单得多。如果您不熟悉声明，那么您的想法是，与其拥有用户所处“角色”的静态列表，不如拥有与每个用户关联的名称/值对字典。字典是用户的“