تمرين - إضافة عمليات التحقق من صحة تطبيق الويب
يحتاج Contoso Shoes إلى طريقة للتحقق من صحة تطبيق الويب على مستوى واجهة برمجة التطبيقات، بالإضافة إلى تبعياته. تريد تنفيذ نقطة نهاية فحص صحة مخصصة على التطبيق، والتي تبلغ عن حالة صحة واجهة برمجة التطبيقات على فترات منتظمة.
الحالة الحالية والمشكلة الحالية
في التصميم الحالي، يسجل التطبيق أخطاء عند وجود مشكلات في وقت التشغيل في التعليمات البرمجية لواجهة برمجة التطبيقات أو تفشل استدعاءات الخدمات التابعة، مثل استعلامات قاعدة البيانات الفاشلة. هذا الأسلوب مفيد في استكشاف المشكلات وإصلاحها بعد وقوع حادث.
ومع ذلك، فإن النهج ليس استباقيا. لا تحتوي Azure App Service وأدوات المراقبة الخارجية على طريقة للتحقق من الحالة الصحية للتطبيق نفسه. تؤثر هذه الفجوة على العديد من حالات الاستخدام، مثل كيفية توزيع الحمل. يعتمد التنفيذ الحالي فقط على أفضل جهد تبذله خطة App Service لتوزيع نسبة استخدام الشبكة بالتساوي عبر المثيلات دون التحقق من صحة التطبيق. في حادث واحد تم الإبلاغ عنه، تم توجيه نسبة استخدام الشبكة إلى مثيلات App Service غير السليمة، مما أدى إلى فشل الطلبات.
المواصفات
مهمتك هي إنشاء خدمة صحية مخصصة كملحق للتعليمات البرمجية المنشورة بالفعل.
تقديم واجهة برمجة تطبيقات للتحقق من الصحة في التطبيق الخاص بك. يجب أن تتحقق واجهة برمجة التطبيقات من الحالة الصحية للتطبيق وتبعياته وإرجاع إشارة الحالة. على سبيل المثال، يجب أن تتحقق واجهة برمجة التطبيقات بشكل دوري من عمليات القراءة والكتابة إلى Azure Cosmos DB. قم بتنفيذ هذه الوظائف كفحوصات منفصلة بحيث يتم التحقق من القراءات والكتابة بشكل مستقل.
تلميح
توسيع فحص الصحة إلى الخدمات غير الوظيفية، مثل Azure Key Vault وAzure Container Registry. هذه الخطوة مهمة، لأنه إذا واجهت هذه الخدمات انقطاعا، فقد تلاحظ تأثيرا في القدرة على التوسع أو تحمل إعادة تشغيل مثيل App Service.
يجب استدعاء نقطة نهاية واجهة برمجة التطبيقات للتحقق من الصحة بشكل متكرر، بواسطة مصادر متعددة، ولا ينبغي أن تقلل من أداء واجهة برمجة التطبيقات. على سبيل المثال، يجب أن ترسل خطة Azure App Service طلبات إلى نقطة نهاية مرتين في الدقيقة واتخاذ قرارات مستنيرة حول مثيلات App Service لتوزيع نسبة استخدام الشبكة إليها.
تحسين أداء واجهة برمجة تطبيقات التحقق من الصحة عن طريق التخزين المؤقت للنتائج في الذاكرة لمدة 10 ثوان. لا يجب أن ينتج عن كل استعلام إلى نقطة نهاية التحقق من الصحة استدعاء الخلفية. يمكن تقديم بعض هذه الاستجابات من ذاكرة التخزين المؤقت.
توفير بيانات التحقق من الصحة في Azure Monitor للتحليل المستقبلي.
النهج المُستحسن
للبدء في تصميمك، نوصي باتباع النهج التالي:
1-عمليات التحقق من الصحة
يجب إجراء جميع الاستعلامات التي ترسلها واجهة برمجة تطبيقات التحقق من الصحة بشكل غير متزامن وبالتوازي. تصميم عمليات التحقق من السلامة مقابل المكونات الهامة مثل قاعدة البيانات. يجب أن تتحقق واجهة برمجة التطبيقات بشكل دوري من عمليات القراءة والكتابة. قم بتنفيذ هذه الوظائف كفحوصات منفصلة بحيث يتم التحقق من القراءات والكتابة بشكل مستقل.
استخدم الطلبات التي تحاكي سلوك التطبيق الحقيقي دون وضع الكثير من الحمل على الخدمات فقط من تحقيقات السلامة. لاختبار طلبات الكتابة أيضا، تحتاج إلى تصميم طريقة لإزالة بيانات الاختبار بكفاءة بحيث لا يتم مزجها مع بيانات المستخدم الحقيقية.
2-نمط التخزين المؤقت
لتجنب التحميل الزائد لخدمات انتقال البيانات من الخادم مع فحوصات السلامة، يجب أن تقوم واجهة برمجة تطبيقات التحقق من الصحة بتخزين النتائج مؤقتا لعدد من الثوان القابلة للتكوين. فكر في الطرق الممكنة لتحقيق هذا الهدف.
راجع عملك
فيما يلي مثال على خدمة صحة التطبيق. هل قمت بتغطية جميع الجوانب في تصميمك؟
- هل نقطة نهاية التحقق من الصحة متوافقة مع ميزة التحقق من الصحة في خدمة تطبيق Azure؟
- هل قمت بتضمين عمليات التحقق من تبعيات وقت التشغيل؟ ما الذي استخدمته كوكيل/اختبار؟
- قراءة/كتابة Cosmos DB
- واجهة برمجة تطبيقات الجهات الخارجية
- هل قمت بتخزين نتائج فحص السلامة مؤقتا لتقليل النفقات العامة للأداء؟
- هل قمت بتسجيل الأحداث في فحوصات السلامة الخاصة بك؟ لاحظ النجاحات والفشل؟
- هل قمت بتطبيق أخذ عينات سجل Azure Application Insights على سجلات التحقق من الصحة؟