إصدار في وظائف دائمة (وظائف Azure)

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

كيفية التعامل مع التغييرات المتقطعة

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

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

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

كمثال على ذلك، افترض أن لدينا وظيفة المنسق التالية.

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

Java

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

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

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

Java

@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. يحدث هذا الفشل لأن النتيجة في جدول المحفوظات هي قيمة منطقية ولكن التعليمات البرمجية الجديدة تحاول إلغاء تسلسلها إلى قيمة سلسلة، ما يؤدي إلى سلوك غير متوقع أو حتى استثناء وقت التشغيل للغات النوع الآمنة.

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

تغيير منطق orchestrator

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

ضع في اعتبارك وظيفة المنسق التالية:

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

Java

@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

Java

@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 بين FooBar. لا توجد أي تغييرات في التوقيع. تنشأ المشكلة عند استئناف مثيل موجود من الاستدعاء إلى Bar. خلال الإعادة، إذا عاد الاستدعاء الأصلي إلى Footrue ، فستدعو إعادة التزامن إلى SendNotificatio، وهو ليس في تاريخ التنفيذ الخاص به. يكتشف وقت التشغيل عدم الاتساق هذا ويُظهر خطأ تنسيق غير محدد لأنه وجد استدعاءً لـ SendNotification بينما كان يتوقع العثور على استدعاء لـ Bar. يمكن أن يحدث نفس النوع من المشكلة عند إضافة استدعاءات API إلى عمليات دائمة أخرى، مثال إنشاء مؤقتات دائمة، وانتظار الأحداث الخارجية، واستدعاء التكوينات الفرعية، إلخ.

استراتيجيات التخفيف من المخاطر

فيما يلي بعض من الإستراتيجيات للتعامل مع تحديات الإصدار:

• لا تفعل شيئًا (غير مستوصى به)
• وقف جميع حالات الطيران
• عمليات التوزيع جنبًا إلى جنب

عديم الفائدة.

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

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

بسبب هذه الإخفاقات المحتملة، لا يوصى بإستراتيجية "عدم القيام بأي شيء".

وقف جميع حالات الطيران

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

إشعار

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

عمليات التوزيع جنبًا إلى جنب

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

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

يُعد النشر جنبًا إلى جنب الأسلوب الموصى به لنشر إصدارات جديدة من تطبيقات الوظائف الخاصة بك.

إشعار

تستخدم هذه الإرشادات الخاصة بإستراتيجية النشر جنبًا إلى جنب المصطلحات الخاصة بـ Azure Storage، ولكنها تنطبق بشكل عام على جميع موفري تخزين الوظائف الدائمة المدعومة.

الفتحات الخاصة بالنشر

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

إشعار

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

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

تعرّف على استخدام موفري التخزين واختيارهم