多租用戶解決方案部署和設定的架構方法

無論您的架構和用來實作它的元件為何，您都需要部署和設定解決方案的元件。 在多租使用者環境中，請務必考慮如何部署 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 應用程式組態來管理您的功能旗標。 如需詳細資訊，請參閱 功能旗標。

有時候，您必須選擇性地針對特定客戶啟用特定功能。 例如，您可能有不同的 定價層 ，允許存取特定功能。 功能旗標通常不是這些案例的正確選擇。 相反地，請考慮建置程式來追蹤並強制執行每個客戶所擁有的 授權權利 。

要避免的反模式

當您部署和設定多租使用者解決方案時，請務必避免禁止調整規模的情況。 這些選項包括：

• 手動部署和測試。 如上所述，手動部署程式會增加風險，並讓部署速度變慢。 請考慮使用管線進行自動化部署、以程式設計方式從解決方案的程式碼建立資源，或兩者的組合。
• 租使用者的特製化自訂。 避免部署僅適用于單一租使用者的功能或設定。 這種方法會增加部署和測試程式的複雜度。 相反地，針對每個租使用者使用相同的資源類型和程式碼基底，並使用 功能旗 標之類的策略來進行暫時變更，或針對漸進式推出的功能使用 不同的定價層，或使用不同的定價層 搭配授權權利，選擇性地為需要它們的租使用者啟用功能。 即使是具有隔離或專用資源的租使用者，也請使用一致且自動化的部署程式。

租使用者清單作為組態或資料

當您在多租使用者解決方案中部署資源時，可以考慮下列兩種方法：

• 使用自動化部署管線來部署每個資源。 新增租使用者時，請重新設定管線，為每個租使用者布建資源。
• 使用自動化部署管線來部署不相依于租使用者數目的共用資源。 針對針對每個租使用者部署的資源，請在您的應用程式內建立它們。

考慮這兩種方法時，您應該區分將租使用者清單視為設定或資料。 當您考慮如何為系統建置 控制平面 時，此區別也很重要。

租使用者清單作為設定

當您將租使用者清單視為設定時，您會從集中式部署管線部署所有資源。 當新的租使用者上線時，您可以重新設定管線或其參數。 一般而言，重新設定是透過手動變更進行，如下圖所示。

將新租使用者上線的程式可能類似下列：

1. 更新租使用者清單。 這通常是藉由設定管線本身，或修改管線組態中包含的參數檔案，手動進行。
2. 觸發要執行的管線。
3. 管線會重新部署一組完整的 Azure 資源，包括任何新的租使用者特定資源。

這種方法通常適用于少數租使用者，以及共用所有資源的架構。 這是簡單的方法，因為您可以使用單一程式來部署和設定所有 Azure 資源。

不過，當您接近大量租使用者時，例如 5 到 10 或更多，當您新增租使用者時重新設定管線會變得很麻煩。 執行部署管線所需的時間通常也會大幅增加。 這種方法也不容易支援自助式租使用者建立，而且租使用者上線之前的前置時間可能較長，因為您需要觸發管線來執行。

租使用者清單作為資料

當您將租使用者清單視為資料時，您仍會使用管線來部署共用元件。 不過，對於需要為每個租使用者部署的資源和組態設定，您必須以命令方式部署或設定資源。 例如，您的控制平面可以使用 Azure SDK 來建立特定資源，或起始參數化範本的部署。

將新租使用者上線的程式可能類似下列，而且會以非同步方式發生：

1. 要求將租使用者上線，例如，藉由起始 API 要求至系統的控制平面。
2. 工作流程元件會接收建立要求，並協調其餘步驟。
3. 工作流程會起始租使用者特定資源的部署至 Azure。 這可透過使用命令式程式設計模型來達成，例如使用 Azure SDK，或命令式觸發 Bicep 或 Terraform 範本的部署。
4. 部署完成時，工作流程會將新租使用者的詳細資料儲存至中央租使用者目錄。 針對每個租使用者儲存的資料可能包含工作流程所建立之所有租使用者特定資源的租使用者識別碼和資源識別碼。

如此一來，您就可以為新的租使用者布建資源，而不需要重新部署整個解決方案。 為每個租使用者布建新資源所需的時間可能較短，因為只需要部署那些資源。

不過，這種方法通常比較耗時的建置，而您花費的精力必須依租使用者數目或您需要符合的布建時間範圍來對齊。

如需此方法的詳細資訊，請參閱 多租使用者控制平面的考慮。

範例

Contoso 會為其客戶執行多租使用者解決方案。 目前，他們有六個租使用者，且預期在未來 18 個月內成長至 300 個租使用者。 Contoso 會遵循 具有每個租使用者方法專用資料庫的多租使用者應用程式 。 他們已部署單一App Service資源和所有租使用者之間共用的Azure SQL邏輯伺服器，並為每個租使用者部署專用Azure SQL資料庫，如下圖所示。

Contoso 會使用 Bicep 來部署其 Azure 資源。

選項 1 - 針對所有專案使用部署管線

Contoso 可能會考慮使用部署管線部署其所有資源。 其管線會部署 Bicep 檔案，其中包含其所有 Azure 資源，包括每個租使用者的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 的 FastTrack 首席客戶工程師

其他參與者：

• Bohdan Cherchyk |適用于 Azure 的 FastTrack 資深客戶工程師
• Ar | 適用于 Azure 的 FastTrack 首席客戶工程師

若要查看非公用LinkedIn設定檔，請登入 LinkedIn。

下一步

• 檢閱 更新多租使用者解決方案的考慮。
• 請考慮 儲存體和資料的結構方法。
• 請考慮如何在多租使用者解決方案中使用 Azure Resource Manager。