ترقية تطبيق "تصميم الخدمة": مواضيع متقدمة

مقالة
06/01/2023

إضافة أنواع الخدمات أو إزالتها أثناء ترقية تطبيق

إذا أُضيف نوع خدمة جديد إلى تطبيق منشور كجزء من ترقية، فسيُضاف نوع الخدمة الجديد إلى التطبيق المنشور. لا تؤثر هذه الترقية على أي من مثيلات الخدمة التي كانت بالفعل جزءًا من التطبيق، ولكن يجب إنشاء مثيل من نوع الخدمة الذي تمت إضافته ليكون نوع الخدمة الجديد نشطًا (راجع New-ServiceFabricService).

بالمثل، يمكن إزالة أنواع الخدمات من أحد التطبيقات كجزء من الترقية. ومع ذلك، يجب إزالة كافة مثيلات الخدمة من نوع الخدمة المراد إزالتها قبل متابعة الترقية (راجع Remove-ServiceFabricService).

تجنب انقطاع الاتصال أثناء وقت تعطل الخدمة عديم الحالة المخطط له

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

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

تكوين الخدمة

هناك عدة طرق لتكوين التأخير على جانب الخدمة.

عند إنشاء خدمة جديدة، حدد -InstanceCloseDelayDuration:

New-ServiceFabricService -Stateless [-ServiceName] <Uri> -InstanceCloseDelayDuration <TimeSpan>

أثناء تعريف الخدمة في قسم «الإعدادات الافتراضية» في بيان التطبيق، عيّن الخاصية InstanceCloseDelayDurationSeconds:

      <StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]" InstanceCloseDelayDurationSeconds="15">
          <SingletonPartition />
      </StatelessService>

عند تحديث خدمة موجودة، حدد -InstanceCloseDelayDuration:

