التحجيم المستند إلى الهدف

يوفر التحجيم المستند إلى الهدف نموذج تحجيم سريع وبديهي للعملاء وهو مدعوم حاليا لملحقات الربط هذه:

• Apache Kafka
• Azure Cosmos DB
• مراكز أحداث Azure
• تخزين قائمة انتظار Azure
• ناقل خدمة Azure (قائمة الانتظار والموضوعات)

يحل التحجيم المستند إلى الهدف محل نموذج التحجيم التزايدي السابق ل Azure Functions باعتباره النموذج الافتراضي لأنواع الملحقات هذه. أضاف التحجيم التزايدي أو أزل عامل واحد كحد أقصى في كل معدل مثيل جديد، مع قرارات معقدة حول وقت التحجيم. في المقابل، يسمح التحجيم المستند إلى الهدف بزيادة أربعة مثيلات في كل مرة، ويستند قرار التحجيم إلى معادلة بسيطة تستند إلى الهدف:

تأتي عمليات التنفيذ الهدف الافتراضية لكل قيم مثيل من SDKs المستخدمة بواسطة ملحقات Azure Functions. لا تحتاج إلى إجراء أي تغييرات للتحجيم المستند إلى الهدف للعمل.

الاعتبارات

تنطبق الاعتبارات التالية عند استخدام التحجيم المستند إلى الهدف:

• يتم تمكين التحجيم المستند إلى الهدف بشكل افتراضي لتطبيقات الوظائف على خطة الاستهلاك وخطة Flex Consumption وخطط Elastic Premium. لا يتم دعم التحجيم المستند إلى الحدث عند التشغيل على خطط مخصصة (خدمة التطبيقات).
• يتم تمكين التحجيم المستند إلى الهدف بشكل افتراضي بدءا من الإصدار 4.19.0 من وقت تشغيل الوظائف.
• عند استخدام التحجيم المستند إلى الهدف، لا يزال يتم الالتزام بحدود المقياس. لمزيد من المعلومات، راجع الحد الأقصى للتحجيم.
• لتحقيق التحجيم الأكثر دقة استنادا إلى المقاييس، استخدم وظيفة واحدة فقط يتم تشغيلها استنادا إلى الهدف لكل تطبيق وظيفة. يجب عليك أيضا التفكير في التشغيل في خطة استهلاك Flex، والتي تقدم تحجيم لكل وظيفة.
• عندما تطلب دوال متعددة في نفس تطبيق الوظائف توسيع النطاق في نفس الوقت، يتم استخدام مجموع عبر هذه الوظائف لتحديد التغيير في المثيلات المطلوبة. الوظائف التي تطلب توسيع نطاق دوال التجاوز التي تطلب التحجيم.
• عند وجود طلبات تحجيم دون أي طلبات توسيع، يتم استخدام الحد الأقصى للمقياس في القيمة.

إلغاء الاشتراك

يتم تمكين التحجيم المستند إلى الهدف بشكل افتراضي لتطبيقات الوظائف المستضافة على خطة الاستهلاك أو على خطط Premium. لتعطيل التحجيم المستند إلى الهدف والعودة إلى التحجيم التزايدي، أضف إعداد التطبيق التالي إلى تطبيق الوظائف:

إعداد التطبيق	القيمة‬
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	غير متوفر
Service Bus (Extension v5.x+, Single Dispatch)	extensions.serviceBus.maxConcurrentCalls	16
ناقل خدمة Microsoft Azure (Extension v5.x+، Single Dispatch Sessions Based)	extensions.serviceBus.maxConcurrentSessions	8
ناقل خدمة Microsoft Azure (ملحق v5.x+، معالجة الدفعات)	extensions.serviceBus.maxMessageBatchSize	1000
Service Bus (Functions v2.x+, Single Dispatch)	extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls	16
ناقل خدمة Microsoft Azure (الوظائف v2.x+، يستند إلى جلسات الإرسال الأحادية)	extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions	2000
ناقل خدمة Microsoft Azure (الوظائف v2.x+، معالجة الدفعات)	extensions.serviceBus.batchOptions.maxMessageCount	1000
قائمة انتظار التخزين	extensions.queues.batchSize	16

^* تم تغيير الافتراضي maxEventBatchSize في v6.0.0 من الحزمة Microsoft.Azure.WebJobs.Extensions.EventHubs . في الإصدارات السابقة، كانت هذه القيمة 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

دعم التزامن الديناميكي

يقدم التحجيم المستند إلى الهدف تحجيما أسرع، ويستخدم الإعدادات الافتراضية لعمليات التنفيذ المستهدفة لكل مثيل. عند استخدام ناقل خدمة Microsoft Azure أو قوائم انتظار التخزين أو Kafka، يمكنك أيضا تمكين التزامن الديناميكي. في هذا التكوين، يتم تحديد عمليات التنفيذ المستهدفة لكل قيمة مثيل تلقائيا بواسطة ميزة التزامن الديناميكي. يبدأ بتزامن محدود ويحدد أفضل إعداد بمرور الوقت.

الملحقات المدعومة

تعتمد الطريقة التي تقوم بها بتكوين التحجيم المستند إلى الهدف في ملف host.json على نوع الملحق المحدد. يوفر هذا القسم تفاصيل التكوين للملحقات التي تدعم حاليا التحجيم المستند إلى الهدف.

قوائم انتظار ناقل خدمة Azure والموضوعات

يدعم ملحق ناقل خدمة Microsoft Azure ثلاثة نماذج تنفيذ، يتم تحديدها بواسطة IsBatched سمات و IsSessionsEnabled لمشغل ناقل خدمة Microsoft Azure. القيمة الافتراضية ل IsBatched و IsSessionsEnabled هي false.

نموذج التنفيذ	IsBatched	IsSessionsEnabled	الإعداد المستخدم لعمليات التنفيذ المستهدفة لكل مثيل
معالجة الإرسال الفردي	true	true	الحد الأقصى للمكالمات المتزامنة
معالجة الإرسال الفردي (المستندة إلى الجلسة)	true	صحيح	الحد الأقصى للجلسات المتزامنة
معالجة الدُفعات	صحيح	true	maxMessageBatchSize أو maxMessageCount

إشعار

كفاءة المقياس: لملحق ناقل خدمة Microsoft Azure، استخدم إدارة الحقوق على الموارد للتحجيم الأكثر كفاءة. مع تحجيم حقوق الاستماع يعود إلى مقياس تزايدي لأنه لا يمكن استخدام طول قائمة الانتظار أو الموضوع لإبلاغ قرارات التحجيم. لمعرفة المزيد حول تعيين الحقوق في نهج الوصول إلى ناقل الخدمة، راجع نهج تخويل الوصول المشترك.

معالجة الإرسال الفردي

في هذا النموذج، يعالج كل استدعاء لدالتك رسالة واحدة. maxConcurrentCalls يتحكم الإعداد في عمليات التنفيذ المستهدفة لكل مثيل. يعتمد الإعداد المحدد على إصدار ملحق ناقل خدمة Microsoft Azure.

v5.x+

host.json تعديل الإعداد maxConcurrentCalls، كما في المثال التالي:

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

v2.x+

host.json تعديل الإعداد maxConcurrentCalls في messageHandlerOptions، كما في المثال التالي:

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

معالجة الإرسال الفردي (المستندة إلى الجلسة)

في هذا النموذج، يعالج كل استدعاء لدالتك رسالة واحدة. ومع ذلك، اعتمادا على عدد الجلسات النشطة لموضوع ناقل خدمة Microsoft Azure أو قائمة الانتظار، يقوم كل مثيل بتأجير جلسة عمل واحدة أو أكثر. يعتمد الإعداد المحدد على إصدار ملحق ناقل خدمة Microsoft Azure.

v5.x+

host.json تعديل الإعداد maxConcurrentSessions لتعيين عمليات التنفيذ المستهدفة لكل مثيل، كما في المثال التالي:

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

v2.x+

قم بتعديل host.json الإعداد maxConcurrentSessions في sessionHandlerOptions لتعيين عمليات التنفيذ المستهدفة لكل مثيل، كما في المثال التالي:

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

معالجة الدُفعات

في هذا النموذج، يعالج كل استدعاء لدالتك دفعة من الرسائل. يعتمد الإعداد المحدد على إصدار ملحق ناقل خدمة Microsoft Azure.

v5.x+

host.json تعديل الإعداد maxMessageBatchSize لتعيين عمليات التنفيذ المستهدفة لكل مثيل، كما في المثال التالي:

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

v2.x+

قم بتعديل host.json الإعداد maxMessageCount في batchOptions لتعيين عمليات التنفيذ المستهدفة لكل مثيل، كما في المثال التالي:

{
    "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+ من ملحق مراكز الأحداث، قم بتعديل host.json الإعداد maxBatchSize ضمن eventProcessorOptions لتعيين عمليات التنفيذ المستهدفة لكل مثيل:

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

عند تعريفها في host.json، targetUnprocessedEventThreshold يتم استخدامها كعملية تنفيذ هدف لكل مثيل بدلا من maxBatchSize، كما هو الحال في المثال التالي:

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

Storage Queues

بالنسبة إلى v2.x+ من ملحق التخزين، قم بتعديل host.json الإعداد batchSize لتعيين عمليات التنفيذ المستهدفة لكل مثيل:

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

إشعار

كفاءة المقياس: بالنسبة لملحق قائمة انتظار التخزين، لا تزال الرسائل ذات الرؤيةTimeout تحسب في طول مصدر الحدث بواسطة واجهات برمجة تطبيقات قائمة انتظار التخزين. يمكن أن يؤدي هذا إلى تكلس تطبيق الوظائف. ضع في اعتبارك استخدام قوائم انتظار ناقل خدمة Microsoft Azure للرسائل المجدولة، أو الحد من التوسيع، أو عدم استخدام 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، يتم تعريف المعلمة 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، يتم تعريف المعلمة 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 في تعريف المشغل الخاص بك، كما هو موضح في الأمثلة التالية لدالة C# قيد المعالجة لمشغل Kafka Event Hubs:

[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، يتم تعريف المعلمة LagThreshold في الربط المحدد، كما هو الحال في مثال مشغل Kafka Event Hubs هذا:

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

نموذج برمجة Python v2 غير مدعوم حاليا من قبل ملحق Kafka.

JavaScript/PowerShell/TypeScript

بالنسبة للغات الدالات التي تستخدم function.json، يتم تعريف المعلمة LagThreshold في الربط المحدد، كما هو الحال في مثال مشغل Kafka Event Hubs هذا:

{
    "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"
        }
    ]
}

نموذج برمجة Node.js v4 غير مدعوم حاليا من قبل ملحق Kafka.

الخطوات التالية

لمعرفة المزيد، راجع المقالات التالية:

• تحسين أداء وموثوقية Azure Functions
• معالجة الأحداث الموثوق بها في Azure Functions