多租戶是具有交互性的正確方法

Question

我正在研究設置爲多租戶，單獨用戶，數據存儲等的項目。但是，當我進一步研究不同的場景時，我看到可能與多租戶無法兼容的東西，或者至少據我瞭解。

租戶可以分層

• 公司A
  • 西部地區
  • 東部地區
• B公司
  • 校園
  • 校園乙
• C公司

住戶可以到另一個資源

• A公司創建資源
與公司
• 公司A股它提供資源B具有指定的權限
• C公司與股份公司B
• B公司現在可以使用A公司提供的資源的資源和C

我不依賴於多租戶，但我要確保，無論模式我選擇，我遵循該模式的最佳實踐。

分層多租戶的定義是否足以實際嘗試？除了2014年提出的開放堆棧項目和研究論文外，我沒有在網上看到太多關於它的內容。我可能會使用分層用戶，但當然，租戶還有其他好處。

現在，我希望租戶能夠共享任何方向的資源，也許我不需要層級租戶。也許需要一個普通的平面多租戶模式，只需增加一層共享。一個房客會分享給另一個房客或另一個房客的用戶。

在後者中，每個用戶似乎都成爲了自己的租戶，並擁有自己的數據。它似乎越來越像一個社交網絡。在Facebook上，我可以分享給別人，他們可以分享給我，但沒有直接的層次結構，但品牌會製作反映層次結構的網頁，而實際上沒有層次結構。例如，微軟有微軟，但也有Xbox，Xbox支持1，Xbox支持7，Windows，必應等。

所以我從這裏開始，在我面前有一個多租戶架構，現在我一個企業級的「社交網絡」是我真正需要的。

這些軌道中的任何一個都有意義嗎？任何事情你會讓我改變或考慮？

Answer 1

在雲計算中，多租戶（MT）通常伴隨租戶隔離。如果我們採用維基百科的定義，MT是獨立於共享的。

在MT架構中，軟件的一個實例爲多個租戶（或用戶組）提供服務。這與其中多個軟件實例爲多個租戶提供服務的多實例軟件形成對比。

MT架構的主要優點是成本 - 軟件更新可以在單個實例上完成，以使所有租戶受益。 MT軟件爲租戶提供通用的功能基礎，但通常具有允許每個租戶自定義品牌工作流程的界面。

您的項目看起來是具有共享功能的MT。我們假設每個公司都希望能夠共享一些資源。然後架構應該有足夠的靈活性讓租戶能夠控制對資源的訪問。底層框架應該是快速，安全，可靠和可審計的。

由於您關注的是共享靈活性，所以架構支持讓租戶按照您和他們想要的方式定義資源訪問權限 - 租戶租戶或租戶給某個用戶很重要。

在我看來，我會考慮從「默認拒絕」體系結構開始 - 默認情況下不共享任何內容，並允許租戶設置訪問資源的規則。

簡版：多租戶通常獨立於交互性。