Update-ServiceFabricService [-Stateless] [-ServiceName] <Uri> [-InstanceCloseDelayDuration <TimeSpan>]`

عند إنشاء خدمة موجودة أو تحديثها من خلال قالب ARM، حدد القيمة InstanceCloseDelayDuration (الحد الأدنى لإصدار واجهة برمجة التطبيقات المدعوم : 2020-03-01):

{
  "apiVersion": "2020-03-01",
  "type": "Microsoft.ServiceFabric/clusters/applications/services",
  "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
  "location": "[variables('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/clusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
  ],
  "properties": {
    "provisioningState": "Default",
    "serviceKind": "Stateless",
    "serviceTypeName": "[parameters('serviceTypeName')]",
    "instanceCount": "-1",
    "partitionDescription": {
      "partitionScheme": "Singleton"
    },
    "serviceLoadMetrics": [],
    "servicePlacementPolicies": [],
    "defaultMoveCost": "",
    "instanceCloseDelayDuration": "00:00:30.0"
  }
}

تكوين العميل

لتلقي إعلام عند تغيير نقطة نهاية، يجب على العملاء تسجيل معاودة الاتصال، راجع ServiceNotificationFilterDescription. إعلام التغيير هو مؤشر على أن نقاط النهاية قد تغيرت، ويجب على العميل إعادة حل نقاط النهاية وعدم استخدام نقاط النهاية التي لم يُعلن عنها بعد الآن لأنها ستتعطل قريبًا.

تجاوزات الترقية الاختيارية

بالإضافة إلى تعيين فترات التأخير الافتراضية لكل خدمة، يمكنك أيضًا تجاوز التأخير أثناء ترقية التطبيق/نظام مجموعة باستخدام الخيار (InstanceCloseDelayDurationSec) نفسه:

Start-ServiceFabricApplicationUpgrade [-ApplicationName] <Uri> [-ApplicationTypeVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

Start-ServiceFabricClusterUpgrade [-CodePackageVersion] <String> [-ClusterManifestVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

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

ملاحظة

لن تتمكن إعدادات استنزاف الطلبات من منع «موازن تحميل Azure» من إرسال طلبات جديدة إلى نقاط النهاية التي تخضع للاستنزاف.
لن تؤدي آلية الدقة القائمة على الشكوى إلى استنزاف الطلبات بأمان، لأنها تشغّل دقة الخدمة بعد الفشل. كما هو موضح سابقًا، يجب بدلًا من ذلك تحسين هذا للاشتراك في إشعارات تغيير نقطة النهاية باستخدام ServiceNotificationFilterDescription.
لا يُلتزم بالإعدادات عندما تكون الترقية عديمة التأثير، أي عندما لا يتم إسقاط النسخ المتماثلة أثناء الترقية.
القيمة القصوى لـ InstanceCloseDelayDuration التي يمكن تكوينها في وصف الخدمة أو InstanceCloseDelayDurationSec في وصف الترقية لا يمكن أن تكون أكبر من تكوين نظام المجموعة FailoverManager.MaxInstanceCloseDelayDurationInSeconds، الذي يُعيّن افتراضيًا إلى 1800 ثانية. لتحديث القيمة القصوى، يجب تحديث تكوين مستوى نظام المجموعة. لا يتوفر هذا التكوين إلا في إصدار وقت التشغيل 9.0 أو إصدار أحدث.

ملاحظة

يمكن تكوين هذه الميزة في الخدمات الموجودة باستخدام Update-ServiceFabricService cmdlet أو قالب ARM كما هو مذكور أعلاه، عندما يكون إصدار التعليمة البرمجية لنظام مجموعة هو 7.1.XXX أو أعلى.

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

ملاحظة

يوصى بوضع ترقية المراقب لجميع ترقيات "تصميم الخدمة". يجب النظر في وضع الترقية غير مراقب يدوي فقط للترقيات الفاشلة أو المتوقفة موقتًا.

في وضع المراقبة، يُطبق "تصميم الخدمة" نُهج الحماية لضمان سلامة التطبيق مع تقدّم الترقية. إذا تم انتهاك نُهج الحماية، فسيتم تعليق الترقية أو التراجع عنها تلقائيًا وفقًا لـ FailureAction المحدد.

في وضع غير مراقب يدوي، يتمتع مسؤول التطبيق بالتحكم الكامل في تقدم الترقية. هذا الوضع مفيد عند تطبيق نُهج تقييم السلامة المخصصة أو إجراء ترقيات غير تقليدية لتجاوز مراقبة السلامة تمامًا (على سبيل المثال، التطبيق بالفعل في حالة فقدان البيانات). ستقوم الترقية قيد التشغيل في هذا الوضع بتعليق نفسها بعد إكمال كل UD ويجب استئنافها صراحة باستخدام Resume-ServiceFabricApplicationUpgrade. عندما يتم تعليق الترقية وتكون جاهزة ليستأنفها المستخدم، ستُظهر حالة الترقية الخاصة بها RollforwardPending (راجع UpgradeState).

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

الترقية باستخدام حزمة diff

بدلًا من توفير حزمة تطبيق كاملة، يمكن أيضًا إجراء الترقيات عن طريق تزويد حزم diff التي تحتوي فقط على حزم التعليمات البرمجية / التكوين / البيانات المُحدثة إلى جانب بيان التطبيق الكامل وبيانات الخدمة الكاملة. حزم التطبيقات الكاملة مطلوبة فقط للتثبيت الأولي لتطبيق على نظام مجموعة. يمكن أن تكون الترقيات اللاحقة إما من حزم التطبيقات الكاملة أو حزم diff.

يُستبدل أي مرجع في بيان التطبيق أو بيانات الخدمة لحزمة diff التي لا يمكن العثور عليها في حزمة التطبيق تلقائيًا بالإصدار المتوفر حاليًا.

سيناريوهات استخدام حزمة diff هي:

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

عند ترقية تطبيق باستخدام Visual Studio، تُنشر حزمة diff تلقائيًا. لإنشاء حزمة diff يدويًا، يجب تحديث بيان التطبيق وبيانات الخدمة، ولكن يجب تضمين الحزم التي تم تغييرها فقط في حزمة التطبيق النهائية.

على سبيل المثال، لنبدأ بالتطبيق التالي (أرقام الإصدارات المُقدمة لسهولة الفهم):

app1           1.0.0
  service1     1.0.0
    code       1.0.0
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

لنفترض أنك لم ترد إلا تحديث حزمة التعليمات البرمجية الخاصة بالخدمة 1 باستخدام حزمة diff. يحتوي التطبيق المُحدّث على تغييرات الإصدار التالية:

app1           2.0.0      <-- new version
  service1     2.0.0      <-- new version
    code       2.0.0      <-- new version
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

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

app1/
  service1/
    code/

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

ترقية معلمات التطبيق بشكل مستقل عن الإصدار

يُستحسن في بعض الأحيان تغيير معلمات تطبيق "تصميم الخدمة" دون تغيير إصدار البيان. يمكن القيام بذلك بشكل ملائم باستخدام العلامة - ApplicationParameter مع Start-ServiceFabricApplicationUpgrade Azure Service Fabric PowerShell cmdlet. افترض تطبيق "تصميم الخدمة" مع الخصائص التالية:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "1"; "NewParameter" = "testBefore" }

الآن، قم بترقية التطبيق باستخدام Start-ServiceFabricApplicationUpgrade cmdlet. يعرض هذا المثال ترقية خاضعة للمراقبة، ولكن يمكن أيضًا استخدام ترقية غير خاضعة للمراقبة. للاطلاع على وصف كامل للعلامات المقبولة بواسطة cmdlet، راجع مرجع الوحدة النمطية Azure Service Fabric PowerShell

PS C:\> $appParams = @{ "ImportantParameter" = "2"; "NewParameter" = "testAfter"}

PS C:\> Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/Application1 -ApplicationTypeVers
ion 1.0.0 -ApplicationParameter $appParams -Monitored

بعد الترقية، تأكد من أن التطبيق يحتوي على المعلمات المُحدّثة ونفس الإصدار:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "2"; "NewParameter" = "testAfter" }

التراجع عن ترقيات التطبيقات

على الرغم من أنه يمكن ترحيل الترقيات إلى الأمام في أحد الأوضاع الثلاثة (مراقب أو غير مراقب تلقائي أو غير مراقب يدوي)، إلا أنه لا يمكن التراجع عنها إلا في وضع غير مراقب تلقائي أو غير مراقب يدوي. يعمل التراجع في وضع غير مراقب تلقائي بنفس طريقة التقدم إلى الأمام باستثناء أن القيمة الافتراضية لـ UpgradeReplicaSetCheckTimeout مختلفة - راجع معلمات ترقية التطبيق. يعمل التراجع في وضع غير مراقب يدوي بنفس طريقة التقدم إلى الأمام - سيُعلّق التراجع نفسه بعد إكمال كل UD ويجب استئنافه صراحة باستخدام Resume-ServiceFabricApplicationUpgrade للاستمرار في التراجع.

يمكن تشغيل عمليات التراجع تلقائيًا عند انتهاك نُهج الحماية الخاصة بالترقية في وضع المراقب مع FailureAction الخاص بـ التراجع (راجع معلمات ترقية التطبيق) أو بشكل صريح باستخدام Start-ServiceFabricApplicationRollback.

أثناء التراجع، لا يزال من الممكن تغيير قيمة UpgradeReplicaSetCheckTimeout ووضعه في أي وقت باستخدام Update-ServiceFabricApplicationUpgrade.

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

يرشدك Upgrading your Application Using Visual Studio خلال ترقية التطبيق باستخدام Visual Studio.

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

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

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

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

مشاركة عبر

ترقية تطبيق "تصميم الخدمة": مواضيع متقدمة

إضافة أنواع الخدمات أو إزالتها أثناء ترقية تطبيق

تجنب انقطاع الاتصال أثناء وقت تعطل الخدمة عديم الحالة المخطط له

تكوين الخدمة

تكوين العميل

تجاوزات الترقية الاختيارية

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

الترقية باستخدام حزمة diff

ترقية معلمات التطبيق بشكل مستقل عن الإصدار

التراجع عن ترقيات التطبيقات

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

الملاحظات

الملاحظات

الموارد الإضافية