多租户是互动的正确方式吗

Question

我正在进行一个项目，该项目被设置为多租户、独立用户、数据存储等。然而，当我深入研究不同的场景时，我看到了一些可能与多租户（至少是我所理解的）结合不好的东西。

租户可以是等级制的

• A公司
  • 西部地区
  • 东部地区
  • A校区
  • B校区

  租户可以向其他资源提供资源

  • A公司创建一个资源
  • A公司以指定权限与B公司共享
  • C公司与B公司共享资源
  • B公司现在可以使用A公司和C公司提供的资源

  我不喜欢多租户，但我想确保无论我选择什么模式，我都遵循该模式的最佳实践。

  层级式多租户的定义是否足够好，可以进行实际尝试？我在网上看不到太多关于它的信息，除了一个提议的开放堆栈项目和一篇仅在2014年发表的研究论文。我可能会改用分层用户，但对租户来说，当然还有其他好处。

  现在考虑到我希望租户能够在任何方向共享资源，也许我不需要分层租户。也许需要一个普通的平面多租户模式，只是增加了一层共享。一个租户将共享给另一个租户，或者可能是另一个租户中的用户。

  在后者中，每个用户似乎都成为了自己的租户，拥有自己的数据。它似乎越来越像一个社交网络。在Facebook上，我可以与他人分享东西，他们也可以与我分享东西，没有直接的等级制度，但品牌会制作反映等级制度理念的页面，而实际上没有等级制度。例如，微软有微软，但也有Xbox、Xbox Support 1、Xbox Support 7、Windows、Bing等。

  所以，我从前面的多租户体系结构开始，现在我想，我真正需要的是一个商业级的“社交网络”。

  这两条轨迹有意义吗？有什么事情让我改变或考虑吗？

Answer 1

在云计算中，多租户通常伴随着租户隔离。如果我们采用维基百科的定义，MT是独立于共享的。

在MT体系结构中，软件的一个实例服务于多个租户（或用户组）。这与多实例软件不同，在多实例软件中，一个软件的多个实例服务于多个租户。

MT架构的主要好处是成本——软件更新可以在单个实例上完成，以使所有租户受益。MT软件为租户提供了一个通用的功能基础，但通常具有允许每个租户定制品牌的接口

您的项目看起来是具有共享功能的MT。假设每家公司都希望能够共享对某些资源的访问。然后，体系结构应该具有足够的灵活性，以便租户能够控制对资源的访问。底层框架应该是快速、安全、可靠且可审计的。

因为您的重点是共享灵活性，所以体系结构支持租户以您和他们想要的方式定义对资源的访问——租户对租户，或租户对某个用户，这一点很重要。

在我看来，我会考虑使用“默认拒绝”架构——一个默认情况下不共享任何东西的架构，并允许租户设置访问资源的规则。

简短版本：多租户通常独立于交互。