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

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

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

هام

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

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

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

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

تطوير

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

راجع ⁧⁩البدء مع الإجراءات الموثوقة ⁧⁩ و⁧⁩البدء مع الخدمات الموثوقة ⁧⁩ للحصول على أمثلة.

نشر

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

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

اختبار

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

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

ترقية

1. يقوم ⁧⁩ مطور الخدمة ⁧⁩ بتحديث الخدمات المكونة للتطبيق الفوري و/أو إصلاح الأخطاء ويقدم إصدارًا جديدًا من بيان الخدمة.
2. يتخطى ⁧⁩ مطور التطبيقات ⁧⁩ إعدادات التكوين والنشر للخدمات المتسقة ويحدد ضوابطها ويوفر إصدارًا جديدًا من بيان التطبيق. ثم يقوم مطور التطبيق بدمج الإصدارات الجديدة من بيانات الخدمة في التطبيق ويقدم نسخة جديدة من نوع التطبيق في حزمة تطبيق محدثة.
3. يقوم ⁧⁩ مسؤول التطبيق ⁧⁩ بدمج الإصدار الجديد من نوع التطبيق في التطبيق المستهدف عن طريق تحديث المعلمات المناسبة.
4. يقوم ⁧⁩المشغل⁧⁩ بتحميل حزمة التطبيق المحدثة إلى متجر الصور العنقودية باستخدام طريقة ⁧⁩⁧⁩CopyApplicationPackage⁧⁩ ⁧⁩ أو ⁧⁩⁧⁩ Copy - ServiceFabricApplicationPackage ⁧⁩ cmdlet⁧⁩. تحتوي حزمة التطبيق على بيان التطبيق ومجموعة حزم الخدمة.
5. يقوم ⁧⁩عامل التشغيل⁧⁩ بتوفير الإصدار الجديد من التطبيق في المجموعة المستهدفة باستخدام ⁧⁩الأسلوب ⁧⁩ProvisionApplicationAsync⁧⁩⁧⁩ أو ⁧⁩cmdlet ⁧⁩Register-ServiceFabricApplicationType⁧⁩⁧⁩ أو ⁧⁩عملية ⁧⁩توفير تطبيق⁧⁩ REST⁧⁩.
6. يقوم ⁧⁩المشغل⁧⁩ بترقية التطبيق المستهدف إلى الإصدار الجديد باستخدام ⁧⁩⁧⁩ طريقة ترقية التطبيق ⁧⁩ Sync ⁧⁩ أو ⁧⁩⁧⁩ بدء الخدمةFabricApplicationUpgradeUpgrade⁧⁩cmdlet⁧⁩ أو⁧⁩⁧⁩ ترقية التطبيق⁧⁩ عملية الثبات ⁧⁩.
7. يتحقق ⁧⁩المشغل⁧⁩ من تقدم الترقية باستخدام ⁧⁩⁧⁩ GetApplicationUpgradeProgressAsync ⁧⁩ طريقة⁧⁩، أو⁧⁩⁧⁩ Get - ServiceFabricApplicationUpgrade ⁧⁩ cmdlet،⁧⁩ أو⁧⁩⁧⁩Get Application Upgrade ⁧⁩ عملية الثبات ⁧⁩.
8. إذا لزم الأمر، يقوم ⁧⁩المشغل⁧⁩ بتعديل وإعادة تطبيق ضوابط ترقية التطبيق الحالية باستخدام ⁧⁩⁧⁩ UpdateApplicationUpgradeAsync⁧⁩ طريقة⁧⁩ أو⁧⁩⁧⁩ Update - Service - FabricApplicationUpgrade ⁧⁩ cmdlet ⁧⁩ أو⁧⁩⁧⁩ تحديث عملية ⁧⁩ REST ⁧⁩.
9. إذا لزم الأمر، يقوم ⁧⁩المشغل⁧⁩ بإعادة ترقية التطبيق الحالي باستخدام ⁧⁩⁧⁩ طريقة التراجع ApplicationUpgradeAsync ⁧⁩ ⁧⁩ أو ⁧⁩⁧⁩ بدء الخدمة FabricApplicationRolllicationRollback ⁧⁩ سم ⁧⁩ أو⁧⁩⁧⁩عملية ترقية تطبيق التراجع ⁧⁩ REST ⁧⁩.
10. يقوم نسيج الخدمة بترقية التطبيق المستهدف الذي يعمل في المجموعة دون فقدان توفر أي من الخدمات المكونة له.

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

صيانة

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

إزالة

1. يمكن ⁧⁩للمشغل⁧⁩ حذف حالة معينة من خدمة قيد التشغيل في المجموعة دون إزالة التطبيق بأكمله باستخدام ⁧⁩⁧⁩DeleteServiceAsync⁧⁩طريقة ⁧⁩ أو ⁧⁩⁧⁩ Remove - ServiceFabricService ⁧⁩ cmdlet⁧⁩ أو⁧⁩⁧⁩خدمة الحذف ⁧⁩ عملية الثبات ⁧⁩.
2. يمكن للمشغل ⁧⁩ ⁧⁩ أيضًا حذف مثيل التطبيق وجميع خدماته باستخدام ⁧⁩⁧⁩DeleteApplicationAsync ⁧⁩طريقة ⁧⁩ أو⁧⁩⁧⁩ Remove - ServiceFabricApplication⁧⁩ cmdlet⁧⁩ أو⁧⁩⁧⁩ Delete Application⁧⁩ REST operation⁧⁩.
3. بمجرد توقف التطبيق والخدمات، يمكن ⁧⁩للمشغل⁧⁩ إلغاء توفير نوع التطبيق باستخدام طريقة⁧⁩⁧⁩UnprovisionApplicationAsync⁧⁩ ⁧⁩ أو⁧⁩⁧⁩Unregister - Service - FabricApplicationType⁧⁩ cmdlet⁧⁩ أو⁧⁩⁧⁩عملية ⁧⁩ 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 بحذف مجلدات التطبيق بمجرد إخلاء التطبيق من العقدة.

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

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

• Reliable Actors
• Reliable Services
• نشر تطبيق
• ترقية التطبيق
• ⁧⁩ نظرة عامة على قابلية الاختبار⁧⁩