تحديات الإصدار واستراتيجيات التخفيف في Durable Functions

الإصدار في Durable Functions ضروري لأن الوظائف تضاف وتزال وتتغير حتما على مدى عمر التطبيق. Durable Functions تتيح لك ربط الدوال معا بطرق لم تكن ممكنة من قبل، وهذا التسلسل يؤثر على كيفية تعاملك مع الإصدارات.

تساعدك هذه المقالة على:

• حدد ما إذا كان تغيير الكود الخاص بك تغييرا خيارا كبيرا.
• اختر استراتيجية التخفيف المناسبة لنشرها بأمان.

مقارنة سريعة بين الاستراتيجيات

إذا كنت تعلم بالفعل أن تغييرك يتعطل، استخدم هذا الجدول لاختيار استراتيجية تخفيف:

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

نصيحة

إذا كنت تبحث عن ميزة التوزيع الأوركسترالي المدمجة التي توفر عزل الإصدارات تلقائيا على مستوى وقت التشغيل، راجع إصدار Orchestration.

مهم

قبل النشر، تحقق مما إذا كان تغييرك تغييرا كبيرا:

• هل غيرت اسم أو نوع الإدخال أو نوع الإخراج لنشاط أو دالة كيان؟
• هل أضفت أو أزلت أو أعدت ترتيب المكالمات للأنشطة، أو التنسيقات الفرعية، أو المؤقتات، أو الأحداث الخارجية في كود الأوركستراتور؟
• هل قمت بإعادة تسمية أو إزالة وظيفة قد تسميها الفرق الموسيقية أثناء الطيران؟

إذا أجبت بنعم على أي من هذه الأفكار، استخدم إحدى استراتيجيات التخفيف أدناه لتجنب الفشل في تشغيل التوزيعات.

أنواع التغييرات العاجلة

هناك عدة أمثلة على التغييرات الفائقة. تناقش هذه المقالة أكثر الأنواع شيوعا. الموضوع الرئيسي وراء كل هذه التعديلات هو أن التغييرات في كود الدوال تؤثر على تنسيقات الوظائف الجديدة والقائمة على حد سواء.

تغييرات توقيع وظيفة النشاط أو الكيان

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

كمثال، اعتبر وظيفة الموزع التالية.

C#‎

[FunctionName("FooBar")]
public static Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    bool result = await context.CallActivityAsync<bool>("Foo");
    await context.CallActivityAsync("Bar", result);
}

بوويرشيل

param($Context)

[bool]$Result = Invoke-DurableActivity -FunctionName 'Foo'
Invoke-DurableActivity -FunctionName 'Bar' -Input $Result

جاوة

@FunctionName("FooBar")
public void fooBarOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    boolean result = ctx.callActivity("Foo", boolean.class).await();
    ctx.callActivity("Bar", result).await();
}

تأخذ هذه الدالة نتيجة فو وتمررها إلى بار. افترض أنك بحاجة لتغيير قيمة عودة Foo من بوليان إلى وتر لدعم مجموعة أوسع من قيم النتائج. والنتيجة تبدو كما يلي:

C#‎

[FunctionName("FooBar")]
public static Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string result = await context.CallActivityAsync<string>("Foo");
    await context.CallActivityAsync("Bar", result);
}

بوويرشيل

param($Context)

[string]$Result = Invoke-DurableActivity -FunctionName 'Foo'
Invoke-DurableActivity -FunctionName 'Bar' -Input $Result

جاوة

@FunctionName("FooBar")
public void fooBarOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    String result = ctx.callActivity("Foo", String.class).await();
    ctx.callActivity("Bar", result).await();
}

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

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

تغييرات منطقية الأوركستراتور

الفئة الأخرى من مشاكل الإصدار تأتي من تغيير كود وظيفة المنسق بطريقة تغير مسار التنفيذ للمثيلات أثناء الطيران.

خذ بعين الاعتبار دالة المنسق التالية:

C#‎

[FunctionName("FooBar")]
public static Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    bool result = await context.CallActivityAsync<bool>("Foo");
    await context.CallActivityAsync("Bar", result);
}

بوويرشيل

param($Context)

[bool]$Result = Invoke-DurableActivity -FunctionName 'Foo'
Invoke-DurableActivity -FunctionName 'Bar' -Input $Result

جاوة

@FunctionName("FooBar")
public void fooBarOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    boolean result = ctx.callActivity("Foo", boolean.class).await();
    ctx.callActivity("Bar", result).await();
}

الآن افترض أنك تريد إضافة استدعاء دالة جديد بين استدعاءي الدوال الحاليين.

C#‎

[FunctionName("FooBar")]
public static Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    bool result = await context.CallActivityAsync<bool>("Foo");
    if (result)
    {
        await context.CallActivityAsync("SendNotification");
    }

    await context.CallActivityAsync("Bar", result);
}

بوويرشيل

param($Context)

[bool]$Result = Invoke-DurableActivity -FunctionName 'Foo'
if ($Result -eq $true) {
    Invoke-DurableActivity -FunctionName 'SendNotification'
}
Invoke-DurableActivity -FunctionName 'Bar' -Input $Result

