architecture - 使用共享凭据的具有多个客户实例的 Multi-Tenancy 应用

Question

我在SO和其他景点附近搜寻了有关如何执行此操作的帮助。我看到许多建议不要这样做的人，但是我有合理和简单的理由使客户愿意这样做。

所以这是我想要做的:

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

设计非常简单，有一个Tenant对象，该对象将具有用户集合和实例集合。将有一个附加的交叉引用对象，该对象将授权用户访问特定实例。例如，我可能只允许大多数租户用户访问生产实例，但对于系统管理员，他们将拥有对所有实例的完全访问权限。

我挂断的部分是:

跨所有实例存储的用户信息实际上应该只包含诸如用户名和密码之类的基本信息，因为诸如名称，电话号码等详细信息应全部驻留在实例特定的数据库中。更重要的是，在每种情况下，用户将与另一个实体(雇员，人员或联系人)建立一对多关系。

然后我的问题变成:

根据设计，我有什么最简单的方法可以跨模型(框架，实例)链接对象(用户和员工)？更重要的是，如何在所有实例之间保持数据更改或修改同步，还是我应该为此担心？

任何人都可以提供任何反馈，我将不胜感激，尤其是如果您已经解决了此类问题或具有此类模型的经验，则尤其如此。我对现有设计非常满意，因为它必须以这种方式工作才能满足客户需求，我需要使技术适应需求。

感谢您的专业知识!

布伦特

Answer 1

听起来好像这里有三件事相互联系，尽管问题只涉及一个问题:

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

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

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

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

如何将数据存储在数据库中？

由于每个应用程序的每个租户实例都有一个数据库(每个“环境”(生产，测试等都是一个租户实例))，并且您拥有与所有数据库有关的数据，因此我将存储“公共”数据在一个单独的数据库中。

让我们将该数据库称为SystemConfiguration数据库。这样，您将拥有:

系统中所有租户的列表。

每个实例的全局配置设置(例如数据库名称，服务端点等)的列表，每个实例都映射到一个租户。

系统中所有用户的列表，每个用户都映射到一个租户(假设单个用户不能跨租户...这可能很复杂，但并非不可能)。

用户到每个用户有权访问的每个实例的ID的映射。

将此SystemConfiguration数据库单独拆分意味着您不必尝试在任何地方保持公共用户信息的同步。如果存在每个实例的用户信息(例如，用户设置等)，则该信息将进入实例数据库，但名称，密码哈希等将全部进入该中央数据库。

从技术上讲，您可以用其他方式对它进行分区，例如也有一个单独的用户数据库，并且仅将租户/系统配置保留在SystemConfiguration数据库中，但这至少可以为您提供思路。

如果租户决定离开，则可以很容易地查询出与特定租户有关的任何信息，并将其从SystemConfiguration数据库中导出。与实例数据库中特定于租户的数据相比，应该没有很多。

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

我认为基于声明的身份验证/授权将使此问题更加简单。如果您不熟悉声明，那么您的想法是，与其拥有一个用户所在的静态“角色”列表，不如拥有一个与每个用户相关联的名称/值对字典。词典是用户的“声明集”，每个名称/值对都是“声明”。相对于角色的好处是，值可以是任何值，包括列表。

通过身份验证的用户将获得一系列声明，包括他们的用户名，名字/姓氏以及他们有权访问的实例列表。

之后，只需根据当前实例的ID检查用户的声明即可。如果通过身份验证的用户无权访问该实例，请阻止他们。

将其带回数据存储-从该SystemConfiguration数据库生成声明集将是一个简单的查询。

有关基于声明的身份以及如何使用Windows Identity Foundation使其在您的应用程序中正常工作的更多信息，请查看 Programming Windows Identity Foundation by Vittorio Bertocci。这是一本好书...而且几乎是WIF上唯一的书。

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

在这一点上，更多的是关于您想要从代码中查看数据的视图，而不是数据存储结构。如果您希望租户对象中包含IEnumerable ，则只不过与您选择的ORM无关。

我可能建议使用服务协定至少在SystemConfiguration数据库周围包装操作，因此，如果您更改其下的数据，则可以在服务层而不是使用代码中调整ORM。接口!

无论如何，这里的要点是我不会尝试将数据存储必然基于您使用数据的方式。

最后，如果您在实例中需要用户或租户信息，最终将使某些查询与SystemConfiguration数据库对话，而某些查询与Tenant-instance数据库对话。没关系。只要对所有内容都使用全局唯一标识符，就可以通过ID将用户从一个数据库绑定到另一个数据库中的某个设置或值。引用完整性很难维护，但是比在多个实例数据库中维护数据同步要容易。

这可能是将内容包装在服务中的另一个原因。例如，如果您具有“UserSettings”服务，则合同可能会要求提供承租人实例ID和用户ID，然后返回设置列表。在后台，该服务可以从SystemConfiguration查询数据，将其映射到适当的实例数据库，然后返回合并的数据集-所有这些对于调用代码都是透明的。另一方面，当您仅更改对象上的值并要提交更改时，您不会得到某些ORM所提供的“Update()”方法。在是否要让ORM达到合规性以实现此目标方面，这是一个折衷方案。