多租戶應用的租賃模型

我們經常聽說建立多租戶應用程序的重要性，特別是在開發軟體即服務 (SaaS) 應用的背景下。

對於“多租戶應用”這一概念的理解以及用於開發多租戶應用的各種模型，人們普遍存在困惑。在本文中，我們從一個更實用的角度深入探討了這些術語。

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

單租戶架構#

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

特徵#

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

範例#

• 專用主機： 傳統的網頁託管提供商提供單租戶架構，其中每個客戶都擁有其自己的資源、資料庫或配置。
• 內部部署軟體： 一些企業級軟體應用，例如客戶關係管理 (CRM) 或人力資源管理系統 (HRMS)，為有嚴格資料安全和定制需求的組織提供單租戶部署選項。
• 具有高級等級的 SaaS： 在某些軟體即服務 (SaaS) 提供中，高級或企業等級為需要增強安全性、合規性或定制功能的客戶提供單租戶選項。

單租戶架構通常用於合規至關重要或需要定制安全需求的場景。例如，金融、醫療和政府等行業，由於有嚴格的監管要求，往往偏好單租戶解決方案以確保合規。

然而，重要的是要注意，與多租戶架構相比，單租戶架構可能更資源密集且更複雜，因為每個客戶的實例需要其自身的基礎設施和維護。因此，對於擁有較少但較大客戶的應用或需要關鍵定制和隔離的情況，它們可能更為適合。

多租戶架構#

軟體多租戶性是一種 軟體架構，其中單一 實例 的軟體 在一台伺服器上運行並服務多個租戶。這樣設計的系統是“共享的”（而不是“專用的”或“隔離的”）。租戶是一組用戶，他們以特定的權限共享對軟體實例的訪問。通過多租戶架構， 軟體應用 被設計為為每個租戶提供實例的專用共享，包括其資料、配置、用戶管理、租戶個別功能和 非功能性屬性。 -- Wikipedia

特徵#

• 共享資源： 多個租戶共享相同的基礎設施，包括伺服器、資料庫和網路資源，以優化資源利用率。
• 隔離： 租戶的資料和配置以邏輯方式分隔，確保資料隱私和安全性。
• 規模經濟： 多租戶性可以降低成本，因為開銷在多個用戶之間分配，降低運營和基礎設施成本。
• 可擴展性： 該架構可以水平或垂直擴展，以容納越來越多的租戶和用戶。
• 維護： 更新和維護被簡化，因為變更對所有租戶統一適用，簡化了管理。
• 定制化： 雖然某些定制化是可能的，但通常相比於單租戶架構更有限，以便維持系統的整體一致性。

範例#

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

重新定義現實世界中的多租戶應用#

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

然而，業務和產品的變化很大，並且有許多個案需求，沒有一個放之四海而皆准的解決方案。

想像一個租戶使用共享基礎設施的場景，但由於特定的業務需求，他們需要系統中一兩個部分專門為他們提供。這些專用的部分可以是資料庫、實例或一組其他組件，所有這些都在共享的整體基礎設施內運行。這就是混合租戶架構發揮作用的地方。

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

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

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

這樣廣泛理解這個術語能夠更好地幫助你同情你的客戶需求以及他們的出發點。

不要固定在一個單一的架構模型上，多租戶反映了現實世界中 SaaS 產品架構的實用性。我們提到的多租戶應用並不一定意味著該應用遵循一種架構模型，它可以利用各種租戶策略，這意味著它的至少某些組件是共享的。

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

問題來了，我如何為我的產品提出租戶策略？ 以下是一些重要的問題需要考慮：

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

請記住，在你的產品中沒有一個嚴格的劃分，你必須選擇純多租戶或單租戶模型。你的決定應該基於你如何對產品的架構組件進行劃分以及客戶或業務所需的特定隔離級別。 然後你可以相應地應用不同的方法。

下一步#

我們談到了多租戶應用的“新”定義，那麼，租戶隔離、身份和如何判斷你的身份是否應隔離呢？身份“隔離”是什麼意思呢？

當處理一個真實世界的用戶擁有兩個不同的身份的情況時，混淆往往會出現。 將此情況標記為“身份隔離”是否合適呢？

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