無論您的架構和用來實作它的元件為何，您都需要部署和設定解決方案的元件。 在多租用戶環境中，請考慮如何部署 Azure 資源，特別是當您為每個租用戶部署專用資源，或根據系統中的租用戶數目動態重新設定資源時。 本文為解決方案架構師提供部署多租用戶解決方案的指引。 它示範規劃部署策略時要考慮的方法。
重要考量與需求
在規劃部署策略之前，請清楚定義您的需求。 請考慮下列因素：
預期規模： 判斷您是否預期只支援少數租用戶 （例如五個或更少），或成長為大量租用戶。 隨著租戶數量的增長，自動化變得越來越重要。
自動化或支援的上線： 指定租用戶是否應該透過自動化程序完成上線，或起始需要手動上線的要求。 定義團隊的任何手動核准步驟，例如防止濫用您的服務。
布建時間： 建立必須完成上線程式的速度。 如果您沒有明確的答案，請定義此步驟是否應該以秒、分鐘、小時或天為單位來測量。
Azure Marketplace： 確認您是否打算使用 Azure Marketplace 來起始部署。 如果您這麼做，請符合 新增租使用者的必要需求。
此外，請考慮上線和佈建步驟、自動化和資源管理責任。
上線和布建步驟
定義並記錄上線租戶所需的每項任務，即使該過程是手動的。 上線工作流程通常包含下列步驟：
- 接受商業合約。
- 完成手動核准步驟，例如防止詐騙或濫用您的服務。
- 在 Azure 中佈建資源。
- 建立或設定網域名稱。
- 執行部署后設定工作，例如建立租使用者的第一個用戶帳戶，並安全地將其認證傳輸至租使用者。
- 套用手動組態變更，例如網域名稱系統 （DNS） 記錄變更。
清楚記錄新租用戶上線所需的工作流程。
請考慮您需要為租用戶布建的特定 Azure 資源。 即使您未為每個租使用者布建專用資源，也請考慮您是否有時需要在新租用戶上線時部署資源。 當租用戶需要在特定區域中儲存資料時，可能會發生此案例。 當您使用 Bin 封裝方法時，也可能會發生此情況。 在垃圾桶封裝中，當您接近解決方案中戳記或元件的限制時，您會為下一批租用戶建立另一個實例。
請考慮上線程式是否會中斷其他租用戶，尤其是共用相同基礎結構的租用戶。 例如，如果您需要修改共用資料庫，請判斷此程式是否會導致其他租用戶可能會注意到的效能影響。 考慮您是否可以透過在正常工作時間之外執行入職流程來避免這些影響或減輕這些影響。
Automation
您應該針對雲端裝載解決方案使用自動化部署。 在多租用戶解決方案中，自動化變得更加重要，原因如下：
秤： 隨著租用戶人口的增加，手動部署程序變得越來越複雜和耗時。 隨著租用戶數目的成長，自動化部署方法更容易調整。
可重複： 在多租用戶環境中，請使用一致的程式來跨所有租用戶進行部署。 手動程式會造成租用戶之間發生錯誤或步驟不一致的機會。 然後，您的環境可能會處於不一致的狀態，這使您的團隊更難管理解決方案。
中斷的影響： 手動部署比自動部署風險更大，更容易中斷。 在多租用戶環境中，部署錯誤可能會導致影響每個租使用者的全系統中斷，進而增加整體影響。
當您部署至多租用戶環境時，請遵循下列做法：
使用部署管線來部署一般資源。
使用基礎結構即程式碼 （IaC） 技術，例如 Bicep、JSON Azure Resource Manager 範本 （ARM 範本） 或 Terraform。
如果適用，請使用程式碼叫用 Azure SDK。
如果您打算透過 Azure Marketplace 提供解決方案，您應該 為新租用戶提供完全自動化的上線程式。
資源容量上限
當您以程式設計方式將租用戶資源部署到共用資源時，請考慮每個資源的容量限制。 當您接近該限制時，您可能需要建立另一個資源實例以支持進一步調整。 請考慮您部署的每個資源的限制，以及觸發您部署另一個執行個體的條件。
例如，假設您的解決方案包含 Azure SQL 邏輯伺服器，並在該伺服器上為每個租用戶佈建專用資料庫。 單一邏輯伺服器有限制，其中包括它支援的資料庫數目上限。 當您接近這些限制時，您可能需要布建新的伺服器，才能繼續讓租用戶上線。 考慮是否要自動化此程序或手動監控成長。
資源管理責任
在某些多租用戶解決方案中，使用數個模型之一來部署資源。 為每個租用戶部署專用的 Azure 資源，例如每個租用戶的資料庫。 或者，您可以定義一組租用戶數目，以存放在資源的單一執行個體上，因此您擁有的租用戶數目會決定您部署至 Azure 的資源集。 在其他解決方案中，部署一組共用資源，並在您上線新租用戶時重新設定它們。
這些模型都需要您以不同的方式部署和管理資源，而且您必須考慮如何部署和管理您布建之資源的生命週期。 請考慮兩種常見的方法：
將租用戶視為已部署資源的 設定 ，並使用部署管線來部署和設定這些資源。
將租用戶視為 數據，並為您的租用戶配置和設定基礎結構的控制 平面 。
下列各節將進一步說明這些方法。
測試
在每次部署期間和之後徹底測試您的解決方案。 您可以使用自動化測試來驗證解決方案的功能和非功能行為。 請確定您測試租用戶隔離模型。 請考慮使用 Azure Chaos Studio 等工具，刻常引入模擬真實世界中斷的錯誤，並確認您的解決方案是否正常運作，即使元件變得無法使用或發生故障。
要考慮的方法和模式
Azure 架構中心和更廣泛社群的數個設計模式支援多租用戶解決方案的部署和設定。
部署標識模式
使用 [部署戳記] 模式 ，為租用戶或租用戶群組部署專用基礎結構。 單一戳記可能包含多個租使用者，或可能專用於單一租使用者。 您可以部署單一戳記，或協調多個戳記之間的部署。 如果您為每個租用戶部署專用戳記，請考慮以程式設計方式部署整個戳記。
部署環段
使用 部署通道 在不同時間將更新推出至不同的基礎結構群組。 此方法通常會補充 部署戳記模式。 根據租用戶喜好設定、工作負載類型和其他考量，將戳記群組指派給不同的環。 如需詳細資訊，請參閱 部署通道。
功能標幟
使用 功能旗標 ，逐步將解決方案的新功能或版本公開給不同的租用戶或使用者，而不需要重新部署程式碼。 請考慮使用 Azure 應用程式組態 來管理您的功能旗標。 如需詳細資訊，請參閱 功能旗標。
有時您必須選擇性地為特定客戶啟用特定功能。 例如，您可能有不同的 定價層 ，允許存取某些功能。 功能旗標通常不是這些案例的正確選擇。 相反地，請考慮建置一個程序來追蹤和強制執行每個客戶擁有的 授權權利 。
應避免的反模式
當您部署和設定多租用戶解決方案時，請避免抑制調整能力的情況。 下列範例會醒目提示常見的反模式：
手動部署和測試： 手動部署程序會增加風險，並減慢您的部署能力。 請考慮使用管線進行自動化部署、以程式設計方式從解決方案的程式碼建立資源，或兩者的組合。
租戶的專門定制： 避免部署僅適用於單一租用戶的功能或設定。 這種方法會增加部署和測試程序的複雜性。 請改為針對每個租使用者使用相同的資源類型和程式代碼基底。 使用 功能旗標 等策略進行暫時變更，或逐漸推出的功能。 或使用具有授權權利 的不同定價層 ，選擇性地為需要授權的租用戶啟用功能。 針對具有隔離或專用資源的租使用者，使用一致且自動化的部署程式。
租使用者清單做為組態或數據
當您在多租使用者解決方案中部署資源時，請考慮下列方法：
使用自動化部署管線來部署每個資源。 新增租使用者時，請重新設定管線來布建每個租用戶的資源。
使用自動化部署管線來部署不相依於租用戶數目的共享資源。 在應用程式中建立租使用者特定的資源。
當您考慮這兩種方法時，請區分將租用戶清單視為 設定 或 資料。 這種區別也會影響您為系統構建 控制平面 的方式。
作為設定的租用戶清單
當您將租使用者清單視為組態時，您會從集中式部署管線部署所有資源。 當新的租用戶上線時，您可以重新設定管線或其參數。 一般而言，重新設定會透過手動變更進行，如下圖所示。
新租用戶的上線程式通常包括下列步驟：
設定管線或修改管線組態中包含的參數檔案，以手動更新租用戶清單。
觸發管線以執行。
管線會重新部署一組完整的 Azure 資源，包括任何新的租使用者特定資源。
此方法適用於共用所有資源的少量租用戶和架構。 單一程式會部署和設定您的所有 Azure 資源，以簡化整體方法。
不過，隨著租用戶數目的增加 （通常大約 10 個或更多），當您新增租用戶時，重新設定管線會變得很麻煩。 執行部署管線所需的時間通常也會增加。 這種方法也不容易支援自助租使用者建立，而且租用戶上線之前的前置時間可能更長，因為您需要觸發管線來執行。
租使用者清單做為數據
當您將租使用者清單視為數據時，仍會使用管線來部署共用元件。 不過，針對需要為每個租使用者部署的資源和組態設定，您必須部署或設定資源。 例如，您的控制平面可以使用 Azure SDK 來建立特定資源，或起始參數化範本的部署。
上線程式通常包括下列非同步步驟：
要求上線租用戶，例如起始系統控制平面的 API 要求。
工作流程元件會接收建立要求，並協調其餘步驟。
工作流程會起始將租使用者特定資源部署至 Azure。 您可以使用命令式程序設計模型，例如 Azure SDK，或命令式觸發 Bicep 檔案或 Terraform 範本的部署。
當部署完成時，工作流程會將新租用戶的詳細數據儲存至中央租用戶目錄。 針對每個租使用者所儲存的數據可能包含租使用者標識碼，以及工作流程所建立之所有租使用者特定資源的資源標識碼。
此方法可讓您為新租使用者布建資源，而不需重新部署整個解決方案。 布建時間通常較短，因為只會部署租使用者特定的資源。
不過，這種方法通常更耗時地建置。 您的工作必須依您需要符合的租用戶數目或布建時間範圍來合理。
如需詳細資訊，請參閱 多租使用者控制平面的考慮。
備註
Azure 部署和設定作業通常需要一段時間才能完成。 請確定您使用適當的程式來起始和監視這些長時間執行的作業。 例如，您可以考慮遵循 異步 Request-Reply 模式。 使用設計來支持長時間執行的作業的技術，例如 Azure Logic Apps 和 耐久函式。
範例
Contoso 會為其客戶執行多租用戶解決方案。 他們有六個租用戶，預計在未來 18 個月內將成長至 300 個租使用者。 Contoso 會遵循 具有每個租使用者方法專用資料庫的多租用戶應用程式 。 他們會部署一組 Azure App Service 資源和所有租用戶共用的 Azure SQL 邏輯伺服器。 它們也會為每個租使用者部署專用的 Azure SQL 資料庫，如下圖所示。 Contoso 會使用 Bicep 來部署其 Azure 資源。
選項 1：針對所有專案使用部署管線
Contoso 可能會使用部署管線來部署其所有資源。 其管線會部署包含其所有 Azure 資源的 Bicep 檔案，包括每個租用戶的 Azure SQL 資料庫。 參數檔案會定義租用戶清單。 Bicep 檔案會使用 資源迴圈 ，為每個列出的租用戶部署資料庫，如下圖所示。
如果 Contoso 遵循此模型，則必須執行下列步驟：
將其參數檔案更新為新租使用者的一部分。
重新執行其管線。
手動追蹤資源限制，例如，如果它們以非預期的高速率成長，並接近單一 Azure SQL 邏輯伺服器上所支援的最大資料庫數目。
選項 2：使用部署管線和命令式資源建立的組合
或者，Contoso 可能會分隔 Azure 部署的責任。
Contoso 會使用 Bicep 檔案來定義要部署的共享資源。 共用資源支援所有租使用者，並包含租使用者目錄資料庫，也稱為 租使用者清單資料庫，如下圖所示。
Contoso 小組會建置包含租用戶上線 API 的控制平面。 當銷售小組向新客戶完成銷售時，Microsoft Dynamics 會觸發 API 開始上線程式。 Contoso 也提供自助 Web 介面，讓客戶用來觸發相同的 API。
API 會以異步方式啟動將新租用戶上線的工作流程。 工作流程會起始新 Azure SQL 資料庫的部署，其可能會使用下列其中一種方法：
使用 Azure SDK 來起始第二個 Bicep 檔案的部署，該檔案會定義 Azure SQL 資料庫。
使用 Azure SDK 以命令方式使用 管理連結庫來建立 Azure SQL 資料庫。
部署資料庫之後，工作流程會將租使用者新增至租使用者清單資料庫，如下圖所示。 應用層會起始進行中的資料庫架構更新。
貢獻者們
本文由 Microsoft 維護。 下列參與者撰寫本文。
主要作者：
- John Downs |Azure 模式和實務的主要軟體工程師
其他貢獻者：
- Bohdan Cherchyk | FastTrack for Azure 資深客戶工程師
- 阿森·弗拉基米爾斯基 | Azure FastTrack 的首席客戶工程師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。