دورة حياة تطبيق نسيج الخدمة

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

تحقق من هذه الصفحة للحصول على فيديو تدريبي يصف كيفية إدارة دورة حياة التطبيق:

هام

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

أدوار نموذج الخدمة

أدوار نموذج الخدمة هي:

• مطور الخدمة: تطوير خدمات نمطية وعامة يمكن إعادة استخدامها واستخدامها في تطبيقات متعددة من نفس النوع أو أنواع مختلفة. على سبيل المثال، يمكن استخدام خدمة قائمة الانتظار لإنشاء تطبيق التذاكر (مكتب المساعدة) أو تطبيق التجارة الإلكترونية (عربة التسوق).
• مطور التطبيق: ينشئ التطبيقات من خلال دمج مجموعة من الخدمات لتلبية متطلبات أو سيناريوهات معينة. على سبيل المثال، قد يدمج موقع ويب للتجارة الإلكترونية "خدمة JSON Front-End غير المتماثلة" و"خدمة حالة المزاد" و"خدمة قائمة الانتظار" لإنشاء حل للمزاد.
• مسؤول التطبيق: يتخذ قرارات بشأن تكوين التطبيق (ملء معلمات قالب التكوين)، والنشر (التعيين إلى الموارد المتاحة)، وجودة الخدمة. على سبيل المثال، يقرر مسؤول التطبيق اللغة المحلية (الإنجليزية للولايات المتحدة أو اليابانية لليابان، على سبيل المثال) للتطبيق. يمكن أن يكون للتطبيق المنشور المختلف إعدادات مختلفة.
• عامل التشغيل: ينشر التطبيقات استنادا إلى تكوين التطبيق والمتطلبات المحددة من قبل مسؤول التطبيق. على سبيل المثال، يوفر المشغل التطبيق وينشره ويضمن تشغيله في Azure. يراقب المشغلون صحة التطبيق ومعلومات الأداء والحفاظ على البنية التحتية المادية حسب الحاجة.

تطوير

1. مطور خدمة يطور أنواعا مختلفة من الخدمات باستخدام نموذج برمجة Reliable Actors أو Reliable Services .
2. يصف مطور الخدمة بشكل تعريفي أنواع الخدمة المطورة في ملف بيان الخدمة الذي يتكون من رمز واحد أو أكثر والتكوين وحزم البيانات.
3. ثم يقوم مطور التطبيق بإنشاء تطبيق باستخدام أنواع خدمات مختلفة.
4. يصف مطور التطبيق بشكل تعريفي نوع التطبيق في بيان التطبيق عن طريق الرجوع إلى بيانات الخدمة للخدمات المكونة وتجاوز إعدادات التكوين والنشر المختلفة للخدمات المكونة وتحديد معلمات لها بشكل مناسب.

راجع بدء استخدام Reliable Actors وبدء استخدام Reliable Services للحصول على أمثلة.

نشر

1. يقوم مسؤول التطبيق بتخصيص نوع التطبيق لتطبيق معين ليتم نشره إلى مجموعة Service Fabric عن طريق تحديد المعلمات المناسبة لعنصر ApplicationType في بيان التطبيق.
2. يقوم عامل التشغيل بتحميل حزمة التطبيق إلى مخزن صور نظام المجموعة باستخدام أسلوب CopyApplicationPackage أو Copy-ServiceFabricApplicationPackage cmdlet. تحتوي حزمة التطبيق على بيان التطبيق ومجموعة حزم الخدمة. ينشر نسيج الخدمة التطبيقات من حزمة التطبيق المخزنة في مخزن الصور، والتي يمكن أن تكون متجر كائن ثنائي كبير الحجم من Azure أو خدمة نظام نسيج الخدمة.
3. يقوم عامل التشغيل بعد ذلك بتوفير نوع التطبيق في نظام المجموعة الهدف من حزمة التطبيق التي تم تحميلها باستخدام أسلوب ProvisionApplicationAsync أو Cmdlet Register-ServiceFabricApplicationType أو عملية Provision an Application REST.
4. بعد توفير التطبيق، يبدأ عامل تشغيل التطبيق بالمعلمات التي يوفرها مسؤول التطبيق باستخدام الأسلوب CreateApplicationAsync أو Cmdlet New-ServiceFabricApplication أو عملية Create Application REST.
5. بعد نشر التطبيق، يستخدم عامل التشغيل أسلوب CreateServiceAsync أو Cmdlet New-ServiceFabricService أو عملية Create Service REST لإنشاء مثيلات خدمة جديدة للتطبيق استنادا إلى أنواع الخدمة المتوفرة.
6. التطبيق الآن قيد التشغيل في مجموعة بنية الخدمة.

