目標型調整可為客戶提供快速且直覺的調整模型，目前支援下列繫結延伸模組：
目標型調整會取代先前的 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 |
* 預設 maxEventBatchSize 在 Microsoft.Azure.WebJobs.Extensions.EventHubs 套件的 v6.0.0 中已變更。 在舊版中，此值為 10。
針對某些繫結延伸模組，每個執行個體的目標執行組態是使用函式屬性來設定：
| 分機 | 函式觸發程序設定 | 預設值 |
|---|---|---|
| Apache Kafka | lagThreshold |
1000 |
| Azure Cosmos DB | maxItemsPerInvocation |
100 |
若要深入了解，請參閱支援延伸模組的範例設定。
已啟用執行階段調整監視的進階方案
啟用執行階段調整監視時，延伸模組本身會處理動態調整，因為調整控制器無法存取受虛擬網路保護的服務。 啟用執行階段調整監視之後，您必須將延伸模組套件升級至這些最低版本，以解除鎖定額外的目標型調整功能：
| 擴充功能名稱 | 所需的最低版本 |
|---|---|
| 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 設定會控管每個執行個體的目標執行。 特定設定取決於服務匯流排延伸模組的版本。
修改 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 屬性是 maxEventBatchSize 和 maxBatchSize。 不過，如果您選擇微調目標型調整，您可以定義個別參數 targetUnprocessedEventThreshold，覆寫以設定每個執行個體的目標執行，而不需變更批次設定。 如果設定了 targetUnprocessedEventThreshold，未處理事件計數總計會除以此值來決定執行個體數目，然後四捨五入至建立平衡分割區散發的背景工作角色執行個體計數。
警告
對於受目標型縮放支援的託管方案，將 batchCheckpointFrequency 設定大於 1，可能會導致錯誤的縮放行為。 平台會將未處理的事件計算為「目前位置 - 檢查點位置」，當批次已處理但尚建立檢查點時，這可能會錯誤指出未處理的訊息，導致在沒有剩餘訊息時無法正確縮減規模。
縮放行為與穩定性
對於事件中樞，頻繁的縮減或擴增作業可能會觸發分割區重新平衡，進而導致處理延遲和延遲增加。 為了減輕此問題：
- 該平台會使用預先定義的有效背景工作角色計數清單來指導擴增決策。
- 該平台會確保擴增作業穩定且具有計畫，避免對分割區指派造成破壞性的變更。
- 如果所需的背景工作角色計數不在有效的清單中 (例如 17)，系統會自動選取下一個最大的有效計數 (在此例中為 32)。 此外，為防止快速重複擴縮，縮減要求會在最後一次向上擴充後被限制 3 分鐘。 此延遲有助於減少不必要的重新平衡，並有助於維持輸送量效率。
事件中樞的有效執行個體計數
對於每個事件中樞分割區計數，我們會計算對應的有效執行個體計數清單，以確保最佳的分佈和有效率的調整。 選擇這些計數是為了與分割和並行需求良好地保持一致：
| 分割計數 | 有效的執行個體計數 |
|---|---|
| 1 | [1] |
| 2 | [1, 2] |
| 4 | [1, 2, 4] |
| 8 | [1, 2, 3, 4, 8] |
| 10 | [1, 2, 3, 4, 5, 10] |
| 16 | [1, 2, 3, 4, 5, 6, 8, 16] |
| 32 | [1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 16, 32] |
這些預先定義的計數有助於確保執行個體在各分割區之間盡可能地平均分佈，從而將閒置或過載的背景工作角色數降至最低。
附註
附註：對於進階版和專用事件中樞層，分割區計數可以超過 32，允許更大的有效執行個體計數集。 這些層級支援更高的輸送量與可擴縮性，並相應地擴充有效的背景工作角色計數清單，以便將事件中樞的分割區平均分散到各執行個體。 此外，由於事件中樞是分割的工作負載，因此事件中樞中的分割區數目是最大目標執行個體計數的上限。
事件中樞設定
特定設定取決於事件中樞延伸模組的版本。
修改 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}");
}
}
}
}
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}");
}
後續步驟
如需詳細資訊，請參閱下列文章：