我正在开发一个设置为多租户，独立用户，数据存储等的项目。但是，当我进一步研究不同的场景时，我发现可能与多租户混合不好的事情，或者至少按照我的理解。
租户可以分层次
租户可以为其他资源提供资源
我不喜欢多租户，但我想确保无论我选择何种模式，我都会遵循该模式的最佳实践。
层级多租户的定义是否足以实际尝试？除了2014年提出的Open Stack项目和研究论文之外，我没有在网上看到太多关于它的信息。我可能会使用层级用户，但当然，租户还有其他好处。
现在我希望租户能够在任何方向上共享资源，也许我不需要分层租户。也许需要一个普通的平面多租户模式，只需添加一层共享。一个租户会分享给另一个租户或者另一个租户的用户。
在后者中，每个用户似乎都成了自己的租户，拥有自己的数据。它似乎越来越像一个社交网络。在Facebook中，我可以与他人分享内容，他们可以与我分享内容，没有直接的层次结构，但品牌会制作反映层次结构概念的页面，而不会实际拥有。例如，微软有微软，还有Xbox，Xbox支持1，Xbox支持7，Windows，Bing等。
所以我从这里开始，在我面前有一个多租户架构，现在我真的需要一个商业级的“社交网络”。
这些曲目中的任何一条都有意义吗？你会让我改变或考虑的任何事情吗？
答案 0 :(得分：0)
在云计算中，多租户（MT）通常伴随着租户隔离。如果我们采用维基百科定义，则MT独立于共享。
在MT架构中，软件的一个实例为多个租户（或用户组）提供服务。这与多实例软件形成对比，多实例软件中多个软件实例为多个租户提供服务。
MT架构的主要好处是成本 - 可以在单个实例上进行软件更新，以使所有租户受益。 MT软件为租户提供了共同的功能基础，但通常具有允许每个租户定制品牌和接口的接口。工作流程。
您的项目看起来是具有共享功能的MT。让我们假设每个公司都希望能够共享对某些资源的访问权限。然后，该体系结构应具有足够的灵活性，以使租户能够控制对资源的访问。底层框架应该快速，安全，可靠且可审计。
由于您的重点是共享灵活性，因此架构支持让租户按您和他们想要的方式定义对资源的访问权限非常重要 - 租户租户或某些用户租户。
在我看来，我会考虑从“默认拒绝”架构开始 - 默认情况下不共享任何内容，并允许租户设置访问资源的规则。
简短版本：多租户通常与交互性无关。