راجع نشر تطبيق للحصول على أمثلة.

اختبار

1. بعد النشر إلى مجموعة التطوير المحلية أو مجموعة اختبار، يقوم مطور الخدمة بتشغيل سيناريو اختبار تجاوز الفشل المضمن باستخدام فئات FailoverTestScenarioParameters و FailoverTestScenario أو Invoke-ServiceFabricFailoverTestScenario cmdlet. يتجاوز سيناريو اختبار تجاوز الفشل خدمة محددة من خلال انتقالات وفشل مهمة لضمان أنها لا تزال متاحة وتعمل.
2. ثم يقوم مطور الخدمة بتشغيل سيناريو اختبار الفوضى المضمن باستخدام فئات ChaosTestScenarioParameters و ChaosTestScenario، أو Cmdlet Invoke-ServiceFabricChaosTestScenario. يؤدي سيناريو اختبار Chaos بشكل عشوائي إلى حث العديد من العقد وحزمة التعليمات البرمجية وأخطاء النسخ المتماثل في المجموعة.
3. يختبر مطور الخدمة الاتصال من خدمة إلى خدمة عن طريق تأليف سيناريوهات الاختبار التي تنقل النسخ المتماثلة الأساسية حول نظام المجموعة.

راجع مقدمة إلى خدمة تحليل الأخطاء لمزيد من المعلومات.

إصلاح

1. يقوم مطور الخدمة بتحديث الخدمات المكونة للتطبيق الذي تم إنشاء مثيل له و/أو إصلاح الأخطاء ويوفر إصدارا جديدا من بيان الخدمة.
2. يتجاوز مطور التطبيق إعدادات التكوين والنشر للخدمات المتناسقة ويحدد معلماتها ويوفر إصدارا جديدا من بيان التطبيق. ثم يقوم مطور التطبيق بدمج الإصدارات الجديدة من بيانات الخدمة في التطبيق ويقدم نسخة جديدة من نوع التطبيق في حزمة تطبيق محدثة.
3. يدمج مسؤول التطبيق الإصدار الجديد من نوع التطبيق في التطبيق الهدف عن طريق تحديث المعلمات المناسبة.
4. يقوم عامل التشغيل بتحميل حزمة التطبيق المحدثة إلى مخزن صور نظام المجموعة باستخدام أسلوب CopyApplicationPackage أو Copy-ServiceFabricApplicationPackage cmdlet. تحتوي حزمة التطبيق على بيان التطبيق ومجموعة حزم الخدمة.
5. يقوم عامل التشغيل بتوفير الإصدار الجديد من التطبيق في نظام المجموعة الهدف باستخدام أسلوب ProvisionApplicationAsync أو Cmdlet Register-ServiceFabricApplicationType أو عملية Provision an Application REST.
6. يقوم عامل التشغيل بترقية التطبيق الهدف إلى الإصدار الجديد باستخدام أسلوب UpgradeApplicationAsync أو Start-ServiceFabricApplicationUpgrade cmdlet أو عملية Upgrade an Application REST.
7. يتحقق عامل التشغيل من تقدم الترقية باستخدام الأسلوب GetApplicationUpgradeProgressAsync أو Get-ServiceFabricApplicationUpgrade cmdlet أو عملية Get Application Upgrade Progress REST.
8. إذا لزم الأمر، يقوم عامل التشغيل بتعديل وإعادة رسم معلمات ترقية التطبيق الحالية باستخدام أسلوب UpdateApplicationUpgradeAsync أو Update-ServiceFabricApplicationUpgrade cmdlet أو عملية تحديث ترقية التطبيق REST.
9. إذا لزم الأمر، يقوم عامل التشغيل بالتراجع عن ترقية التطبيق الحالية باستخدام طريقة RollbackApplicationUpgradeAsync أو Start-ServiceFabricApplicationRollback cmdlet أو عملية Reback Application Upgrade REST.
10. يقوم نسيج الخدمة بترقية التطبيق المستهدف الذي يعمل في المجموعة دون فقدان توفر أي من الخدمات المكونة له.

راجع البرنامج التعليمي لترقية التطبيق للحصول على أمثلة.

الاحتفاظ

1. بالنسبة إلى ترقيات نظام التشغيل والتصحيحات، يتفاعل نسيج الخدمة مع البنية التحتية Azure لضمان توفر جميع التطبيقات التي تعمل في المجموعة.
2. للترقيات والتصحيحات إلى منصة نسيج الخدمة، يقوم نسيج الخدمة بترقيته بنفسه دون فقدان توفر أي من التطبيقات التي تعمل على المجموعة.
3. يوافق مسؤول التطبيق على إضافة العقد أو إزالتها من نظام مجموعة بعد تحليل بيانات استخدام السعة التاريخية والطلب المتوقع في المستقبل.
4. يضيف عامل التشغيل العقد المحددة من قبل مسؤول التطبيق ويزيلها.
5. عند إضافة عقد جديدة أو إزالة العقد الموجودة من المجموعة، يقوم نسيج الخدمة تلقائيًا بموازنة تطبيقات التشغيل عبر جميع العقد في المجموعة لتحقيق الأداء الأمثل.

