Azure 提供許多選項來組織您的資源。 在多租用戶解決方案中，當您規劃資源組織策略時，必須考慮特定的取捨。 本文著重於 Azure 資源組織的兩個核心元素：租戶隔離和跨多個資源擴展。 它描述一些可支援不同租用戶隔離模型的常見部署方法。 本文也說明如何使用 Azure 資源限制和配額，以及如何調整解決方案超出這些限制。
重要考量與需求
以下各部分說明當您組織 Azure 資源時，應該進行的租用戶隔離性和規模考量。
租用戶隔離需求
當您在 Azure 中部署多租使用者解決方案時，您必須決定要將資源獻給每個租用戶，還是要在多個租用戶之間共用資源。 此系列文章中的多租戶方法和 服務特定指引 章節描述了許多資源類別的選擇和取捨。 一般而言，租戶隔離有一系列選項。 如需如何決定隔離模型的詳細資訊，請參閱 多租用戶解決方案的租用模型。
規模
大部分的 Azure 資源、資源群組和訂用帳戶都設有限制，這些限制可能會影響您的擴展能力。 您可能需要考慮擴展或箱型打包，以符合您計劃的租戶數量或系統負載。
如果您確定不會成長到大量租使用者或高負載，請不要過度工程您的向外延展方案。 但是，如果您打算讓解決方案成長，請仔細考慮您的向外延展計劃。 請遵循本文中的指引，以協助您設計具規模擴展能力的系統。
如果您有自動化的部署流程，且需要在不同資源間進行擴充，請確定您計劃如何在多個資源實體中部署和分配租戶。 例如，請考慮如何偵測何時接近可指派給特定資源的租用戶數目。 您可能會計劃在需要時及時部署新的資源。 或者，您可以事先部署資源集區，讓資源集區可供您在需要時使用。
小提示
在設計和開發的早期階段，您可能不會選擇實作自動化向外延展程式。 您仍應該考慮並清楚記錄在您成長時調整所需的程式。 藉由記錄程式，您可以更輕鬆地在未來出現需要時將其自動化。
請務必避免在整個程式代碼和設定中進行任何假設，以限制您調整的能力。 例如，您可能需要在未來向外延展至多個記憶體帳戶。 當您建置應用層時，請確定它可以根據目前的租用戶動態切換它所連線的儲存體帳戶。
要考慮的方法和模式
當您規劃 Azure 資源組織時，請考慮下列租用戶隔離、量化封裝、資源卷標和部署堆疊的方法。
租戶隔離
Azure 資源會透過階層部署和管理。 大部分的資源都會部署到訂用帳戶中包含的 資源群組中。 管理群組 會以邏輯方式將訂用帳戶群組在一起。 所有這些階層層都與 Microsoft Entra 租用戶相關聯。
當您決定如何為每個租使用者部署資源時，您可能會在階層中的不同層級隔離。 每個選項都適用於特定類型的多租用戶解決方案，而且每個選項都有優點和取捨。 針對解決方案的不同元件，使用不同的隔離模型來結合方法也很常見。
共用資源內的隔離
您可以選擇在多個租用戶之間共用 Azure 資源，並在單一實例上執行其所有工作負載。 如需可能很重要的特定考慮或選項，請參閱您使用之 Azure 服務的服務 特定指引 。
當您執行單一資源實例時，您必須考慮調整規模時可能達到的任何服務限制、訂用帳戶限制或配額。 例如，Azure Kubernetes Service （AKS） 叢集支持的節點數目上限，記憶體帳戶所支援的每秒交易數目上限。 規劃如何在接近這些限制時 擴展至多個共享資源。
您也需要確保應用程式碼完全瞭解多租戶，並限制存取特定租戶的資料。
作為共用資源方法的範例，假設 Contoso 正在建置多租使用者軟體即服務 （SaaS） 應用程式，其中包含 Web 應用程式、資料庫和記憶體帳戶。 他們可能會決定部署共用資源來服務其所有客戶。 在下圖中，所有客戶都會共用一組資源。
分隔資源群組中的資源
您也可以為每個租使用者部署專用資源。 您可以為單一租使用者部署解決方案的完整複本。 或者，您可能會在租用戶之間共用某些元件，並將其他元件專用於特定租使用者。 這種方法稱為 水平數據分割。
建議您使用資源群組來管理具有相同生命周期的資源。 在某些多租用戶系統中，將多個租用戶的資源部署至單一資源群組或一組資源群組是合理的。
請務必考慮如何部署和管理這些資源，包括 您的部署管線或應用程式是否啟動租用戶特定資源的部署。 您也需要判斷如何 清楚識別特定資源與特定租用戶有關。 請考慮使用明確的 命名慣例策略、 資源標籤或租使用者目錄資料庫。
最好針對您在多個租用戶之間共用的資源，以及針對個別租使用者部署的資源，使用不同的資源群組。 不過，對於某些資源， Azure 會限制可部署到資源群組的單一類型資源數目。 此限制表示，當您成長時，您可能需要 跨多個資源群組進行調整 。
假設 Contoso 有三個客戶或租使用者：Adventure Works、Fabrikam 和 Tailwind。 他們可能會選擇在三個租用戶之間共用 Web 應用程式和記憶體帳戶，然後為每個租使用者部署個別資料庫。 下圖顯示包含共用資源的資源群組，以及包含每個租使用者資料庫的資源群組。
將訂用帳戶中的資源群組分開
當您為每個租使用者部署一組資源時，請考慮使用專用的租使用者特定資源群組。 例如，當您遵循 部署戳記模式時，應該將每個戳記部署到自己的資源群組。 您可以考慮將多個租使用者特定資源群組部署到共用 Azure 訂用帳戶。 此方法可讓您輕鬆地設定原則和訪問控制規則。
您可以選擇為每個租使用者建立一組資源群組，以及針對任何共用資源建立共用資源群組。
當您將租使用者特定資源群組部署到共用訂用帳戶時，請注意每個訂用帳戶中的資源群組數目上限，以及套用至所部署資源的其他訂用帳戶層級限制。 當您接近這些限制時，您可能需要 跨多個訂用帳戶進行調整。
在此範例中，Contoso 可能會選擇為每個客戶部署戳記，並將戳記放在單一訂用帳戶內的專用資源群組中。 在下圖中，會為每個客戶建立包含三個資源群組的訂用帳戶。
個別訂用帳戶
您可以部署租使用者特定的訂用帳戶，以完全隔離租使用者特定資源。 您也可以為每個租使用者使用個別的訂用帳戶，以確保每個租使用者都充分使用任何適用的配額，因為訂用帳戶內會套用大部分配額和限制。 針對某些 Azure 計費帳戶類型， 您可以以程式設計方式建立訂用帳戶。 您也可以使用 Azure 保留 和 Azure 節省方案，跨訂用帳戶計算 。
請確定您知道您可以建立多少個訂用帳戶。 視您與Microsoft或Microsoft合作夥伴的商業關係而定，訂用帳戶數目上限可能會有所不同，例如，如果您有 企業合約。
當您在大量訂閱中工作時，要求增加配額可能會更加困難。 配額 API 提供某些資源類型的程式設計介面。 不過，對於許多資源類型，必須藉由 起始支援案例來要求增加配額。 當您使用許多訂用帳戶時，使用 Azure 支援合約和支援案例也可能很困難。
請考慮將您的租使用者特定訂用帳戶分組到 管理群組 階層，以便輕鬆管理訪問控制規則和原則。
例如，假設 Contoso 決定為每個客戶建立個別的 Azure 訂用帳戶，如下圖所示。 每個訂用帳戶都包含一個資源群組，其中包含該客戶的完整資源集。
每個訂用帳戶都包含一個資源群組，其中包含該客戶的完整資源集。
在此範例中，Contoso 會使用管理群組來簡化其訂用帳戶的管理。 藉由在管理群組的名稱中包含 生產，他們可以清楚地區分任何生產租戶與非生產或測試租戶。 不同的 Azure 訪問控制規則和原則適用於非生產租使用者。
Contoso 的所有訂閱都與單一的 Microsoft Entra 租戶相關聯。 Contoso 透過使用單一的 Microsoft Entra 租使用者，可以在其整個 Azure 資產中用到其小組的完整身分識別，包括使用者和服務主體。
個別Microsoft Entra 租使用者中的個別訂用帳戶
您也可以手動為每個租用戶建立個別的 Microsoft Entra 租用戶，或將資源部署到客戶的 Microsoft Entra 租用戶的訂用帳戶中。 不過，使用多個 Microsoft Entra 租用戶使得驗證、角色指派管理、全域原則套用，以及執行其他許多管理操作變得更加困難。
警告
我們建議不要為大多數多租用戶解決方案建立多個Microsoft Entra 租使用者。 跨Microsoft Entra 租使用者的工作引進了額外的複雜度，並減少調整和管理資源的能力。 通常，此方法只會由代表客戶作 Azure 環境的受控服務提供者（MSP）使用。
在您努力部署多個Microsoft Entra 租使用者之前，請考慮您是否可以改為在單一租用戶內使用管理群組或訂用帳戶來達成需求。
如果您需要在系結至多個Microsoft Entra 租使用者的訂用帳戶中管理 Azure 資源，請考慮使用 Azure Lighthouse 來協助跨Microsoft Entra 租使用者管理您的資源。
例如，Contoso 可以為每個客戶建立個別Microsoft Entra 租使用者和個別的 Azure 訂用帳戶，如下圖所示。
會為 Contoso 的每個租戶設定一個 Microsoft Entra 租戶。 每個租使用者都包含一個訂用帳戶，以及每個客戶需求的資源。 Azure Lighthouse 會連線至每個Microsoft Entra 租使用者。
Bin 封裝
無論您的資源隔離模型是什麼，您都應該考慮何時以及如何在多個資源之間擴展您的解決方案。 當系統負載增加或租用戶數目增加時，您可能需要調整資源。 考慮使用箱型打包，以部署滿足您需求的最佳資源數量。
小提示
在許多解決方案中，比較容易一起調整整個資源集，而不是個別調整資源。 請考慮遵循 部署戳記模式。
資源限制
Azure 資源在解決方案規劃中必須考慮 限制和配額。 例如，資源可能支援並行要求數目上限或租使用者特定的組態設定。
您設定和使用每個資源的方式也會影響該資源的延展性。 例如，假設您的應用程式可以在有特定數量的計算資源可用時，每秒成功回應已定義的交易數目。 除此之外，您可能需要向外延展。效能測試可協助您識別資源不再符合需求的時間點。
備註
即使您使用支援多個實例的服務，仍適用調整為多個資源的原則。
例如，Azure App 服務 支援相應放大方案的實例數目，但您可以調整單一方案有多遠有限制。 在大規模的多租用戶應用程式中，您可能會超過這些限制，而且需要部署更多 App Service 方案以符合您的成長。
當您在租用戶之間共用部分資源時，您應該先根據需求判斷資源所支援的租用戶數目。 然後，部署所需的資源數量，以處理租用戶總數。
例如，假設您部署 Azure 應用程式閘道 做為多租使用者 SaaS 解決方案的一部分。 您可以檢閱應用程式設計、測試應用程式閘道負載下的效能，並檢閱其設定。 然後，您可以判斷單一應用程式閘道資源可以在100個客戶之間共用。 根據貴組織的成長計劃，您預期第一年內將150個客戶上線，因此您必須規劃部署多個應用程式網關來服務預期的負載。
此圖顯示兩個應用程式閘道。 第一個閘道專用於客戶 1 到 100，而第二個閘道則專用於客戶 101 到 200。
資源群組和訂用帳戶限制
無論您使用共用或專用資源，請務必考慮限制。 Azure 會限制可 部署到資源群組 和 Azure 訂用帳戶中的資源數目。 當您接近這些限制時，您必須規劃跨多個資源群組或訂用帳戶進行調整。
例如，假設您將每個客戶的專用應用程式閘道部署至共用資源群組。 對於某些資源，Azure 支援 將最多800個相同類型的資源部署到單一資源群組。 因此，當您達到此限制時，您必須將任何新的應用程式閘道部署到另一個資源群組。 在下圖中，有兩個資源群組。 每個資源群組都包含800個應用程式閘道。
跨資源群組和訂用帳戶的 Bin 套件租使用者
您也可以跨資源、資源群組和訂用帳戶套用 bin 封裝概念。 例如，當您有幾個租使用者時，或許可以部署單一資源，並在所有租用戶之間共用。 下圖顯示將 Bin 封裝成單一資源。
隨著您成長，您可能會接近單一資源的容量限制，並相應放大至多個資源 （R）。 下圖顯示跨多個資源的 bin 封裝。
如果您達到單一資源群組中的資源數目限制，則可以將多個資源 （R） 部署到多個資源群組 （G）。 下圖顯示跨多個資源在多個資源群組中的 bin 封裝。
當您成長得更大時，您可以將資源部署到多個訂用帳戶 （S），每個訂用帳戶都包含多個資源群組 （G） 且有多個資源 （R）。 下圖顯示跨多個資源、多個資源群組和訂用帳戶的 Bin 封裝。
藉由規劃向外延展策略，您可以擴充至大量租戶，並維持高負載。
Tags
資源標籤可讓您將自訂元數據新增至 Azure 資源。 您可以使用此元數據來管理資源並追蹤成本。 如需詳細資訊，請參閱 使用資源標記來配置成本。
部署堆疊 (部分機器翻譯)
部署堆疊可讓您根據一般存留期將資源分組在一起，即使它們跨越多個資源群組或訂用帳戶也一樣。 當您部署租戶特定資源時，部署堆疊非常有用。特別是當您的部署方法要求您因為考量規模或合規性，將不同類型的資源部署到不同位置時。 當您停止該租戶時，部署堆疊也能讓您輕鬆地在一次操作中移除與單一租戶相關的所有資源。 如需詳細資訊，請參閱 建立和部署 Azure 部署堆棧。
應避免的反模式
未規劃調整規模。 請確定您已瞭解所部署資源的限制。 了解當您的負載或租用戶數目增加時，哪些限制可能會變得重要。 規劃如何在調整規模時部署更多資源，並測試該計劃。
不打算收納套件。 即使您不需要立即成長，也請規劃在一段時間內跨多個資源、資源群組和訂用帳戶調整 Azure 資源。 避免在應用程式代碼中做出假設，例如未來可能需要擴展為多個資源時只考慮單一資源。
調整許多個別資源。 如果您有複雜的資源拓撲，可能會變得難以個別調整每個元件。 遵循 部署郵票模式，通常更容易將您的解決方案作為一個整體進行擴展。
不需要時，為每個租使用者部署隔離的資源。 在許多解決方案中，為多個租使用者部署共用資源更有成本效益且更有效率。
無法追蹤租使用者特定資源。 如果您部署租使用者特定資源，請確定您瞭解哪些資源會配置給哪些租使用者。 此資訊對於合規性目的、追蹤成本以及在移除承租者時取消布建資源而言非常重要。 請考慮使用資源標籤來追蹤資源上的租用戶資訊，並考慮使用部署堆疊將租使用者特定資源分組到邏輯單元中，而不論其位於的資源群組或訂用帳戶為何。
使用個別Microsoft Entra 租使用者。 一般而言，無法布建多個Microsoft Entra 租使用者。 跨 Microsoft Entra 租使用者管理資源很複雜。 更輕鬆地跨連結至單一Microsoft Entra 租用戶的訂用帳戶進行調整。
當您不需要調整時，階層架構。 在某些解決方案中，您確定不會成長超過特定層級的規模。 在這些案例中，不需要建置複雜的調整邏輯。 不過，如果您的組織計劃成長，則必須準備好快速調整規模。
貢獻者們
本文由 Microsoft 維護。 下列參與者撰寫本文。
主要作者：
- John Downs |Azure 模式和實務的主要軟體工程師
其他貢獻者：
- 傑森·貝克 |適用於 Azure 的 FastTrack 資深客戶工程師
- Bohdan Cherchyk | FastTrack for Azure 資深客戶工程師
- 蘿拉·尼古拉斯 | Azure 快速入門資深客戶工程師
- 阿森·弗拉基米爾斯基 | Azure FastTrack 的首席客戶工程師
- 約書亞·瓦德爾 | Azure FastTrack 資深客戶工程師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。