多租戶應用的租賃模型
深入探討 "多租戶 "的概念,分享我們對這一概念的認識。
深入探討 "多租戶 "的概念,分享我們對這一概念的認識。
我們經常聽說建立多租戶應用程序的重要性,特別是在開發軟體即服務 (SaaS) 應用的背景下。
對於“多租戶應用”這一概念的理解以及用於開發多租戶應用的各種模型,人們普遍存在困惑。在本文中,我們從一個更實用的角度深入探討了這些術語。
單租戶架構是一種軟體或雲端計算模型,其中每個客戶或租戶都有專用的應用或服務實例。如果我們追溯 B2B 商業模式的起源,則始於每個軟體實例僅服務於一個客戶或組織。

單租戶架構通常用於合規至關重要或需要定制安全需求的場景。例如,金融、醫療和政府等行業,由於有嚴格的監管要求,往往偏好單租戶解決方案以確保合規。
然而,重要的是要注意,與多租戶架構相比,單租戶架構可能更資源密集且更複雜,因為每個客戶的實例需要其自身的基礎設施和維護。因此,對於擁有較少但較大客戶的應用或需要關鍵定制和隔離的情況,它們可能更為適合。
軟體多租戶性是一種 軟體架構,其中單一 實例 的軟體 在一台伺服器上運行並服務多個租戶。這樣設計的系統是“共享的”(而不是“專用的”或“隔離的”)。租戶是一組用戶,他們以特定的權限共享對軟體實例的訪問。通過多租戶架構, 軟體應用 被設計為為每個租戶提供實例的專用共享,包括其資料、配置、用戶管理、租戶個別功能和 非功能性屬性。 -- Wikipedia

我們從架構角度提供了定義,使區分多租戶和單租戶設計變得簡單。然而,這更傾向於技術定義。如果我們在設計租戶模型時在現實世界的開發環境中使用這些定義,這種思維方式假定多租戶應用必須擁有純粹共享的多租戶基礎設施。
然而,業務和產品的變化很大,並且有許多個案需求,沒有一個放之四海而皆准的解決方案。
想像一個租戶使用共享基礎設施的場景,但由於特定的業務需求,他們需要系統中一兩個部分專門為他們提供。這些專用的部分可以是資料庫、實例或一組其他組件,所有這些都在共享的整體基礎設施內運行。這就是混合租戶架構發揮作用的地方。
在實際的 SaaS 產品開發中,通常會遇到產品主要設計成通用的多租戶模型的情況。然而,架構或資源的某些方面可能會偏向“單租戶”方法。
AWS 使用以下個案作為範例來傳達這一概念:多租戶是一個廣泛的概念,根據每種情況選擇合適的策略來定義你希望實現的共享資源和資料隔離。

換句話說,有時人們仍然稱這種模型為“多租戶”,因此在多租戶的廣泛定義中,它並不意味著解決方案中的每一個組件都被共享。相反,它表示解決方案的至少某些組件在多個租戶之間被重用。
這樣廣泛理解這個術語能夠更好地幫助你同情你的客戶需求以及他們的出發點。
不要固定在一個單一的架構模型上,多租戶反映了現實世界中 SaaS 產品架構的實用性。我們提到的多租戶應用並不一定意味著該應用遵循一種架構模型,它可以利用各種租戶策略,這意味著它的至少某些組件是共享的。
問題來了,我如何為我的產品提出租戶策略? 以下是一些重要的問題需要考慮:
請記住,在你的產品中沒有一個嚴格的劃分,你必須選擇純多租戶或單租戶模型。你的決定應該基於你如何對產品的架構組件進行劃分以及客戶或業務所需的特定隔離級別。 然後你可以相應地應用不同的方法。
我們談到了多租戶應用的“新”定義,那麼,租戶隔離、身份和如何判斷你的身份是否應隔離呢?身份“隔離”是什麼意思呢?
當處理一個真實世界的用戶擁有兩個不同的身份的情況時,混淆往往會出現。 將此情況標記為“身份隔離”是否合適呢?
我們將在即將到來的一系列文章中解決這些問題。敬請期待!