目標型調整

目標型調整可為客戶提供快速且直覺的調整模型，目前支援下列延伸模組：

• Apache Kafka
• Azure Cosmos DB
• Azure 事件中樞
• Azure 佇列儲存體
• Azure 服務匯流排 (佇列和主題)

目標型調整會取代先前的 Azure Functions 累加調整模型，作為這些延伸模組類型的預設值。 累加調整會以每個新的執行個體速率新增或移除最多一個背景工作角色，具有何時調整的複雜決策。 相反地，目標型調整允許一次擴大四個執行個體，而調整決策是以簡單的目標型方程式為基礎：

預設每個執行個體的目標執行值來自 Azure Functions 延伸模組所使用的 SDK。 您不需要對目標型調整進行任何變更即可運作。

考量

使用目標型調整時，請套用下列考量事項：

• 針對使用量方案或進階方案上的函數應用程式，預設會啟用目標型調整，但您可以退出。在專用 (App Service) 方案中執行時，不支援事件驅動調整。
• 預設會在函數應用程式執行階段 4.19.0 或更新版本上啟用目標型調整。
• 使用目標型調整時，仍會接受 functionAppScaleLimit 網站設定。 如需詳細資訊，請參閱限制擴增。
• 若要根據計量達到最精確的調整，每個函數應用程式只能使用一個目標型觸發程序函數。
• 當相同函數應用程式中的多個函式同時要求擴增時，會使用這些函式的總和來判斷所需執行個體中的變更。 要求擴增的函式會覆寫要求縮減的函式。
• 有縮減要求但沒有任何擴增要求時，會使用最大縮減值。

退出

針對使用量方案或進階方案上裝載的函數應用程式，預設會啟用目標型調整。 若要停用目標型調整並復原為累加調整，請將下列應用程式設定新增至函數應用程式：

應用程式設定	值
TARGET_BASED_SCALING_ENABLED	0

自訂目標型調整

您可以藉由調整每個執行個體的目標執行，根據應用程式的工作負載，變更調整行為的積極程度。 每個延伸模組都有不同的設定，可用來設定每個執行個體的目標執行。

下表摘要說明用於每個執行個體的目標執行值的 host.json 值和預設值：

副檔名	host.json 值	預設值
事件中樞 (延伸模組 v5.x+)	extensions.eventHubs.maxEventBatchSize	100*
事件中樞 (延伸模組 v3.x+)	extensions.eventHubs.eventProcessorOptions.maxBatchSize	10
事件中樞 (如果已定義)	extensions.eventHubs.targetUnprocessedEventThreshold	n/a
服務匯流排 (延伸模組 v5.x+，單一分派)	extensions.serviceBus.maxConcurrentCalls	16
服務匯流排 (延伸模組 v5.x+，以單一分派工作階段為基礎)	extensions.serviceBus.maxConcurrentSessions	8
服務匯流排 (延伸模組 v5.x+，批次處理)	extensions.serviceBus.maxMessageBatchSize	1000
服務匯流排 (Functions v2.x+，單一分派)	extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls	16
服務匯流排 (Functions v2.x+，以單一分派工作階段為基礎)	extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions	2000
服務匯流排 (Functions v2.x+，批次處理)	extensions.serviceBus.batchOptions.maxMessageCount	1000
儲存體佇列	extensions.queues.batchSize	16

^* 預設 maxEventBatchSize 在 Microsoft.Azure.WebJobs.Extensions.EventHubs 套件的 v6.0.0 中已變更。 在舊版中，此值為 10。

針對某些繫結延伸模組，每個執行個體的目標執行是使用函式屬性來設定：

副檔名	函式觸發程序設定	預設值
Apache Kafka	lagThreshold	1000
Azure Cosmos DB	maxItemsPerInvocation	100

若要深入了解，請參閱支援延伸模組的範例設定。

已啟用執行階段調整監視的進階方案

啟用執行階段調整監視時，延伸模組本身會處理動態調整。 這是因為調整控制器無法存取虛擬網路所保護的服務。 啟用執行階段調整監視之後，您必須將延伸模組套件升級至這些最低版本，以解除鎖定額外的目標型調整功能：

