Azure Logic Apps 的限制和組態參考

針對取用邏輯應用程式工作流程，相同的設定可控制工作流程可執行的天數上限，以及保留記憶體中的執行歷程記錄。

• 在多租使用者 Azure Logic Apps 中，90 天的預設限制與上限相同。 您只能減少此值。

例如，假設您將保留限制從90天減少到30天。 已從執行歷程記錄中移除 60 天的舊回合。 如果您將保留期間從 30 天增加到 60 天，則 20 天的執行歷程記錄會持續 40 天。

入口網站

1. 在 [Azure 入口網站 搜尋] 方塊中，在設計工具中開啟邏輯應用程式工作流程。

2. 在邏輯應用程式功能表上，選取 [工作流程設定]。

3. 在 [運行時間選項] 底下，從 [以天為單位的執行歷程記錄保留] 清單中，選取 [自定義]。

4. 拖曳滑桿以變更您想要的天數。

5. 完成時，在 [ 工作流程設定 ] 工具列上，選取 [ 儲存]。

ARM 範本

如果您使用 Azure Resource Manager 範本，此設定會顯示為工作流程資源定義中的屬性，如 Microsoft.Logic workflows 範本參考中所述：

{
   "name": "{logic-app-name}",
   "type": "Microsoft.Logic/workflows",
   "location": "{Azure-region}",
   "apiVersion": "2019-05-01",
   "properties": {
      "definition": {},
      "parameters": {},
      "runtimeConfiguration": {
         "lifetime": {
            "unit": "day",
            "count": {number-of-days}
         }
      }
   }
}

針對標準邏輯應用程式工作流程，您可以減少或增加 90 天的預設限制，但您需要將下列設定及其值新增至邏輯應用程式資源或專案：

• 名為 Workflows.RuntimeConfiguration.RetentionInDays 的應用程式設定

• 名為 Runtime.FlowMaintenanceJob.RetentionCooldownInterval 的主機設定

根據預設，名為 Workflows.RuntimeConfiguration.RetentionInDays 的應用程式設定會設定為保留 90 天的數據。 名為 Runtime.FlowMaintenanceJob.RetentionCooldownInterval 的主機設定會設定為每隔 7 天檢查要刪除的舊數據。 如果您保留這些預設值，您可能會看到最多 97 天的數據。 例如，假設 Azure Logic Apps 會檢查第 X 天，並刪除早於第 X 天 - 90 天的數據，然後等候 7 天再執行一次。 此行為會導致工作再次執行前97天超過97天的數據。 不過，如果您將間隔設定為1天，但保留天數保留為預設值，則刪除舊數據的最大延遲為90+1天。

入口網站

1. 請遵循下列步驟來新增名為 Workflows.RuntimeConfiguration.RetentionInDays 的應用程式設定，並將值設定為您想要保留工作流程執行歷程記錄的天數。

2. 請依照下列步驟新增名為 Runtime.FlowMaintenanceJob.RetentionCooldownInterval 的主機設定，並將值設定為檢查和刪除您不想保留的執行歷程記錄之間的間隔天數。

Visual Studio Code

1. 請遵循下列步驟來新增名為 Workflows.RuntimeConfiguration.RetentionInDays 的應用程式設定，並將值設定為您想要保留工作流程執行歷程記錄的天數。

2. 請依照下列步驟新增名為 Runtime.FlowMaintenanceJob.RetentionCooldownInterval 的主機設定，並將值設定為檢查和刪除您不想保留的執行歷程記錄之間的間隔天數。

在單一租使用者 Azure Logic Apps 中，標準邏輯應用程式資源會使用記憶體和計算作為執行工作流程的主要資源。

儲存體

單一租使用者 Azure Logic Apps 中的具狀態工作流程會在運行時間使用 Azure 數據表記憶體進行永續性數據記憶體、Azure Blob 儲存體 維護工作流程執行歷程記錄，以及用於排程用途的 Azure 佇列記憶體。 例如，單一記憶體帳戶可讓您處理大量要求，每個分割區最多 2,000 個要求，以及記憶體帳戶層級每秒 20,000 個要求。 雖然單一記憶體帳戶可以處理相當高的輸送量，但超過這些閾值，要求率會受限於節流，而您的工作流程可能會在工作流程執行速率增加時遇到分割區層級節流或帳戶層級節流。 為了確保工作流程運作順利，請務必瞭解可能的限制，以及解決這些限制的方式。

