無論您的架構和用來實作它的元件為何，您都需要部署和設定解決方案的元件。 在多租用戶環境中，請務必考慮如何部署 Azure 資源，特別是當您為每個租使用者部署專用資源，或根據系統中的租用戶數目重新設定資源時。 在此頁面上，我們提供解決方案架構設計人員部署多租用戶解決方案的指引，並示範規劃部署策略時要考慮的一些方法。
重要考慮和需求
在規劃部署策略之前，請務必清楚瞭解需求。 特定考慮包括下列各項：
- 預期規模： 您是否預期支持少數租使用者（例如五個或更少），或會成長為大量的租使用者？
- 自動化或支持的上線： 當租使用者準備好上線時，他們能否遵循自動化程式自行完成程式？ 或者，新租使用者是否起始要求，並在收到要求之後手動上線？ 小組是否需要手動核准步驟，例如防止濫用您的服務？
- 布建時間： 當租使用者準備好上線時，上線程式需要多快完成？ 如果您沒有明確的答案，請考慮這是否應該以秒、分鐘、小時或天為單位來測量。
- Azure Marketplace： 您是否打算使用 Azure Marketplace 來起始部署？ 如果您這樣做，則需要 符合以新增租使用者的需求。
您也應該考慮上線和布建步驟、自動化和資源管理責任。
上線和布建步驟
請考慮您在上線租使用者時需要執行的一切，並記錄此清單和工作流程，即使手動執行也一樣。 上線工作流程通常包含下列專案：
- 接受商業協定。
- 您需要為新租使用者設定系統所需的資訊集合。
- 例如，手動核准步驟，以防止詐騙或濫用您的服務。
- 在 Azure 中布建資源。
- 建立或設定功能變數名稱。
- 執行部署后設定工作，例如建立租使用者的第一個用戶帳戶，並安全地將其認證傳輸至租使用者。
- 手動設定變更，例如 DNS 記錄變更。
請清楚記錄新租用戶上線所需的工作流程。
此外，請考慮您需要為租使用者布建的特定 Azure 資源。 即使您未為每個租使用者布建專用資源，也請考慮您是否有時需要在新租用戶上線時部署資源。 當租使用者要求其數據儲存在特定區域中，或當您接近解決方案中的戳記或元件限制，且需要為下一批租使用者建立另一個實例時，可能會發生這種情況。
請考慮上架程式是否可能會干擾其他租使用者，尤其是共用相同基礎結構的人員。 例如，如果您需要修改共享資料庫，此程式是否會造成其他租使用者可能注意到的效能影響？ 請考慮您是否可以避免這些影響，或藉由在正常作業時間以外執行上線程式來減輕這些影響。
自動化
雲端裝載解決方案一律建議自動化部署。 使用多租用戶解決方案時，部署自動化會因為下列原因變得更加重要：
- 調整： 隨著租用戶擴展的增加，手動部署程式變得越來越複雜且耗時。 隨著租用戶數目的成長，自動化部署方法更容易調整。
- 可重複： 在多租用戶環境中，針對所有租使用者部署使用一致的程式。 手動程式會產生錯誤的機會，或某些租用戶執行的步驟，而不是其他租使用者。 這些手動程式會讓您的環境處於不一致的狀態，讓您的小組更難管理解決方案。
- 中斷的影響： 手動部署比自動化部署更具風險且容易中斷。 在多租用戶環境中，整個系統中斷的影響可能很高，因為每個租使用者都可能會受到影響。
當您部署至多租用戶環境時，應該使用部署管線，並使用基礎結構即程式代碼 （IaC） 技術，例如 Bicep、JSON ARM 範本、Terraform 或 Azure SDK。
如果您打算透過 Azure Marketplace 提供解決方案，您應該為新租使用者提供完全自動化的上線程式。 此程式會在 SaaS 履行 API 檔中說明。
資源容量上限
當您以程式設計方式將租用戶資源部署到共用資源時，請考慮每個資源的容量限制。 當您接近該限制時，您可能需要建立另一個資源實例以支持進一步調整。 請考慮您部署的每個資源限制，以及將觸發您部署另一個實例的條件。
例如，假設您的解決方案包含 Azure SQL 邏輯伺服器，而您的解決方案會針對每個租使用者在該伺服器上布建專用資料庫。 單一 邏輯伺服器有限制，其中包括邏輯伺服器支援的資料庫數目上限。 當您接近這些限制時，您可能需要布建新的伺服器，才能繼續讓租用戶上線。 請考慮您將此程式自動化，或手動監視成長。
資源管理責任
在某些多租用戶解決方案中，您會為每個租使用者部署專用的 Azure 資源，例如每個租用戶的資料庫。 或者，您可以決定要存放在單一資源實例上的一組租用戶數目，因此您所擁有的租用戶數目會決定部署至 Azure 的資源集。 在其他解決方案中，您會部署一組共用資源，然後在您上線新租使用者時重新設定資源。
這些模型都需要您以不同的方式部署和管理資源，而且您必須考慮如何部署和管理布建資源生命週期。 兩種常見的方法如下：
- 若要將租用戶視為您部署的資源設定，並使用部署管線來部署和設定這些資源。
- 若要將租用戶視為 數據，並具有 控制平面 布建和設定租用戶的基礎結構。
以下提供這些方法的進一步討論。
測試
規劃在每個部署期間和之後徹底測試您的解決方案。 您可以使用自動化測試來驗證解決方案的功能和非功能性行為。 請確定您測試租用戶隔離模型，並考慮使用 Azure Chaos Studio 之類的工具，刻意引入模擬真實世界中斷的錯誤，並確認您的解決方案運作，即使元件無法使用或故障也一樣。
要考慮的方法和模式
來自 Azure 架構中心的數種設計模式和更廣泛的社群，都與多租用戶解決方案的部署和設定相關。
部署戳記模式
部署 戳記模式 牽涉到為租使用者或租使用者群組部署專用基礎結構。 單一戳記可能包含多個租使用者，或可能專用於單一租使用者。 您可以選擇部署單一戳記，也可以協調跨多個戳記的部署。 如果您為每個租使用者部署專用戳記，您也可以考慮以程式設計方式部署整個戳記。
部署環
部署通道 可讓您在不同時間推出不同基礎結構群組的更新。 此方法通常與部署戳記模式搭配使用，而且可以根據租使用者喜好設定、工作負載類型和其他考慮，將戳記群組指派給不同的通道。 如需詳細資訊，請參閱 部署通道。
功能旗幟
功能旗標 可讓您在維護單一程式代碼基底的同時，逐漸將解決方案的新功能或版本公開給不同的租使用者。 請考慮使用 Azure 應用程式組態 來管理您的功能旗標。 如需詳細資訊，請參閱 功能旗標。
有時候，您必須選擇性地針對特定客戶啟用特定功能。 例如，您可能有不同的 定價層 ，允許存取特定功能。 功能旗標通常不是這些案例的正確選擇。 相反地，請考慮建置程式來追蹤並強制執行每位客戶擁有的 授權權利 。
要避免的反模式
當您部署和設定多租用戶解決方案時，請務必避免阻礙調整能力的情況。 其中包括下列各項：
- 手動部署和測試。 如上所述，手動部署程式會增加風險，並減緩部署能力。 請考慮使用管線進行自動化部署、以程式設計方式從解決方案的程式代碼建立資源，或兩者的組合。
- 租使用者的特製化自定義。 避免部署僅適用於單一租使用者的功能或組態。 這種方法會增加部署和測試程序的複雜性。 相反地，請針對每個租使用者使用相同的資源類型和程式代碼基底，並使用功能旗標等策略來暫時變更或逐漸推出的功能，或使用具有授權權利的不同定價層，選擇性地為需要它們的租使用者啟用功能。 針對具有隔離或專用資源的租使用者，使用一致且自動化的部署程式。
租使用者清單做為組態或數據
當您在多租用戶解決方案中部署資源時，可以考慮下列兩種方法：
- 使用自動化部署管線來部署每個資源。 新增租使用者時，請重新設定管線來布建每個租用戶的資源。
- 使用自動化部署管線來部署不相依於租用戶數目的共享資源。 針對針對每個租使用者部署的資源，請在您的應用程式內加以建立。
考慮這兩種方法時，您應該區分將租使用者清單 視為組態 或 數據。 當您考慮如何為系統建 置控制平面 時，這項區別也很重要。
作為設定的租用戶清單
當您將租使用者清單視為組態時，您會從集中式部署管線部署所有資源。 當新的租用戶上線時，您可以重新設定管線或其參數。 一般而言，重新設定會透過手動變更進行，如下圖所示。
將新租用戶上線的程式可能類似下列：
- 更新租用戶清單。 這通常是藉由設定管線本身，或修改管線組態中包含的參數檔案，以手動方式發生。
- 觸發管線以執行。
- 管線會重新部署一組完整的 Azure 資源，包括任何新的租使用者特定資源。
這種方法通常適用於少量租使用者，以及共用所有資源的架構。 這是一個簡單的方法，因為您可以使用單一程式來部署和設定所有 Azure 資源。
不過，當您接近更多租使用者時，例如 5 到 10 個以上的租使用者時，當您新增租使用者時，重新設定管線會變得很麻煩。 執行部署管線所需的時間通常也會大幅增加。 這種方法也不容易支援自助租使用者建立，而且租用戶上線之前的前置時間可能更長，因為您需要觸發管線來執行。
租使用者清單做為數據
當您將租使用者清單視為數據時，仍會使用管線來部署共用元件。 不過，針對需要為每個租使用者部署的資源和組態設定，您必須部署或設定資源。 例如，您的控制平面可以使用 Azure SDK 來建立特定資源，或起始參數化範本的部署。
將新租用戶上線的程式可能類似下列，而且會以異步方式發生：
- 要求租用戶上線，例如將 API 要求起始至系統控制平面。
- 工作流程元件會接收建立要求，並協調其餘步驟。
- 工作流程會起始將租使用者特定資源部署至 Azure。 使用命令式程序設計模型，例如使用 Azure SDK，或命令式觸發 Bicep 或 Terraform 範本的部署，即可達成此目的。
- 完成部署時，工作流程會將新租用戶的詳細數據儲存至中央租用戶目錄。 針對每個租使用者所儲存的數據，可能包含工作流程所建立之所有租使用者特定資源的租使用者標識碼和資源標識符。
如此一來，您可以布建新租用戶的資源，而不需重新部署整個解決方案。 為每個租使用者布建新資源所需的時間可能會較短，因為只需要部署那些資源。
不過，這種方法通常更耗時地建置，而您花費的努力必須依據租用戶數目或您需要滿足的布建時間範圍來合理。
如需此方法的詳細資訊，請參閱 多租使用者控制平面的考慮。
注意
Azure 部署和設定作業通常需要一段時間才能完成。 請確定您使用適當的程式來起始和監視這些長時間執行的作業。 例如，您可以考慮遵循 異步要求-回復模式。 使用設計來支持長時間執行作業的技術，例如 Azure Logic Apps 和 Durable Functions。
範例
Contoso 會為其客戶執行多租用戶解決方案。 目前，他們有六個租用戶，預計在未來 18 個月內將成長至 300 個租使用者。 Contoso 會 遵循具有每個租使用者 方法專用資料庫的多租用戶應用程式。 他們已部署一組 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 |首席軟體工程師
其他投稿人：
- Bohdan Cherchyk |適用於 Azure 的 FastTrack 資深客戶工程師
- 阿森·弗拉基米爾斯基 | 適用於 Azure 的主要客戶工程師 FastTrack
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
- 檢閱 更新多租使用者解決方案的考慮。
- 請考慮 記憶體和數據的結構方法。
- 請考慮 如何在多租用戶解決方案中使用 Azure Resource Manager。