Extension Name	所需的最低版本
Apache Kafka	3.9.0
Azure Cosmos DB	4.1.0
事件中樞	5.2.0
服務匯流排	5.9.0
儲存體佇列	5.1.0

動態並行支援

目標型調整引進了更快的調整速度，並使用每個執行個體的目標執行的預設值。 使用服務匯流排、儲存體佇列或 Kafka 時，您也可以啟用動態並行。 在此設定中，每個執行個體的目標執行值是由動態並行功能自動決定。 會從有限的並行開始，並隨著時間識別最佳設定。

支援的擴充功能

您在 host.json 檔案中設定目標型調整的方式取決於特定延伸模組類型。 本節提供目前支援目標型調整之延伸模組的設定詳細資料。

服務匯流排佇列與主題

服務匯流排延伸模組支援三個執行模型，由服務匯流排觸發程序的 IsBatched 和 IsSessionsEnabled 屬性決定。 IsBatched 和 IsSessionsEnabled 的預設值為 false。

執行模型	IsBatched	IsSessionsEnabled	用於每個執行個體的目標執行的設定
單一分派處理	false	false	maxConcurrentCalls
單一分派處理 (工作階段型)	false	true	maxConcurrentSessions
批次處理	true	false	maxMessageBatchSize or maxMessageCount

注意

調整效率：針對服務匯流排延伸模組，請對資源使用管理權限，以獲得最有效率的調整。 使用接聽權限時，調整會還原為累加調整，因為佇列或主題長度無法用來通知調整決策。 若要深入了解在服務匯流排存取原則中設定權限，請參閱共用存取授權原則。

單一分派處理

在此模型中，函式的每個引動過程都會處理單一訊息。 maxConcurrentCalls 設定會控管每個執行個體的目標執行。 特定設定取決於服務匯流排延伸模組的版本。

v5.x+

修改 host.json 設定 maxConcurrentCalls，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentCalls": 16
        }
    }
}

v2.x+

修改 messageHandlerOptions 中的 host.json 設定 maxConcurrentCalls，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "messageHandlerOptions": {
                "maxConcurrentCalls": 16
            }
        }
    }
}

單一分派處理 (工作階段型)

在此模型中，函式的每個引動過程都會處理單一訊息。 不過，視服務匯流排主題或佇列的作用中工作階段數目而定，每個執行個體都會租用一或多個工作階段。 特定設定取決於服務匯流排延伸模組的版本。

v5.x+

修改 host.json 設定 maxConcurrentSessions 以設定每個執行個體的目標執行，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentSessions": 8
        }
    }
}

v2.x+

修改 sessionHandlerOptions 中的 host.json 設定 maxConcurrentSessions 以設定每個執行個體的目標執行，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "sessionHandlerOptions": {
                "maxConcurrentSessions": 2000
            }
        }
    }
}

批次處理

在此模型中，函式的每個引動過程都會處理訊息批次。 特定設定取決於服務匯流排延伸模組的版本。

v5.x+

修改 host.json 設定 maxMessageBatchSize 以設定每個執行個體的目標執行，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxMessageBatchSize": 1000
        }
    }
}

v2.x+

修改 batchOptions 中的 host.json 設定 maxMessageCount 以設定每個執行個體的目標執行，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "batchOptions": {
                "maxMessageCount": 1000
            }
        }
    }
}

事件中樞

針對 Azure 事件中樞，Azure Functions 會根據分散在事件中樞內所有分割區的未處理事件數目進行調整。 根據預設，用於每個執行個體的目標執行的 host.json 屬性是 maxEventBatchSize 和 maxBatchSize。 不過，如果您選擇微調目標型調整，您可以定義個別參數 targetUnprocessedEventThreshold，覆寫以設定每個執行個體的目標執行，而不需變更批次設定。 如果設定了 targetUnprocessedEventThreshold，未處理事件計數總計會除以此值來決定執行個體數目，然後四捨五入至建立平衡分割區散發的背景工作角色執行個體計數。