如需調整各種 Azure 儲存體 服務之目標和限制的詳細資訊，請參閱下列檔：

• 調整數據表記憶體的目標
• 數據表記憶體的數據作業目標
• 調整 Blob 記憶體的目標
• 調整佇列記憶體的目標

調整邏輯應用程式以取得記憶體限制

下列建議適用於調整標準邏輯應用程式工作流程：

• 跨多個工作流程共用工作負載。

  單一租使用者 Azure Logic Apps 已透過將記憶體交易分散到多個分割區，將分割區層級的節流降到最低。 不過，若要改善散發並減輕數據分割層級的節流， 請將工作負載分散到多個工作流程，而不是依賴單一工作流程。

• 跨多個記憶體帳戶共用工作負載。

  如果您的工作流程需要高輸送量，您可以將工作負載分散到多個記憶體帳戶，而不是依賴單一儲存器帳戶來大幅增加輸送量。 您可以設定標準邏輯應用程式資源，以使用最多 32 個記憶體帳戶作為限制。 若要判斷您需要的記憶體帳戶數目，請使用每個記憶體帳戶每個分鐘 ~100,000 個動作執行的一般指導方針。 雖然此估計適用於大部分案例，但如果您的工作流程動作計算繁重，您可能會使用較少的動作執行次數，例如處理大型數據陣列的查詢動作。 在生產環境中使用之前，請確定您先執行負載測試和微調解決方案。

  若要啟用使用多個記憶體帳戶，請先遵循下列步驟，再建立標準邏輯應用程式。 否則，如果您在建立之後變更設定，可能會遇到數據遺失或無法達到必要的延展性。

  1. 建立您想要使用的記憶體帳戶 。 儲存每個記憶體帳戶的 連接字串。

  2. 尋找並開啟您的標準邏輯應用程式，然後編輯邏輯應用程式的主機設定（host.json檔案），以包含下列extensions物件，其中包含 workflow Runtime.ScaleUnitsCount 設定的 和 settings 物件：

     "extensions": {
         "workflow": {
             "settings": {
                 "Runtime.ScaleUnitsCount": "<storage-accounts-number>"
             }
         }
     }
     

     下列範例會將 3 指定為記憶體帳戶的數目：

     {
         "version": "2.0",
         "extensionBundle": {
             "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
             "version": "[1.*, 2.0.0)"
         },
         "extensions": {
             "workflow": {
                 "settings": {
                     "Runtime.ScaleUnitsCount": "3"
                 }
             }
         }
     }
     

  3. 編輯邏輯應用程式的應用程式組態設定（local.settings.json），以新增名為 CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU0<storage-account-number> 的應用程式設定。ConnectionString 和對應的記憶體帳戶 連接字串 使用下列語法，其中第一個記憶體帳戶號碼00最多為記憶體帳戶數目減 1，例如：

     應用程式設定名稱	值
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString	<connection-string-1>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString	<connection-string-2>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString	<connection-string-3>

     重要

     當您有敏感性資訊時，例如包含使用者名稱和密碼的連接字串，請務必使用可用的最安全驗證流程。 例如，在標準邏輯應用程式工作流程中，不支援安全資料類型，例如 securestring 和 secureobject。 Microsoft 建議您盡可能使用受控識別驗證 Azure 資源的存取權，並指派具有最低必要權限的角色。

     如果無法使用這項功能，請務必透過其他方法 (例如可與應用程式設定搭配使用的 Azure Key Vault) 來保護連接字串。 然後您可以直接參考安全字串，例如連接字串和金鑰。 類似於您可以於部署期間定義環境變數的 ARM 範本，您可以在邏輯應用程式工作流程定義中定義應用程式設定。 然後，您可以擷取動態產生的基礎結構值，例如連線端點、儲存體字串等等。 如需詳細資訊，請參閱 Microsoft 身分識別平台的應用程式類型。

  4. 在邏輯應用程式的應用程式組態設定中，將 AzureWebJobsStorage 設定值更新為 CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString 設定中的相同 連接字串。

計算

標準邏輯應用程式會使用其中一個可用的計算計劃來執行，其可提供不同層級的虛擬 CPU 和記憶體，或使用提供更多計算選項的 App Service 環境 v3。

