繁體中文（香港）
多租戶應用程式的租戶模型
深入探討“多租戶”概念，分享我們對其的見解。
Guamian
Product & Design
Product & Design
Stop wasting weeks on user auth
Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.
Get started
深入探討“多租戶”概念，分享我們對其的見解。
我們經常聽到創建多租戶應用程式的重要性，尤其是在開發軟體即服務 (SaaS) 應用程式的背景下。
關於“多租戶應用程式”的概念以及開發它所使用的各種模型存在一些混淆。在本文中，我們更實際地仔細研究了這些術語。
單租戶架構是一種軟體或雲端計算模型，其中每個客戶或租戶有一個專用的應用程式或服務實例。如果我們查看 B2B 商業模式的起源，它始於每個軟體實例僅服務一個客戶或組織。
單租戶架構通常在合規性至關重要或需要量身定制的安全要求的情況下使用。例如，金融、醫療保健和政府等行業，由於有嚴格的法規要求，通常偏好單租戶解決方案來確保合規性。
然而，值得注意的是，與多租戶架構相比，單租戶架構可能需要更多的資源和更複雜的管理，因為每個客戶的實例需要自己的基礎設施和維護。因此，它們可能更適合較少但客戶規模較大的應用程式，或需要自定義和隔離的應用程式。
軟體多租戶是一種軟體架構，其中一個軟體的實例在伺服器上運行，並為多個租戶服務。這種設計的系統是“共享的”（而不是“專用的”或“隔離的”）。租戶是一組具有特定權限的用戶，他們共享對同一軟體實例的訪問權限。利用多租戶架構，軟體應用程式旨在為每個租戶提供實例的專用共享，包括其數據、配置、用戶管理、租戶個別功能和非功能屬性。 -- 來自維基百科
我們從架構角度提供了定義，使其能夠輕鬆區分多租戶和單租戶設計。然而，這更傾向於技術定義。如果我們在設計租戶模型的現實世界開發環境中使用這些定義，這種思維方式假設多租戶應用程式必須有一個純粹共享的、多租戶的基礎設施。
然而，業務和產品各不相同，具有大量逐案要求，因此不存在一刀切的解決方案。
想像一個情景，一個租戶正在使用來自共享基礎設施的資源，但由於特定業務需求，他們需要系統的一兩個部分專門只為他們提供服務。這些專用部分可能是數據庫、實例或其他組件的組合，同時共享整體基礎設施。這就是混合租戶架構的出現。
在實際的 SaaS 產品開發中，常常遇到一個產品主要設計為通用多租戶模型的情景。然而，架構或資源的某些方面可能偏向於“單租戶”方法。
AWS 使用以下案例作為例子來傳達這一概念：多租戶是個廣義的概念，根據具體情況選擇合適的策略來定義你希望實現共享資源和數據隔離的目標。
換句話說，有時人們仍然把這個模型稱為“多租戶”，所以在多租戶的廣義定義中，它不意味著解決方案中的每一個組件都是共享的。相反，它意味著解決方案的至少某些組件在多個租戶之間重用。
廣泛理解這一術語能更好地幫助你體會客戶的需求和來源。
與其固執於單一的架構模型，多租戶反映了現實世界中 SaaS 產品的架構實用性。當我們提到多租戶應用程式，它不一定意味著應用程式遵循一種架構模型；它可能利用各種租戶策略，表明其至少一些組件是共享的。
問題來了，我該如何為我的產品建議租戶策略？這裡有一些重要的問題要思考：
記住，產品中沒有嚴格的界限必須選擇純多租戶或僅單租戶模型。你的決定應基於你如何劃分產品的架構組件以及客戶或業務需要的具體隔離級別。然後你可以相應地應用不同的方法。
我們討論了多租戶應用程式的“新”定義，然而，租戶隔離、身份以及如何確定身份應否被隔離呢？身份被“隔離”意味著什麼呢？
當面對一個現實世界中的用戶擁有兩個不同的身份時，常會出現混淆狀況。是否合適將這情況標示為“身份隔離”？
我們會在即將到來的系列文章中解決這些問題，敬請期待！