注意

由於事件中樞是分割工作負載，因此事件中樞的目標執行個體計數會以事件中樞的分割區數目為上限。

特定設定取決於事件中樞延伸模組的版本。

v5.x+

修改 host.json 設定 maxEventBatchSize 以設定每個執行個體的目標執行，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "maxEventBatchSize" : 100
        }
    }
}

在 host.json 中定義時，targetUnprocessedEventThreshold 會用來作為每個執行個體的目標執行，而不是 maxEventBatchSize，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "targetUnprocessedEventThreshold": 153
        }
    }
}

v3.x+

針對事件中樞延伸模組的 v3.x+，請修改 eventProcessorOptions 底下的 host.json 設定 maxBatchSize，以設定每個執行個體的目標執行：

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "eventProcessorOptions": {
                "maxBatchSize": 10
            }
        }
    }
}

在 host.json 中定義時，targetUnprocessedEventThreshold 會用來作為每個執行個體的目標執行，而不是 maxBatchSize，如下列範例所示：

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "targetUnprocessedEventThreshold": 23
        }
    }
}

儲存體佇列

針對儲存體延伸模組的 v2.x+，請修改 host.json 設定 batchSize 以設定每個執行個體的目標執行：

{
    "version": "2.0",
    "extensions": {
        "queues": {
            "batchSize": 16
        }
    }
}

注意

調整效率：針對儲存體佇列延伸模組，儲存體佇列 API 仍會將具有 visibilityTimeout 的訊息計入事件來源長度中。 這可能會導致函數應用程式的過度調整。 請考慮使用服務匯流排佇列排程訊息，限制擴增，或不要針對您的解決方案使用 visibilityTimeout。

Azure Cosmos DB

Azure Cosmos DB 會使用函式層級屬性，MaxItemsPerInvocation。 您設定此函式層級屬性的方式取決於您的函式語言。

C#

針對編譯的 C# 函式，請在觸發程序定義中設定 MaxItemsPerInvocation，如下列內含式 C# 函式的範例所示：

