多租戶應用程式的租戶模型

我們經常聽到創建多租戶應用程式的重要性，尤其是在開發軟體即服務 (SaaS) 應用程式的背景下。

關於“多租戶應用程式”的概念以及開發它所使用的各種模型存在一些混淆。在本文中，我們更實際地仔細研究了這些術語。

從技術角度了解不同的租戶模型#

單租戶架構#

單租戶架構是一種軟體或雲端計算模型，其中每個客戶或租戶有一個專用的應用程式或服務實例。如果我們查看 B2B 商業模式的起源，它始於每個軟體實例僅服務一個客戶或組織。

特點#

• 隔離： 每個客戶或租戶在一個獨立的環境中運行，擁有專用的資源、資料庫和配置。
• 自定義： 單租戶架構通常允許更大的自定義和靈活性，以滿足特定客戶需求。
• 安全性： 增強的安全性和數據隱私，因為客戶數據不與其他租戶的數據混合。
• 可擴展性： 資源和容量的擴展可以更簡單，因為每個租戶的實例可以獨立調整。
• 維護： 獨立的維護和更新，因為對一個租戶環境的更改不會影響其他租戶。
• 成本： 由於需要為每個租戶維護單獨的實例，因此基礎設施和運營成本通常較高。

範例#

• 專用託管： 傳統的網頁託管提供商提供單租戶架構，每個客戶獲得自己的資源、數據庫或配置。
• 內部部署軟體： 一些企業級軟體應用程式，如客戶關係管理 (CRM) 或人力資源管理系統 (HRMS)，為有嚴格數據安全性和自定義要求的組織提供單租戶部署選項。
• 帶有高級等級的 SaaS： 在一些軟體即服務 (SaaS) 產品中，高級或企業等級為需要增強安全性、合規性或定制化的客戶提供單租戶選項。

單租戶架構通常在合規性至關重要或需要量身定制的安全要求的情況下使用。例如，金融、醫療保健和政府等行業，由於有嚴格的法規要求，通常偏好單租戶解決方案來確保合規性。

然而，值得注意的是，與多租戶架構相比，單租戶架構可能需要更多的資源和更複雜的管理，因為每個客戶的實例需要自己的基礎設施和維護。因此，它們可能更適合較少但客戶規模較大的應用程式，或需要自定義和隔離的應用程式。

多租戶架構#

軟體多租戶是一種軟體架構，其中一個軟體的實例在伺服器上運行，並為多個租戶服務。這種設計的系統是“共享的”（而不是“專用的”或“隔離的”）。租戶是一組具有特定權限的用戶，他們共享對同一軟體實例的訪問權限。利用多租戶架構，軟體應用程式旨在為每個租戶提供實例的專用共享，包括其數據、配置、用戶管理、租戶個別功能和非功能屬性。 -- 來自維基百科

特點#

• 共享資源： 多個租戶共享相同的基礎設施，包括伺服器、數據庫和網絡資源，以最佳化資源利用。
• 隔離： 租戶的數據和配置在邏輯上分隔，確保數據隱私和安全。
• 規模經濟： 多租戶可以降低成本，因為開銷在多個用戶之間分配，降低運營和基礎設施成本。
• 可擴展性： 該架構可以水平或垂直擴展，以容納不斷增加的租戶和用戶。
• 維護： 更新和維護得到簡化，因為更改統一應用於所有租戶，簡化了管理。
• 自定義： 雖然有些自定義是可能的，但與單租戶架構相比通常更有限，以維持系統的一致性。

範例#

• 基於雲的 SaaS： 大多數軟體即服務 (SaaS) 應用程式，如 Google Workspace 和 Salesforce，採用多租戶以在共享平台上服務多個組織或用戶。
• 共享託管： 在網頁託管中，共享託管服務在同一伺服器上託管多個網站，每個都屬於不同的客戶或組織。
• 公共雲服務： 公共雲服務提供商，如 AWS 和 Azure，利用多租戶在共享數據中心中為不同客戶提供隔離的虛擬化資源。
• 企業級基礎設施解決方案： 如一個共享的 Kubernetes 集群，由公司內的多個業務單位使用。

在現實世界中重新定義多租戶應用程式#

我們從架構角度提供了定義，使其能夠輕鬆區分多租戶和單租戶設計。然而，這更傾向於技術定義。如果我們在設計租戶模型的現實世界開發環境中使用這些定義，這種思維方式假設多租戶應用程式必須有一個純粹共享的、多租戶的基礎設施。

然而，業務和產品各不相同，具有大量逐案要求，因此不存在一刀切的解決方案。

想像一個情景，一個租戶正在使用來自共享基礎設施的資源，但由於特定業務需求，他們需要系統的一兩個部分專門只為他們提供服務。這些專用部分可能是數據庫、實例或其他組件的組合，同時共享整體基礎設施。這就是混合租戶架構的出現。

在實際的 SaaS 產品開發中，常常遇到一個產品主要設計為通用多租戶模型的情景。然而，架構或資源的某些方面可能偏向於“單租戶”方法。

AWS 使用以下案例作為例子來傳達這一概念：多租戶是個廣義的概念，根據具體情況選擇合適的策略來定義你希望實現共享資源和數據隔離的目標。

換句話說，有時人們仍然把這個模型稱為“多租戶”，所以在多租戶的廣義定義中，它不意味著解決方案中的每一個組件都是共享的。相反，它意味著解決方案的至少某些組件在多個租戶之間重用。

廣泛理解這一術語能更好地幫助你體會客戶的需求和來源。

與其固執於單一的架構模型，多租戶反映了現實世界中 SaaS 產品的架構實用性。當我們提到多租戶應用程式，它不一定意味著應用程式遵循一種架構模型；它可能利用各種租戶策略，表明其至少一些組件是共享的。

確定你的租戶模型策略的關鍵考量因素#

問題來了，我該如何為我的產品建議租戶策略？這裡有一些重要的問題要思考：

• 你的業務目標是什麼？
• 單租戶解決方案是否能支持你的未來增長計畫？
• 你的運營團隊有多大，基礎設施管理中能自動化多少？你是否關心敏捷性和成本效益？
• 你的客戶對各種多租戶選項是否感到滿意？
• 各個選項如何影響合規性，包括你的合規性和客戶的合規性？
• 你是否預期滿足服務級別協議 (SLA) 或尋求具體的服務級別目標 (SLO)？
• 你是否在整體上考慮了安全性、成本、性能、可靠性和對個別租戶需求的響應能力？

記住，產品中沒有嚴格的界限必須選擇純多租戶或僅單租戶模型。你的決定應基於你如何劃分產品的架構組件以及客戶或業務需要的具體隔離級別。然後你可以相應地應用不同的方法。

下一步#

我們討論了多租戶應用程式的“新”定義，然而，租戶隔離、身份以及如何確定身份應否被隔離呢？身份被“隔離”意味著什麼呢？

當面對一個現實世界中的用戶擁有兩個不同的身份時，常會出現混淆狀況。是否合適將這情況標示為“身份隔離”？

我們會在即將到來的系列文章中解決這些問題，敬請期待！