جاوة

@FunctionName("FooBar")
public void fooBarOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    boolean result = ctx.callActivity("Foo", boolean.class).await();
    if (result) {
        ctx.callActivity("SendNotification").await();
    }

    ctx.callActivity("Bar", result).await();
}

هذا التغيير يضيف استدعاء دالة جديدة إلى SendNotification بين Foo و Bar. لا توجد تغييرات في التوقيع. تظهر المشكلة عندما يستأنف المثيل الحالي من المكالمة إلى Bar. أثناء إعادة التشغيل، إذا عاد النداء الأصلي ل Footrue، فإن إعادة تشغيل الموزع تستدعي إلى SendNotification، وهذا ليس ضمن سجل التنفيذ. يكتشف وقت التشغيل هذا التناقض ويرفع خطأ تنسيق غير حتمي لأنه واجه استدعاء إلى SendNotification عندما كان يتوقع رؤية نداء إلى Bar. يمكن أن تحدث نفس نوع المشكلة عند إضافة استدعاءات API إلى عمليات دائمة أخرى، مثل إنشاء مؤقتات دائمة، انتظار أحداث خارجية، أو استدعاء التنسيقات الفرعية.

استراتيجيات التخفيف

تحذير

نشر تغييرات القطع دون استراتيجية تخفيف (نهج "عدم القيام بشيء") يمكن أن يؤدي إلى فشل التنسيقات مع أخطاء تنسيق غير حتمية ، أو التوقف إلى أجل غير مسمى في حالة معينة Running ، أو تفعيل فشل في وقت التشغيل منخفض المستوى يؤثر على الأداء. استخدم دائما إحدى الاستراتيجيات التالية عند تنفيذ التغييرات العاجلة.

إصدار التوزيع الأوركسترالي (موصى به)

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

مع تعيين إصدار التنسيق:

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

يتطلب هذا النهج تكوينا بسيطا (سلسلة إصدارات واستراتيجية مطابقة اختيارية) وهو متوافق مع أي مزود تخزين. إنها الاستراتيجية الموصى بها للتطبيقات التي تحتاج إلى دعم التغييرات المنفصلة مع الحفاظ على النشر بدون توقف مفاجئ.

للحصول على إرشادات تفصيلية حول التكوين والتنفيذ، انظر إصدار التنسيق الأوركستراسي.

إيقاف جميع مثيلات الطيران

خيار آخر هو إيقاف جميع المثيلات أثناء الطيران. إذا كنت تستخدم المزود الافتراضي تخزين Azure ل Durable Functions، أوقف جميع النسخات بمسح محتويات قوائم control-queue الداخلية workitem-queue. بدلا من ذلك، إيقاف تطبيق الوظائف، حذف هذه الطوابير، وإعادة تشغيل التطبيق. يتم إعادة إنشاء قوائم الانتظار تلقائيا بمجرد إعادة تشغيل التطبيق. قد تبقى حالات التنسيق السابقة في حالة "تشغيل" إلى أجل غير مسمى، لكنها لا تملأ سجلاتك برسائل فشل أو تسبب أي ضرر لتطبيقك. هذا النهج مثالي للتطوير النموذجي السريع، بما في ذلك التنمية المحلية.

تحذير

يتطلب هذا النهج وصولا مباشرا إلى موارد التخزين الأساسية وليس مناسبا لجميع مزودي التخزين المدعومين من Durable Functions.

عمليات النشر جنبا إلى جنب

أكثر الطرق محصنة لضمان نشر التغييرات المتعثرة بأمان هي بنشرها جنبا إلى جنب مع نسخك القديمة. يمكنك استخدام أي من التقنيات التالية:

• حساب تخزين مختلف: قم بنشر جميع التحديثات كتطبيق وظيفة جديدة مع حساب تخزين مختلف. هذا يعزل حالة النسخة الجديدة تماما عن النسخة القديمة.
• مركز مهام مختلف: نشر نسخة جديدة من تطبيق الوظائف بنفس حساب التخزين ولكن باسم مركز المهام المحدث. هذا النهج ينشئ تشويلات تخزين جديدة للنسخة الجديدة بينما تستمر النسخة القديمة في استخدام التشوياتها الحالية.

عند تنفيذ عمليات نشر جنبا إلى جنب في Azure، يمكنك استخدام <فتحات النشر /c0> لتشغيل كلا النسختين في نفس الوقت مع وجود واحدة فقط كخانة نشطة production النشطة. عندما تكون مستعدا لكشف منطق التوزيع الموسيقي الجديد، بدل النسخة الجديدة إلى مكان الإنتاج.

ملاحظة

تستخدم هذه الإرشادات مصطلحات خاصة تخزين Azure، لكنها تنطبق بشكل عام على جميع مزودي التخزين المدعومين Durable Functions.

ملاحظة

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

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

تعرف على إصدار التنسيق

• تعرف على استراتيجيات توزيع وقت التعطل الصفري
• تعرف على مزودي التخزين ل Durable Functions