本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

重新定義多租戶

多租戶和 SaaS 的術語通常緊密連接。在某些情況下，組織將 SaaS 和多租戶描述為相同的事情。儘管這看起來很自然，但將 SaaS 和多租戶等同於往往會帶領團隊對 SaaS 進行純粹的技術觀點，而實際上，SaaS 更像是一種商業模式而不是架構策略。

為了更好地理解這個概念，讓我們從多租戶的經典視圖開始。在這個純粹以基礎架構為中心的檢視中，多租戶可用來描述租戶如何共用資源，以提升靈活性和成本效益。

例如，假設您有一個微型服務或 Amazon 彈性運算雲端 (Amazon EC2) 執行個體，該執行個體已被 SaaS 系統的多個租用戶所使用。這項服務會被視為在多租用戶模型中執行，因為租用戶正在共用執行此服務之基礎結構的使用。

這個定義的挑戰在於，它太直接地將多租戶的技術概念附加到 SaaS。它假設 SaaS 的定義特徵是它必須具有共享的多租戶基礎結構。當我們研究 SaaS 在不同環境中實現的各種方式時，對 SaaS 的這種觀點開始崩潰。

下圖提供了 SaaS 系統的視圖，該系統揭露了我們在定義多租戶方面面臨的一些挑戰。

在這裡，您將看到先前描述的傳統 SaaS 模型，其中包含一系列應用程式服務，周圍環繞著共用服務，可讓您集體管理和操作租用戶。

新功能是我們已經包含的微服務。該圖包括三個微服務範例：產品、訂單和目錄。如果您仔細觀察這些服務的租賃模式，您會注意到它們都採用了略有不同的租賃模式。

產品服務會與所有租用戶共用其所有資源 (運算和儲存體)。這與多租戶的典型定義保持一致。但是，如果您查看訂單服務，您會看到它具有共用計算，但是每個租用戶都有個別的儲存空間。

目錄服務新增了另一個變體，其中每個租用戶的計算是分開的 (每個租用戶的個別微服務部署)，但它會共用所有租用戶的儲存區。

這種性質的變化在 SaaS 環境中很常見。嘈雜的鄰居、分層模型、隔離需求 — 這些都是您可能有選擇性地共用 SaaS 解決方案或隔離部分的原因之一。

考慮到這些變化以及許多其他可能性，要弄清楚如何使用多租戶一詞來分析此環境的特性變得更具挑戰性。總體而言，就客戶而言，這是一個多租戶環境。但是，如果我們使用最技術性的定義，則此環境的某些部分是多租戶，有些則不是。

這就是為什麼有必要擺脫使用術語多租戶來分析 SaaS 環境的原因。相反，我們可以討論如何在您的應用程序中實現多租戶，但避免使用它將解決方案表徵為 SaaS。如果要使用術語「多租戶」，則使用它將整個 SaaS 環境描述為多租戶是更有意義的，因為知道架構的某些部分可能是共享的，有些可能不會。整體而言，您仍在多租用戶模型中操作和管理此環境。

極端情況

為了更好地突出這種租賃概念，讓我們看一個 SaaS 模型，該模型具有共享零資源的租戶。下圖提供某些 SaaS 提供者使用的 SaaS 環境範例。

在此圖中，您將看到我們仍然擁有圍繞這些租戶的共同環境。但是，每個承租人都會使用專用的資源集合進行部署。沒有任何東西是由此模型中的租戶共享。

此範例會挑戰多租戶的意義。即使沒有任何資源共享，這是一個多租戶環境嗎？ 使用此系統的租用戶對於具有共用資源的 SaaS 環境的期望相同。事實上，他們可能沒有意識到他們的資源是如何在 SaaS 環境的引擎蓋下部署的。

即使這些租用戶在孤立的基礎架構中執行，它們仍然是集體管理和運作的。他們共享一個統一的入職、身分識別、指標、計費和操作經驗。此外，當新版本發行時，它會部署到所有租用戶。若要使用此功能，您無法允許個別租用戶進行一次性自訂。

這個極端範例為測試多租戶 SaaS 概念提供了一個很好的模型。雖然它可能無法實現共享基礎架構的所有效率，但它是一個完全有效的多租戶 SaaS 環境。對於某些客戶，他們的網域可能會指定部分或全部客戶在此模型中執行。這並不意味著他們不是 SaaS。如果他們使用這些共用服務，而且所有租用戶都執行相同的版本，這仍然符合 SaaS 的基本原則。

鑑於這些參數和 SaaS 的這個更廣泛的定義，您可以看到需要發展術語多租戶的使用。將集體管理和運行的任何 SaaS 系統稱為多租戶，這更有意義。然後，您可以推遲到更精細的術語，以描述在 SaaS 解決方案實施中如何共享或專用資源。