ترقية تطبيق Service Fabric

تطبيق Azure Service Fabric هو مجموعة من الخدمات. أثناء الترقية، يقارن Service Fabric بيان التطبيق الجديد بالإصدار السابق ويحدد الخدمات في التطبيق التي تتطلب تحديثات. يقارن Service Fabric الإصدار في بيانات الخدمة بالإصدار الموجود في الإصدار السابق. إذا لم يتغير إصدار الخدمة، فلن تتم ترقية هذه الخدمة.

إشعار

لا يتم الاحتفاظ ب ApplicationParameters عبر ترقية التطبيق. للحفاظ على معلمات التطبيق الحالية، يجب على المستخدم الحصول على المعلمات أولا وتمريرها إلى استدعاء واجهة برمجة تطبيقات الترقية كما يلي:

$myApplication = Get-ServiceFabricApplication -ApplicationName fabric:/myApplication
$appParamCollection = $myApplication.ApplicationParameters

$applicationParameterMap = @{}
foreach ($pair in $appParamCollection)
{
    $applicationParameterMap.Add($pair.Name, $pair.Value);
}

Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/myApplication -ApplicationTypeVersion 2.0.0 -ApplicationParameter $applicationParameterMap -Monitored -FailureAction Rollback

نظرة عامة على الترقيات المتداولة

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

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

يتم تحديد مجالات التحديث في بيان نظام المجموعة عند تكوين نظام المجموعة. لا تتلقى مجالات التحديث التحديثات بترتيب معين. مجال التحديث هو وحدة منطقية للتوزيع لأحد التطبيقات. تسمح مجالات التحديث للخدمات بالبقاء في حالة توفر عالية أثناء الترقية.

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

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

عمليات التحقق من السلامة أثناء الترقيات

للترقية، يجب تعيين نهج الحماية (أو يمكن استخدام القيم الافتراضية). يطلق على الترقية أنها ناجحة عندما تتم ترقية جميع مجالات التحديث خلال المهلات المحددة، وعندما تعتبر جميع مجالات التحديث سليمة. يعني مجال التحديث السليم أن مجال التحديث اجتاز جميع عمليات التحقق من الصحة المحددة في نهج الصحة. على سبيل المثال، قد تنص السياسة الصحية على أن جميع الخدمات داخل مثيل التطبيق يجب أن تكون سليمة، حيث يتم تعريف الصحة بواسطة Service Fabric.

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

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

أوضاع الترقية

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

يحتاج الوضع اليدوي غير الخاضع للمراقبة إلى تدخل يدوي بعد كل ترقية على مجال تحديث، لبدء الترقية على مجال التحديث التالي. لا يتم إجراء فحوصات سلامة Service Fabric. يقوم المسؤول بإجراء عمليات التحقق من الصحة أو الحالة قبل بدء الترقية في مجال التحديث التالي.

ترقية الخدمات الافتراضية

يمكن أيضا ترقية بعض معلمات الخدمة الافتراضية المحددة في بيان التطبيق كجزء من ترقية التطبيق. يمكن تغيير معلمات الخدمة التي تدعم التغيير من خلال Update-ServiceFabricService فقط كجزء من الترقية. سلوك تغيير الخدمات الافتراضية أثناء ترقية التطبيق كما يلي:

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

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

تلميح

يجب أن يكون إعداد تكوين نظام المجموعة EnableDefaultServicesUpgradeصحيحا لتمكين القواعد 2) و3) أعلاه (تحديث الخدمة الافتراضي وحذفها). يتم دعم هذه الميزة بدءا من Service Fabric الإصدار 5.5.

ترقية تطبيقات متعددة باستخدام نقاط نهاية HTTPS

تحتاج إلى الحرص على عدم استخدام نفس المنفذ لمثيلات مختلفة من نفس التطبيق عند استخدام HTTPS. والسبب هو أن Service Fabric لن يكون قادرا على ترقية الشهادة لأحد مثيلات التطبيق. على سبيل المثال، إذا كان التطبيق 1 أو التطبيق 2 يريد كلاهما ترقية الشهادة 1 إلى الشهادة 2. عند حدوث الترقية، قد يكون Service Fabric قد قام بتنظيف تسجيل الشهادة 1 مع http.sys على الرغم من أن التطبيق الآخر لا يزال يستخدمه. لمنع ذلك، يكتشف Service Fabric أن هناك بالفعل مثيل تطبيق آخر مسجل على المنفذ مع الشهادة (بسبب http.sys) ويفشل العملية.

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

إذا رأيت فشل ترقية مع https، فإن تحذير الخطأ يقول "لا تدعم واجهة برمجة تطبيقات Windows HTTP Server شهادات متعددة للتطبيقات التي تشترك في منفذ."

مخطط انسيابي لترقية التطبيق

يمكن أن يساعدك المخطط الانسيابي التالي لهذه الفقرة على فهم عملية ترقية تطبيق Service Fabric. على وجه الخصوص، يصف التدفق كيف تساعد المهلات، بما في ذلك HealthCheckStableDuration و HealthCheckRetryTimeout و UpgradeHealthCheckInterval، في التحكم عند اعتبار الترقية في مجال تحديث واحد ناجحا أو فشلا.

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

ترقية التطبيق الخاص بك باستخدام Visual Studio يرشدك خلال ترقية تطبيق باستخدام Visual Studio.

ترقية التطبيق الخاص بك باستخدام PowerShell يرشدك من خلال ترقية تطبيق باستخدام PowerShell.

التحكم في كيفية ترقية التطبيق الخاص بك باستخدام معلمات الترقية.

اجعل ترقيات التطبيق متوافقة من خلال تعلم كيفية استخدام تسلسل البيانات.

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

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