單一租使用者 Azure Logic Apps 會動態調整，以有效處理增加的負載。 邏輯應用程式會使用下列主要因素來判斷是否要調整。

• 觸發程序

  為了判斷調整需求，調整器會分析觸發程式，以在邏輯應用程式中啟動每個工作流程。 例如，對於具有 服務匯流排 觸發程式的工作流程，如果佇列長度持續成長，調整器會採取動作來新增背景工作實例，以啟用處理更多訊息。 同樣地，對於具有要求觸發程式的工作流程，如果要求延遲發生上升趨勢，縮放器會增加背景工作實例數目，以更有效率地分散要求負載。 如需背景工作實例的詳細資訊，請參閱 Azure Logic Apps （標準） - 運行時間深入探討。

• 工作流程作業執行延遲

  在運行時間，工作流程動作會分成已排入佇列以供執行的個別作業。 作業發送器會定期輪詢作業佇列以擷取和執行這些作業。 不過，如果計算容量不足以接下這些作業，作業留在佇列的時間會延長，導致執行延遲增加。 縮放程式會監視這種情況，並做出調整決策，以控制執行延遲。 如需運行時間排程和執行作業方式的詳細資訊，請參閱 Azure Logic Apps （標準） - 運行時間深入探討。

  調整器也會考慮最小和最大背景工作實例計數器組態，以判斷是否要做出調整決策，例如新增、移除或維護目前的背景工作實例數目。 一般而言，縮放器會以大約 15-30 秒的間隔做出這些決策。 因此，請考慮此增加時間及其對邏輯應用程式調整速度的影響，以有效處理尖峰負載。 例如，如果您的工作負載需要將邏輯應用程式從 1 個背景工作實例調整為 100 個背景工作實例，單靠增加可能需要 25-50 分鐘。 單一租使用者 Azure Logic Apps 調整共用相同的 Azure Functions 調整基礎結構。

設定邏輯應用程式計算以加快調整速度

• 跨多個邏輯應用程式共用工作負載。

  每個邏輯應用程式都可以獨立調整，因此將工作負載分散到多個邏輯應用程式可以大幅加速調整速度。 例如，兩個邏輯應用程式可以調整為與單一邏輯應用程式相同時間範圍內背景工作實例數目的兩倍。 藉由將工作負載分割到多個應用程式，您可以有效地將延展性乘以達到更快的調整結果。

• 使用預先設定的實例。

  如果您的案例需要更快的加速時間，請考慮使用預先設定的實例。 如果您的尖峰負載時間具決定性，您可以使用自動化工作，依排程調整這些前置實例。 如需詳細資訊，請參閱建立自動化工作來管理 Azure 資源和監視成本（預覽版）。

多租使用者 Azure Logic Apps 對每 5 分鐘執行的動作數目有 預設限制 。 若要將預設值提升為 最大值，您可以啟用處於預覽狀態的高輸送量模式。 或者， 將工作負載分散到多個邏輯應用程式和工作流程，而不是依賴單一邏輯應用程式和工作流程。

在入口網站中啟用高輸送量

1. 在 Azure 入口網站 的邏輯應用程式功能表上，於 [設定] 底下選取 [工作流程設定]。

2. 在 [運行時間選項>高輸送量] 下，將設定變更為 [開啟]。

   

在 Resource Manager 樣本中啟用高輸送量

若要在 ARM 樣本中啟用此設定以部署邏輯應用程式，請在properties邏輯應用程式資源定義的物件中，將 屬性設定為 的物件operationOptions新增runtimeConfiguration為 OptimizedForHighThroughput：

{
   <template-properties>
   "resources": [
      // Start logic app resource definition
      {
         "properties": {
            <logic-app-resource-definition-properties>,
            <logic-app-workflow-definition>,
            <more-logic-app-resource-definition-properties>,
            "runtimeConfiguration": {
               "operationOptions": "OptimizedForHighThroughput"
            }
         },
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {},
         "apiVersion": "2016-06-01",
         "dependsOn": [
         ]
      }
      // End logic app resource definition
   ],
   "outputs": {}
}

如需邏輯應用程式資源定義的詳細資訊，請參閱 概觀：使用 Azure Resource Manager 範本自動部署 Azure Logic Apps。