namespace CosmosDBSamplesV2
{
    public static class CosmosTrigger
    {
        [FunctionName("CosmosTrigger")]
        public static void Run([CosmosDBTrigger(
            databaseName: "ToDoItems",
            collectionName: "Items",
            MaxItemsPerInvocation: 100,
            ConnectionStringSetting = "CosmosDBConnection",
            LeaseCollectionName = "leases",
            CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> documents,
            ILogger log)
        {
            if (documents != null && documents.Count > 0)
            {
                log.LogInformation($"Documents modified: {documents.Count}");
                log.LogInformation($"First document Id: {documents[0].Id}");
            }
        }
    }
}

Java

暫止的 Java 範例。

Python

對於使用 function.json 的 Functions 語言，MaxItemsPerInvocation 參數會定義於特定繫結中，如同此 Azure Cosmos DB 觸發程序範例所示

{
    "scriptFile": "main.py",
    "bindings": [
        {
          "type": "cosmosDBTrigger",
          "maxItemsPerInvocation": 100,
          "connection": "MyCosmosDb",
          "leaseContainerName": "leases",
          "containerName": "collectionName",
          "databaseName": "databaseName",
          "leaseDatabaseName": "databaseName",
          "createLeaseContainerIfNotExists": false,
          "startFromBeginning": false,
          "name": "input"
        }
    ]
}

尚未提供 Python v2 程式設計模型的範例。

JavaScript/PowerShell/TypeScript

對於使用 function.json 的 Functions 語言，MaxItemsPerInvocation 參數會定義於特定繫結中，如同此 Azure Cosmos DB 觸發程序範例所示：

{
  "bindings": [
    {
      "type": "cosmosDBTrigger",
      "maxItemsPerInvocation": 100,
      "connection": "MyCosmosDb",
      "leaseContainerName": "leases",
      "containerName": "collectionName",
      "databaseName": "databaseName",
      "leaseDatabaseName": "databaseName",
      "createLeaseContainerIfNotExists": false,
      "startFromBeginning": false,
      "name": "input"
    }
  ]
}

尚未提供 Node.js v4 程式設計模型的範例。

注意

由於 Azure Cosmos DB 是分割工作負載，因此資料庫的目標執行個體計數會以容器的實體分割區數目為上限。 若要深入了解 Azure Cosmos DB 調整，請參閱實體分割區和租用所有權。

Apache Kafka

Apache Kafka 延伸模組會使用函式層級屬性，LagThreshold。 針對 Kafka，所需執行個體的數目是根據取用者延遲總數除以 LagThreshold 設定來計算。 針對指定的延遲，減少延遲閾值會增加所需執行個體的數目。

您設定此函式層級屬性的方式取決於您的函式語言。 此範例會將閾值設定為 100。

C#

針對編譯的 C# 函式，請在觸發程序定義中設定 LagThreshold，如 Kafka 事件中樞觸發程序的下列內含式 C# 函式範例所示：

[FunctionName("KafkaTrigger")]
public static void Run(
    [KafkaTrigger("BrokerList",
                  "topic",
                  Username = "$ConnectionString",
                  Password = "%EventHubConnectionString%",
                  Protocol = BrokerProtocol.SaslSsl,
                  AuthenticationMode = BrokerAuthenticationMode.Plain,
                  ConsumerGroup = "$Default",
                  LagThreshold = 100)] KafkaEventData<string> kevent, ILogger log)
{            
    log.LogInformation($"C# Kafka trigger function processed a message: {kevent.Value}");
}

Java

public class KafkaTriggerMany {
    @FunctionName("KafkaTriggerMany")
    public void runMany(
            @KafkaTrigger(
                name = "kafkaTriggerMany",
                topic = "topic",  
                brokerList="%BrokerList%",
                consumerGroup="$Default", 
                username = "$ConnectionString", 
                password = "EventHubConnectionString",
                authenticationMode = BrokerAuthenticationMode.PLAIN,
                protocol = BrokerProtocol.SASLSSL,
                LagThreshold = 100,
                // sslCaLocation = "confluent_cloud_cacert.pem", // Enable this line for windows.
                cardinality = Cardinality.MANY,
                dataType = "string"
             ) String[] kafkaEvents,
            final ExecutionContext context) {
            for (String kevent: kafkaEvents) {
                context.getLogger().info(kevent);
            }

Python

對於使用 function.json 的 Functions 語言，LagThreshold 參數會定義於特定繫結中，如同此 Kafka 事件中樞觸發程序範例所示：

{
      "scriptFile": "main.py",
      "bindings": [
        {
          "type": "kafkaTrigger",
          "name": "kevent",
          "topic": "topic",
          "brokerList": "%BrokerList%",
          "username": "$ConnectionString",
          "password": "EventHubConnectionString",
          "consumerGroup" : "functions",
          "protocol": "saslSsl",
          "authenticationMode": "plain",
          "lagThreshold": "100"
        }
    ]
}

Kafka 延伸模組目前不支援 Python v2 程式設計模型。

JavaScript/PowerShell/TypeScript

對於使用 function.json 的 Functions 語言，LagThreshold 參數會定義於特定繫結中，如同此 Kafka 事件中樞觸發程序範例所示：

{
    "bindings": [
      {
            "type": "kafkaTrigger",
            "name": "kafkaEvent",
            "direction": "in",
            "protocol" : "SASLSSL",
            "password" : "EventHubConnectionString",
            "dataType" : "string",
            "topic" : "topic",
            "authenticationMode" : "PLAIN",
            "consumerGroup" : "$Default",
            "username" : "$ConnectionString",
            "brokerList" : "%BrokerList%",
            "sslCaLocation": "confluent_cloud_cacert.pem",
            "lagThreshold": "100"
        }
    ]
}

Kafka 延伸模組目前不支援 Node.js v4 程式設計模型。

下一步

如需詳細資訊，請參閱下列文章：

• 改善 Azure Functions 的效能與可靠性
• Azure Functions 可靠的事件處理