多租户是具有交互性的正确方法吗

Question

我正在处理一个设置为多租户、独立用户、数据存储等的项目。但是，当我进一步研究不同的场景时，我发现可能无法与多租户很好地融合在一起，或者至少按照我的理解。

租户可以分层

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

租户可以将资源提供给另一个资源

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

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

分层多租户是否定义得足够好，可以实际尝试？除了 2014 年提出的 Open Stack 项目和一篇研究论文外，我在网上看不到太多关于它的信息。我可能会使用分层用户，但当然，租户还有其他好处。

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

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

因此，我已经从我面前的多租户架构开始，现在我真正需要的是商业级“社交网络”。

这些曲目中的任何一个都有意义吗？你有什么想让我改变或考虑的吗？

Answer 1

在云计算中，多租户 (MT) 通常伴随着租户隔离。如果我们按照维基百科的定义，机器翻译是独立于共享的。

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

MT 架构的主要优势在于成本 - 可以在单个实例上完成软件更新，从而使所有租户受益。 MT 软件为租户提供通用功能基础，但通常具有允许每个租户自定义品牌和工作流程的界面。

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

由于您的重点是共享灵活性，因此架构支持让租户以您和他们想要的方式（租户对租户或租户对某些用户）定义对资源的访问非常重要。

在我看来，我会考虑从“默认拒绝”架构开始 - 默认情况下不共享任何内容，并允许租户设置访问资源的规则。

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