مشاركة عبر

أفضل الممارسات المتبعة عند تصميم تطبيق Azure Service Fabric

  • مقالة

توفر هذه المقالة إرشادات عن أفضل الممارسات لإنشاء التطبيقات والخدمات على Azure Service Fabric.

الإلمام بـService Fabric

إرشادات حول تصميم التطبيقات

التعرف على البنية العامة لتطبيقات Service Fabric و اعتبارات التصميم الخاصة بها.

اختيار بوابة واجهة برمجة التطبيقات

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

خدمات Stateless

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

موعد استخدام خدمات stateful

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

حدد الإطار الزمني لاستيفاء البيانات:

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

توفير معدل التكاليف وتحسين التوافر:

  • يمكنك تقليل التكاليف باستخدام الخدمات ذات الحالة لأنك لا تتحمل تكاليف الوصول إلى البيانات والمعاملات من المتجر البعيد، ولأنك لست بحاجة إلى استخدام خدمة أخرى، مثل Azure Cache for Redis.
  • يعد استخدام الخدمات ذات الحالة الخاصة في المقام الأول للتخزين وليس للحوسبة أمرًا مكلفًا، ونحن لا نوصي به. فكر في الخدمات stateful على أنها حساب باستخدام التخزين المحلي الرخيص.
  • عن طريق إزالة التبعيات على الخدمات الأخرى، يمكنك تحسين توافر الخدمة الخاصة بك. تؤدي إدارة الحالة باستخدام قابلية وصول عالية في نظام المجموعة إلى عزلك عن أوقات تعطل الخدمة الأخرى أو مشكلات زمن الانتقال.

طريقة التعامل مع خدمات Reliable

تمكّنك خدمات Fabric وReliable من إنشاء خدمات stateless وstateful بسهولة. لمزيد من المعلومات، راجع مقدمة إلى خدمات Reliable.

  • احترم دائمًا رمز الإلغاء في RunAsync() طريقة الخدمات عديمة الحالة وذات الحالة وطريقة ChangeRole() للخدمات ذات الحالة. إذا لم تقم بذلك، فإن Service Fabric لا تعرف ما إذا كان يمكن إغلاق خدمتك. على سبيل المثال، إذا لم تحترم رمز الإلغاء، فقد تحدث أوقات أطول لترقية التطبيق.
  • افتح وأغلق مستمعي الاتصال في الوقت المناسب، وراعِ رموز الإلغاء.
  • لا تخلط أبدًا التعليمة البرمجية للمزامنة باستخدام تعليمة برمجية غير متزامنة. على سبيل المثال، تجنب استخدام .GetAwaiter().GetResult() في استدعائتك غير المتزامنة. استخدم غير متزامن طوال الطريق عبر مكدس الاستدعاءات.

طريقة التعامل مع Reliable Actors

تمكنك خدمة Fabric Reliable Actors من إنشاء ممثلين ظاهريين يتمتعون بالحالة بسهولة. لمزيد من المعلومات، راجع مقدمة عن Reliable Actors.

  • فكر بجدية في استخدام رسائل pub / sub بين الممثلين لتوسيع نطاق تطبيقك. تشمل الأدوات التي تقدم هذه الخدمة Open Source SoCreate Service Fabric Pub / Sub و Azure Service Bus .
  • اجعل حالة الممثل دقيقة بقدر المستطاع .
  • إدارة دورة حياة المستخدم. احذف المستخدمين إذا كنت لن تستخدمها مرة أخرى. يعد حذف المستخدمين غير الضرورية أمرًا مهمًا بشكل خاص عند استخدام موفر الحالة المتغيرة ، لأن كل الحالات مخزنة في الذاكرة.
  • بسبب التزامن القائم على الدور، من الأفضل استخدام المستخدمين ككائنات مستقلة. تجنب إنشاء رسوم بيانية لاستدعاءات الأسلوب المتزامن متعدد المستخدمين (والتي من المرجح أن تصبح كل منها مكالمة شبكة منفصلة) أو تنشئ طلبات مستخدمين دائرية. ستؤثر هذه بشكل كبير في الأداء وتغيير الحجم.
  • لا تخلط التعليمة البرمجية المزامنة مع تعليمة برمجية غير متزامنة. استخدم غير متزامن باستمرار لمنع المشاكل المنطوية على الأداء.
  • تجنب إجراء مكالمات طويلة الأمد مع المستخدمين. ستحظر المكالمات طويلة المدى المكالمات الأخرى إلى نفس المستخدم، بسبب التزامن القائم على الدوران.
  • إذا كنت تتواصل مع خدمات أخرى باستخدام خدمة النسيج عن بُعد وكنت تنشئ ServiceProxyFactory، فأنشئ المصنع على مستوى خدمة المستخدم و لا على مستوى المستخدم.

تشخيص خاص بالتطبيقات

كن دقيقًا بشأن إضافة تسجيل التطبيق في استدعاءات الخدمة. سيساعدك على تشخيص السيناريوهات التي تتصل فيها الخدمات ببعضها بعضًا. على سبيل المثال، عندما تستدعي A مكالمات B تستدعي C D، فقد تفشل المكالمة في أي مكان. إذا لم يكن لديك ما يكفي من التسجيلات، فمن الصعب تشخيص الأعطال. إذا تم تسجيل الكثير من الخدمات بسبب حجم الاستدعاءات، فتأكد على الأقل من تسجيل الأخطاء والتحذيرات.

إرشادات التصميم في Azure