什麼是多租户 (Multi-tenancy)？
軟體多租戶 (Multi-tenancy) 是一種 軟體架構 ，其中單個 軟體 實例 在服務器上運行，並為多個租戶服務。這樣設計的系統是“共享的”（而不是“專用的”或“隔離的”）。
租戶是一組共享對該軟件實例特定權限的用戶。
當服務提供商向多個客戶提供標準化服務時，多租戶架構通常是首選。這些服務通常只有最小的定制，所有客戶共享相同的應用程式實例。當應用程式更新時，對所有客戶同時生效。
例如，CRM（客戶關係管理）系統經常使用多租戶架構向所有客戶提供相同的服務。
多租戶 (Multi-tenancy) 的一個關鍵原則是“共享”。這並不意味著解決方案的每個部分都是共享的；這意味著至少有一些組件在多個租戶之間重複使用。理解這個更廣泛的概念可以幫助你更好地滿足客戶的需求。
多租户 (Multi-tenancy) 產品的使用案例有哪些？
多租戶 (Multi-tenancy) 應用程式常用於軟體即服務（SaaS）產品中，如生產力工具、協作軟件等。在此設置中，每個“租戶”通常代表一個商業客戶，擁有多個用戶（通常是員工）。在不同的產品中，根據上下文，它可能被稱為租戶、工作空間或項目。單一企業可能還有多個租戶來代表不同的部門或組織。
在更複雜的情況下，超出 SaaS 的 B2B 應用程式中，多租戶 (Multi-tenancy) 應用程式為各種團隊、業務客戶和合作公司提供了一個共享的平臺來訪問你的服務。
為什麼要在 SaaS 產品中使用多租戶 (Multi-tenancy)
使用多租户 (Multi-tenancy) 進行擴展
對於企業客戶，多租戶 (Multi-tenancy) 是有效滿足其對可用性、資源管理、成本管理和數據安全需求的關鍵。從技術層面來說，採用多租戶 (Multi-tenancy) 方法可簡化你的開發流程，最小化技術挑戰並促進無縫擴展。
創建統一的體驗
在檢視 SaaS 產品的根源時，它類似於一棟擁有多個公寓的建築。所有租戶共享水、電、煤氣等公共設施，但他們獨立掌握管理自己空間和資源的控制權。這種方法簡化了物業管理。
透過租戶隔離確保安全性
在多租户 (Multi-tenancy) 架構中，引入“租戶”一詞以創建邊界，將不同租戶的資源和數據在共享實例內分離並保護起來。這確保了即使租戶使用相同的底層資源，也能保持各自数据和操作的獨特性和安全性。
如何在多租户 (Multi-tenancy) 架構中實現租戶隔離？
當討論多租戶 (Multi-tenancy) 應用程式時，總是需要實現租戶隔離。這意味著在共享系統（例如，雲基礎設施或多租戶 (Multi-tenancy) 應用程式）中將不同租戶的數據和資源分開且安全，以防止任何未經授權的企圖訪問另一租戶的資源。
雖然這種說明可能看似抽象，我們將通過示例和關鍵細節進一步解釋隔離心態和實現租戶隔離的最佳實踐。
租戶隔離不違背多租户 (Multi-tenancy) 的“共享”心態
這是因為租戶隔離不一定是一種基礎設施資源層級的結構。在多租户 (Multi-tenancy) 和隔離的領域中，有些人將隔離視為對實際基礎設施資源的嚴格分割。這通常導致每個租戶擁有不同的數據庫、計算實例、帳戶或私有雲的模式。在共享資源場景中，如多租戶 (Multi-tenancy) 應用程式，實現隔離的方法可以是一種邏輯結構。
在架構的設計中，可以在租戶之間實現不同程度的資源隔離：
通常，共享的租戶資源越多，系統迭代和維護成本越低。反之，共享資源越少，成本越高。
租戶隔離專注於使用“租戶”上下文來限制資源訪問。它評估當前租戶的上下文，並使用該上下文來確定哪些資源對該租戶可訪問。
認證 (Authentication) 和授權 (Authorization) 並不等於“隔離”
使用認證 (Authentication) 和授權 (Authorization)來控制對你的 SaaS 環境的訪問很重要，但這還不足以實現完全隔離。這些機制僅是安全難題的一部分。
人們經常問一個問題，我可以使用通用授權解決方案和基於角色的訪問控制 (Access Control, RBAC)來實現租戶隔離嗎？
你可以構建一個多租戶 (Multi-tenancy) 應用程式，但不能說你實現並採用了租戶隔離策略作為最佳實踐。我們通常不建議這樣做，因為租戶隔離是獨立於認證 (Authentication) 和授權 (Authorization) 的。
舉例來說，考慮一種情況，你已經為你的 SaaS 系統設置了認證 (Authentication) 和授權 (Authorization)。當用戶登錄時，他們會收到一個包含其角色信息的 token，用以規定他們在應用程式中可以做什麼。這種方法增強了安全性，但並不能確保隔離。
使用“組織”作為上下文來代表 SaaS 產品租戶，以實現租戶隔離
僅依賴認證 (Authentication) 和授權 (Authorization) 無法阻止擁有正確角色的用戶訪問其他租戶的資源。因此，我們需要整合一個“租戶”上下文，例如租戶 ID 來限制資源訪問。
這就是租戶隔離發揮作用的地方。它使用租戶特定的標識符來建立邊界，就像牆壁、門和鎖一樣，確保租戶之間清晰的分隔。
多租户 (Multi-tenancy) 應用程式中身份是如何管理的？
我們討論了租戶隔離，但身份呢？如何決定你的身份是否應該是“隔離的”？
“身份隔離”這個概念經常讓人混淆。它可能指的是一個現實用戶在通常的理解中擁有兩個身份的情況。
- 這兩個身份可以在單一身份系統中存在。例如，Sarah 可能擁有一個個人電子郵件地址，還有一個通過單點登錄 (SSO) 連接的公司電子郵件地址。
- 用戶在不同的身份系統中保持兩個獨立的身份，代表完全獨立的產品。這些產品彼此之間完全沒有關聯。
有時，這些情況被稱為“身份隔離”，但該術語可能對決策沒有幫助。
與其問你是否需要“身份隔離”，不如考慮你的業務或產品的哪些部分需要獨立的身份系統。這將指導你的系統設計。對於多租戶 (Multi-tenancy) 應用程式而言，在大多數情況下，身份是共享的，而每個租戶的資源則是相互獨立的。
在多租戶 (Multi-tenancy) 應用程式中，身份是租戶間共享的，與租戶特定的資源和數據不同。這就像作為建築物管理員——你不會希望維護兩份獨立的租戶姓名列表。
當目標是租戶隔離時，“組織”這個詞常常出現，因為它是構建多租戶 (Multi-tenancy) 應用程式的最佳實踐。
通過在許多 CIAM（客戶身份管理）或 Auth 服務中使用“組織”，你可以在多租戶 (Multi-tenancy) 應用程式中實現租戶隔離，同時維護統一的身份系統。
如何選擇合適的授權模型以實現更好的訪問控制 (Access Control)？
選擇合適的授權模型時，考慮以下問題：
- 你是在開發 B2C、B2B 還是兩者結合的產品？
- 你的應用程式是否具有多租戶 (Multi-tenancy) 架構？
- 是否有來自業務單位決定的應用特定隔離層級的需求？
- 在組織範疇內需要定義哪些權限和角色，哪些是不需要的？