إزالة

1. يمكن للمشغل حذف مثيل معين لخدمة قيد التشغيل في نظام المجموعة دون إزالة التطبيق بأكمله باستخدام أسلوب DeleteServiceAsync أو Remove-ServiceFabricService cmdlet أو عملية Delete Service REST.
2. يمكن للمشغل أيضا حذف مثيل تطبيق وجميع خدماته باستخدام أسلوب DeleteApplicationAsync أو الأمر cmdlet Remove-ServiceFabricApplication أو عملية Delete Application REST.
3. بمجرد إيقاف التطبيق والخدمات، يمكن للمشغل إلغاء توفير نوع التطبيق باستخدام أسلوب UnprovisionApplicationAsync أو الأمر cmdlet Unregister-ServiceFabricApplicationType أو إلغاء توفير عملية Application REST. لا يؤدي عدم توفير نوع التطبيق إلى إزالة حزمة التطبيق من ImageStore.
4. يقوم عامل التشغيل بإزالة حزمة التطبيق من ImageStore باستخدام الأسلوب RemoveApplicationPackage أو Remove-ServiceFabricApplicationPackage cmdlet.

راجع نشر تطبيق للحصول على أمثلة.

الحفاظ على مساحة القرص في مخزن صور نظام المجموعة

يحتفظ ImageStoreService بحزم منسوخة ومكدسة، مما قد يؤدي إلى تراكم الملفات. يمكن أن يؤدي تراكم الملفات إلى تعبئة ImageStoreService (fabric:/System/ImageStoreService) للقرص ويمكن أن يزيد من وقت الإنشاء للنسخ المتماثلة ImageStoreService.

لتجنب تراكم الملفات، استخدم تسلسل التوفير التالي:

1. نسخ الحزمة إلى ImageStore، واستخدام خيار الضغط

2. توفير الحزمة

3. قم بإزالة الحزمة في مخزن الصور

4. ترقية التطبيق/نظام المجموعة

5. إلغاء توفير الإصدار القديم

تمنع الخطوتان 3 و5 في الإجراء أعلاه تراكم الملفات في مخزن الصور.

تكوين التنظيف التلقائي

يمكنك أتمتة الخطوة 3 أعلاه باستخدام PowerShell أو XML. سيؤدي هذا إلى حذف حزمة التطبيق تلقائيا بعد التسجيل الناجح لنوع التطبيق.

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

يمكنك أتمتة الخطوة 5 أعلاه باستخدام XML. سيؤدي هذا إلى إلغاء تسجيل أنواع التطبيقات غير المستخدمة تلقائيا.

<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

تنظيف الملفات والبيانات على العقد

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

لإزالة ثنائيات التطبيق تماما، يجب عليك إلغاء تسجيل نوع التطبيق.

التوصيات لتقليل ضغط القرص:

1. Remove-ServiceFabricApplicationPackage هذا يزيل الحزمة من موقع التحميل المؤقت.
2. إلغاء تسجيل-ServiceFabricApplicationType إصدار مساحة التخزين عن طريق إزالة ملفات نوع التطبيق من خدمة مخزن الصور وجميع العقد. يتم تشغيل مدير الحذف كل ساعة افتراضيا.
3. تقوم CleanupUnusedApplicationTypes بتنظيف إصدارات التطبيق القديمة غير المستخدمة تلقائيا.

   {
     "name": "Management",
     "parameters": [
       {
         "name": "CleanupUnusedApplicationTypes",
         "value": true
       },
       {
         "name": "MaxUnusedAppTypeVersionsToKeep",
         "value": "3"
       }
     ]
   }
   

4. يزيل Remove-ServiceFabricClusterPackage ثنائيات تثبيت وقت التشغيل القديمة غير المستخدمة.

إشعار

هناك ميزة قيد التطوير للسماح لـ Service Fabric بحذف مجلدات التطبيق بمجرد إخلاء التطبيق من العقدة.

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

للمزيد من المعلومات حول تطوير واختبار وإدارة تطبيقات وخدمات نسيج الخدمة، راجع:

• الجهات الفاعلة الموثوق بها
• خدمات موثوقة
• نشر تطبيق
• ترقية التطبيق
• نظرة عامة على قابلية الاختبار