「租戶」呢個概念對大多數用戶都比較陌生，但對於構建身份模型尤為重要。喺呢篇文章中，我哋會透過例子幫助大家了解邊種身份模型適合佢哋嘅業務。
隨着低代碼工具同雲端服務嘅成熟度不斷提高，加上人工智能工具化嘅加速發展，開發應用嘅門檻大大降低，市場上出現越嚟越多嘅應用。
無論係複雜定簡單嘅應用，大多數應用都涉及用戶註冊同登錄情景，咁樣用戶就可以獲得更穩定、安全同定製化嘅服務。為咗解決用戶登錄同註冊嘅問題，第一步就係構建身份系統。
對於好多面向消費者嘅應用，佢哋嘅身份模型往往比較簡單，甚至只需要電郵地址同密碼。對於處於快速增長同吸引新用戶階段嘅應用，咁樣已經足夠；但當應用有自己嘅業務模型時，最簡單嘅情況，例如提供廣告服務，需要區分普通用戶帳戶同廣告主帳戶。廣告主帳戶可以自定義廣告投放範圍、內容等；而普通用戶只能瀏覽部分免費內容同廣告等。
Logto 係一個雲端身份解決方案，亦有同雲服務一樣核心嘅開源軟件（OSS）解決方案，供有特定需求嘅用戶進行定製。Logto 嘅服務係基於多租戶系統構建，每個 Logto 用戶創建自己嘅帳戶，並可以喺帳戶中管理多個租戶。其他各種身份雲服務亦有類似架構，每個不同嘅雲服務都有自己對「租戶」嘅定義，所以我哋喺文章中討論嘅租戶模型係限於 Logto 嘅情況，而對於其他供應商可能會有其他相應概念。
值得注意嘅係，喺 Logto 嘅多租戶模型中，租戶之間嘅數據（所有終端用戶嘅信息）係隔離嘅，所以 Logto 用戶可以根據佢哋嘅業務需求喺一個 Logto 帳戶內管理終端用戶帳戶數據。好多其他嘅身份雲服務只能支援每個帳戶只有一個租戶，令需要同時管理多個租戶嘅用戶經常切換帳戶，體驗較差。
咁講晒，應用應該點樣揀啱佢嘅帳戶模型呢？我哋嚟睇下三個案例。
呢種類型嘅應用身份模型相對比較簡單。以音樂串流應用為例——除咗管理員（Logto 嘅用戶 “foo”，呢個情況下係租戶擁有者，天生有管理訪問權限），只有終端用戶。
喺呢個情境中，終端用戶分為三種類型：
喺上述應用情境中，我哋只需要三種類型嘅角色（免費、付費、高級），每個角色都分配唔同嘅權限。咁樣終端用戶登錄後，Logto 可以根據佢擁有嘅角色決定是否向佢提供某些特定服務（例如 HiFi 音樂）。喺呢刻，我哋只需要一個租戶就可以符合要求。
一個連接第三方服務提供者同終端用戶嘅平台，亦係而家好常見嘅 2C 商業模式。有兩個用戶群需要考慮——以一個電商應用為例，就係商家（服務提供商）同買家（終端用戶）。
呢度有兩種建構身份模型嘅方法：
為咗令例子更容易理解，我哋假設買家可以下單或查看產品描述；商家可以更改產品價格、更改產品描述及查看產品庫存。商家檢視產品描述以幫助佢哋發現問題同及時更新產品信息。
對於身份模型 1，只有一個應用。所有註冊嘅用戶都成為買家。如果有人需要賣嘢，佢可以添加自己嘅產品嚟出售，所以咁樣嘅終端用戶會獲得除買家權限外嘅商家權限，以管理佢自己嘅產品。
對於身份模型 2，由於每個租戶都有自己獨特嘅身份信息及自己嘅獨立授權閘道，每個租戶需要有自己嘅獨立應用。喺例子情況下，就會有買家應用與商家應用。買家帳戶唔可以成為商家，商家帳戶亦唔可以成為買家。如果商家想從買家嘅角度查看自己嘅產品描述，就好似模型 1 咁，需要重新喺商家應用中實施相同功能，又或者註冊一個買家應用帳戶嚟查看。呢樣會增加好多複雜度，但優勢係買家和商家身份完全隔離。
如果商家有好多唔同嘅產品需要管理，使用身份模型 2 及開發一個更專業化嘅商家應用應該係更好嘅選擇。模型 1 更適合例如 eBay 呢類平台，商家嘅產品唔多，亦唔需要過於複雜嘅產品管理功能。
假設有一間 IT 技術諮詢公司，佢嘅客戶唔具備自行開發 IT 系統嘅能力，所以需要尋求呢間公司嘅技術服務。
假設公司有兩個客戶，一個係書店內部書籍管理系統，另一個客戶係酒店嘅訂房系統。
從書店老闆嘅角度，我顯然唔想酒店客戶可以隨意登錄我嘅書籍管理系統，因為咁樣會非常唔安全。因此，從保護隱私嘅角度，必須為每個客戶設置獨立租戶，利用租戶信息隔離機制，保證客戶資料唔會被其他客戶看見。
正如我哋之前提到，即使你需要創建多個租戶，Logto 可以幫助你喺一個帳戶中管理多個租戶，呢樣比起某些需要你自己創建同管理多個帳戶嘅服務更方便同安全。
透過上述例子，你一定知道喺咩時候一定需要創建多個租戶，喺咩情境中可以選擇單租戶或者多租戶，然後根據你自己嘅業務需求，選擇最適合你嘅身份模型解決方案。
Logto 團隊嘅目標係確保「是否應該創建多個租戶」呢個問題唔係任何業務嘅阻礙。如果你唔肯定你嘅業務情境能否使用單租戶實現，請加入 Logto 社區進行諮詢。你嘅問題亦可能係其他人嘅問題，所以將你遇到嘅挑戰同我哋分享，以幫助提升 Logto 產品嘅可擴展性。
如果你係應用中挑選身份框架，Logto 值得一試。佢提供一個開箱即用嘅方案，適合各種業務情境，從小型企業到大型應用！