在有互动性的情况下，多租户是正确的方法吗？
我正在从事一个以多租户、独立用户、数据存储等形式设置的项目。然而，当我进一步研究不同的场景时，我看到了一些可能与多租户不能很好地结合在一起的东西，或者至少在我理解的情况下。
租户可以是层次结构的
- A公司
- 西部地区
- 东部地区
- B公司
- 校园A
- 校园B
- C公司
租户可以向另一个资源提供资源。
- A公司创建资源
- 公司A以指定的权限与B公司共享
- C公司与B公司共享资源
- B公司现在可以使用A公司和C公司提供的资源
我与多租户无关，但我想确保无论我选择哪种模式，我都遵循该模式的最佳实践。
层次结构的多租户定义是否足够好，可以进行实际尝试？我在网上并没有看到太多关于它的报道，除了在2014年才提出的一个开放堆栈项目和一篇研究论文。我可能会使用层次化的用户，但当然还有其他好处给租户。
现在，考虑到我希望租户能够在任何方向上共享资源，也许我不需要分层租户。也许需要一个普通的平面多租户模式，只需增加一层共享。一个租户将与另一个租户共享，或者在另一个租户中共享用户。
在后一种情况下，每个用户似乎都成为了自己的租户，拥有自己的数据。它似乎越来越像一个社交网络。在Facebook上，我可以把东西分享给别人，他们可以和我分享，没有直接的等级，但是品牌会制作出反映等级观念的网页，而不是真正的等级。例如，微软拥有微软，但也有Xbox、Xbox支持1、Xbox支持7、Windows、Bing等。
所以我从我面前的多租户架构开始，现在我真正需要的是一个商业级别的“社交网络”。
这些曲目中的任何一个都有意义吗？你有什么想让我改变或考虑的吗？
回答 1
Stack Overflow用户
发布于 2016-01-01 00:31:17
在云计算中，多租户(MT)通常伴随着租户隔离.如果我们采用维基百科的定义，MT是独立于共享的。
在MT体系结构中，一个软件实例为多个租户(或多组用户)服务。这与多实例软件不同，其中一个软件的多个实例为多个租户服务。
MT体系结构的主要好处在于成本--可以在单个实例上进行软件更新，以使所有租户受益。MT软件为租户提供了共同的功能基础，但通常有允许每个租户定制品牌和工作流的接口。
您的项目看起来是具有共享功能的MT。让我们假设每个公司都希望能够共享一些资源。因此，架构应该具有足够的灵活性，以便租户能够控制对资源的访问。底层框架应该是快速、安全、可靠和可审计的。
由于您的重点是共享灵活性，因此架构支持允许租户以您和他们想要的方式定义对资源的访问--租户对租户，或对某些用户的租户。
在我看来，我会考虑从“默认-拒绝”架构开始--默认情况下不共享任何东西，并允许租户设置访问资源的规则。
短版本:多租户通常独立于互动性。
https://stackoverflow.com/questions/34552352
复制相似问题
腾讯云开发者
