سيناريوهات قابلية اختبار Service Fabric: اتصالات الخدمة
تظهر الخدمات المصغرة والتصميمات الموجهة نحو الخدمة بشكل طبيعي في Azure Service Fabric. في هذه الأنواع من التصميمات المُوزَّعة، تتكون تطبيقات الخدمات المصغرة التي تكون مكونةً عادةً من خدمات متعددة تحتاج إلى التحدث مع بعضها البعض. حتى في أبسط الحالات، يكون لديك عموماً خدمة ويب "عديمة الحالة" على الأقل وخدمة تخزين بيانات ذات حالة تحتاج إلى الاتصال.
يُعد الاتصال من خدمة إلى خدمة نقطة تكامل مهمة للتطبيق، لأن كل خدمة تعرض واجهة برمجة تطبيقات بعيدة للخدمات الأخرى. يتطلب العمل مع مجموعة من حدود واجهة برمجة التطبيقات التي تتضمن إدخال/إخراج بشكل عام بعض العناية، مع قدرٍ لا بأس به من الاختبار والتحقق من الصحة.
هناك العديد من الاعتبارات التي يجب مراعاتها عندما يتم توصيل حدود الخدمة هذه معاً في نظامٍ موزعٍ:
- بروتوكول النقل. هل ستستخدم HTTP لزيادة إمكانية التشغيل التفاعلي، أو بروتوكول ثنائي مخصص لتحقيق أقصى قدر من معدل النقل؟
- معالجة الأخطاء. كيف سيتم التعامل مع الأخطاء الدائمة والعابرة؟ ماذا سيحدث عندما تنتقل الخدمة إلى عُقدة مختلفة؟
- المهلات وزمن الانتقال. في التطبيقات متعددة المستويات، كيف ستتعامل كل طبقة خدمة مع زمن الانتقال من خلال المكدس وللمستخدم؟
سواء كنت تستخدم أحد مكونات اتصالات الخدمة المُضمَّنة التي توفرها Service Fabric أو كنت تنشئ مكونك الخاص، فإن اختبار التفاعلات بين خدماتك يُعد أمراً بالغ الأهمية لضمان المرونة في تطبيقك.
الاستعداد لنقل الخدمات
قد تتحرك مثيلات الخدمة بمرور الوقت. هذا صحيح لا سيما عندما يتم تكوينها باستخدام مقاييس الحمل لتحقيق التوازن الأمثل للموارد المُصممة خصيصاً. تنقل Service Fabric مثيلات الخدمة خاصتك لزيادة توافرها إلى أقصى حد حتى أثناء الترقيات وتجاوز الفشل والتوسع والمواقف الأخرى التي تحدث على مدار مدة بقاء النظام المُوزَّع.
أثناء تنقل الخدمات في المجموعة، يجب أن يكون عملاؤك والخدمات الأخرى مستعدين للتعامل مع سيناريوهين عند التحدث إلى خدمة:
- تم نقل مثيل الخدمة أو النسخة المتماثلة للقسم منذ آخر مرة تحدثت إليها. هذا جزء طبيعي من دورة حياة الخدمة، ويجب توقع حدوثه خلال مدة بقاء التطبيق.
- مثيل الخدمة أو النسخة المتماثلة للقسم في طور النقل. على الرغم من أن تجاوز فشل الخدمة من عُقدة إلى أخرى يحدث بسرعة كبيرة في Service Fabric، فقد يكون هناك تأخير في التوفر إذا كان مكون الاتصال في خدمتك يبدأ ببطء.
يُعد التعامل مع هذه السيناريوهات بأمانٍ أمراً مهماً لنظام التشغيل السلس. للقيام بذلك، ضع في اعتبارك ما يلي:
- تحتوي كل خدمة يمكن الاتصال بها على عنوان تستمع إليه (على سبيل المثال، HTTP أو WebSockets). عند نقل مثيل خدمة أو قسم، تتغير نقطة نهاية العنوان خاصته. (ينتقل إلى عُقدة مختلفة بعنوان IP مختلف.) إذا كنت تستخدم مكونات الاتصال المُضمَّنة، فستتعامل مع إعادة حل عناوين الخدمة نيابةً عنك.
- قد تكون هناك زيادة مؤقتة في زمن انتقال الخدمة حيث يبدأ مثيل الخدمة المستمع خاصته مرةً أخرى. يعتمد هذا على مدى سرعة فتح الخدمة للمستمع بعد نقل مثيل الخدمة.
- يجب إغلاق أي اتصالات موجودة وإعادة فتحها بعد فتح الخدمة على عُقدة جديدة. يتيح إيقاف تشغيل العُقدة الآمنة أو إعادة تشغيلها وقتاً لإيقاف تشغيل الاتصالات الحالية بأمانٍ.
اختباره: نقل مثيلات الخدمة
باستخدام أدوات قابلية اختبار Service Fabric، يمكنك تأليف سيناريو اختبار لاختبار هذه المواقف بطرقٍ مختلفةٍ:
نقل النسخة المتماثلة الأساسية للخدمة "ذات الحالة".
يمكن نقل النسخة المتماثلة الأساسية لقسم الخدمة "ذات الحالة" لأي عددٍ من الأسباب. استخدم هذا لاستهداف النسخة المتماثلة الأساسية لقسم معين لترى كيف تتفاعل خدماتك مع النقل بطريقة مُتحكَّم بها للغاية.
PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyServiceإيقاف عُقدة.
عند إيقاف عقُدة، تنقل Service Fabric جميع مثيلات الخدمة أو الأقسام التي كانت موجودة على تلك العُقدة إلى إحدى العُقد الأخرى المتوفرة في المجموعة. استخدم هذا لاختبار موقف يتم فيه فقد عُقدة من نظام مجموعتك ويجب نقل جميع مثيلات الخدمة والنسخ المتماثلة الموجودة على تلك العُقدة.
يمكنك إيقاف عُقدة باستخدام PowerShell Stop-ServiceFabricNode cmdlet:
PS > Stop-ServiceFabricNode -NodeName Node_1
الحفاظ على توفر الخدمة
كنظامٍ أساسي، تم تصميم Service Fabric لتوفير قابلية وصول عالية لخدماتك. ولكن في الحالات القصوى، لا تزال مشاكل البنية التحتية الأساسية تتسبب في عدم توفرها. من المهم اختبار هذه السيناريوهات أيضاً.
تستخدم الخدمات "ذات الحالة" نظاماً قائماً على الحصة لتكرار الحالة من أجل قابلية الوصول العالية. وهذا يعني أنه يجب أن تكون حصة النُسخ المتماثلة متاحةً لتنفيذ عمليات الكتابة. في حالات نادرة، مثل فشل الأجهزة على نطاقٍ واسعٍ، قد لا تتوفر حصة من النسخ المتماثلة. في هذه الحالات، لن تتمكن من إجراء عمليات الكتابة ولكنك ستظل قادراً على إجراء عمليات القراءة.
اختباره: عدم توفر عملية الكتابة
باستخدام أدوات قابلية اختبار Service Fabric، يمكنك إدخال خطأ يؤدي إلى فقدان الحصة كاختبار. على الرغم من أن مثل هذا السيناريو نادر الحدوث، فمن المهم أن يكون العملاء والخدمات التي تعتمد على الخدمة "ذات الحالة" على استعداد للتعامل مع المواقف التي لا يمكنهم فيها تقديم طلبات الكتابة إليها. من المهم أيضاً أن تكون الخدمة "ذات الحالة" نفسها على درايةٍ بهذا الاحتمال ويمكنها توصيله بأمانٍ إلى المتصلين.
يمكنك الحث على فقدان الحصة باستخدام PowerShell Invoke-ServiceFabricPartitionQuorumLoss cmdlet:
PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20
في هذا المثال، عيَّنا QuorumLossMode إلى QuorumReplicas للإشارة إلى أننا نريد الحث على فقدان الحصة دون إزالة جميع النسخ المتماثلة. بهذه الطريقة، لا تزال عمليات القراءة ممكنة. لاختبار سيناريو حيث يكون القسم بأكمله غير متوفر، يمكنك تعيين رمز التبديل هذا إلى AllReplicas.