共用方式為


目標型調整

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

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

方程式圖表:所需的執行個體 = 事件來源長度/每個執行個體的目標執行。

在此方程式中, 事件來源長度 是指必須處理的事件數目。 預設每個執行個體的目標執行值來自 Azure Functions 延伸模組所使用的 SDK。 您不需要對目標型調整進行任何變更即可運作。

考量

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

  • 根據預設,使用量方案Flex 使用量方案彈性進階方案上,都會針對函數應用程式啟用以目標為基礎的縮放。 在專用 (App Service) 方案中執行時,不支援事件驅動調整。
  • 從 Functions 執行階段 4.19.0 版開始,預設會啟用以目標為基礎的縮放。
  • 當您使用以目標為基礎的縮放時,仍須遵循縮放限制。 如需詳細資訊,請參閱限制擴增
  • 若要根據計量達到最精確的調整,每個函數應用程式只能使用一個目標型觸發程序函數。 您也應該考慮在 Flex 使用量方案中執行,其提供個別函式縮放
  • 當相同函數應用程式中的多個函式同時要求擴增時,會使用這些函式的總和來判斷所需執行個體中的變更。 要求擴增的函式會覆寫要求縮減的函式。
  • 有縮減要求但沒有任何擴增要求時,會使用最大縮減值。

退出

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

應用程式設定
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

* 預設 maxEventBatchSizeMicrosoft.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 檔案中設定目標型調整的方式取決於特定延伸模組類型。 本節提供目前支援目標型調整之延伸模組的設定詳細資料。

服務匯流排佇列與主題

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

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

注意

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

單一分派處理

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

修改 host.json 設定 maxConcurrentCalls,如下列範例所示:

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

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

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

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

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

批次處理

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

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

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

事件中樞

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

注意

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

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

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

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

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

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

儲存體佇列

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

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

注意

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

Azure Cosmos DB

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

針對編譯的 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}");
            }
        }
    }
}

注意

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

Apache Kafka

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

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

針對編譯的 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}");
}

下一步

如需詳細資訊,請參閱下列文章: