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

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

• أباتشي كافكا
• 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	غير متوفر
ناقل خدمة Microsoft Azure (الملحق v5.x+ ، إرسال واحد)	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
ناقل خدمة Microsoft Azure (الوظائف v2.x+ ، إرسال واحد)	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، يمكنك أيضا تمكين التزامن الديناميكي. في هذا التكوين، يتم تحديد تنفيذ _target لكل قيمة مثيل تلقائيا بواسطة ميزة التزامن الديناميكي. يبدأ بتزامن محدود ويحدد أفضل إعداد بمرور الوقت.

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

تعتمد الطريقة التي تقوم بها بتكوين التحجيم المستند إلى الهدف في ملف 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 Event Hubs، يتم توسيع نطاق Azure Functions استنادا إلى عدد الأحداث غير المعالجة الموزعة عبر جميع الأقسام في مركز الأحداث ضمن قائمة بأعداد المثيلات الصالحة. بشكل افتراضي، host.json السمات المستخدمة لعمليات التنفيذ الهدف لكل مثيل هي maxEventBatchSize و maxBatchSize. ومع ذلك، إذا اخترت ضبط التحجيم المستند إلى الهدف، يمكنك تحديد معلمة targetUnprocessedEventThreshold منفصلة تتجاوز لتعيين عمليات التنفيذ المستهدفة لكل مثيل دون تغيير إعدادات الدفعة. إذا targetUnprocessedEventThreshold تم تعيين، يتم تقسيم إجمالي عدد الأحداث غير المعالجة على هذه القيمة لتحديد عدد المثيلات، والتي يتم تقريبها بعد ذلك إلى عدد مثيلات العامل الذي ينشئ توزيع قسم متوازن.

تحذير

التعيين batchCheckpointFrequency فوق 1 لخطط الاستضافة المدعومة بالتكبير القائم على الهدف قد يسبب سلوك توسع غير صحيح. تحسب المنصة الأحداث غير المعالجة ك "الموقع الحالي - موقع نقاط التحقق"، مما قد يشير بشكل خاطئ إلى الرسائل غير المعالجة عندما تتم معالجة الدفعات ولكن لم يتم التحقق منها بعد، مما يمنع التوسع الصحيح عندما لا تبقى رسائل.

سلوك التحجيم والاستقرار

بالنسبة إلى مراكز الأحداث، يمكن أن تؤدي عمليات التوسع والتوسيع المتكررة إلى إعادة موازنة القسم، مما يؤدي إلى تأخير المعالجة وزيادة زمن الانتقال. للتخفيف من ذلك:

• تستخدم المنصة قائمة محددة مسبقا من أعداد العمال الصالحة لتوجيه قرارات التحجيم.
• تضمن المنصة أن يكون القياس مستقرا ومتعمدا ، وتجنب التغييرات التخريبية في تعيينات الأقسام.
• إذا لم يكن عدد العمال المطلوب في القائمة الصالحة - على سبيل المثال، 17، يحدد النظام تلقائيا أكبر عدد صالح تالي، وهو في هذه الحالة 32. بالإضافة إلى ذلك ، لمنع القياس المتكرر السريع ، يتم خنق طلبات التوسع لمدة 3 دقائق بعد آخر توسيع نطاق. يساعد هذا التأخير في تقليل إعادة التوازن غير الضرورية ويساهم في الحفاظ على كفاءة الإنتاجية.

عدد المثيلات الصالحة لمراكز الأحداث

لكل عدد أقسام Event Hubs، نحسب قائمة مقابلة من أعداد المثيلات الصالحة لضمان التوزيع الأمثل والقياس الفعال. يتم اختيار هذه الأعداد لتتماشى بشكل جيد مع متطلبات التقسيم والتزامن:

عدد الأقسام	عدد المثيلات الصالحة
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، مما يسمح بمجموعات عدد مثيلات صالحة أكبر. تدعم هذه المستويات معدل نقل وقابلية توسع أعلى، ويتم توسيع قائمة عدد العمال الصالحة وفقا لذلك لتوزيع أقسام مركز الأحداث بالتساوي عبر المثيلات. أيضا، نظرا لأن مراكز الأحداث عبارة عن حمل عمل مقسم، فإن عدد الأقسام في مركز الأحداث هو الحد الأقصى لعدد المثيلات المستهدفة.

إعدادات مراكز الأحداث

يعتمد الإعداد المحدد على إصدار ملحق مراكز الأحداث.

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
        }
    }
}

قوائم انتظار التخزين

بالنسبة إلى 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"
        }
    ]
}

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

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