مختبر ميزانية المهلة وإلغاء الطلبات: مشاريع تخرج هندسة البرمجيات

المشكلة التي يخفيها timeout عام

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

ابدأ بتحديد معنى deadline: لحظة زمنية يجب أن تنتهي عندها العملية وفق ساعة العميل، بينما timeout مدة نسبية تحول عادة إلى deadline عند إرسال الطلب. توثيق gRPC يوضح أن العميل لا يفرض مهلة افتراضية تلقائياً في كل الحالات، لذلك ينبغي للتطبيق تحديدها صراحة. سجل زمن الوصول والمهلة المتبقية عند كل قفزة، ولا تقارن ساعات أجهزة مختلفة بلا مزامنة أو معالجة انحراف الساعة.

ابن سلسلة قصيرة قابلة للفحص

أنشئ client يطلب خدمة order، والخدمة تستدعي inventory ثم pricing. اجعل كل خدمة تقبل مدة عمل مصطنعة، مثلاً 80 أو 180 أو 400 ملي ثانية، وتستجيب بإحدى الحالات: نجاح، انتظار، أو خطأ قابل للتكرار. لا حاجة إلى قاعدة بيانات؛ يكفي مخزن ذاكرة يحمل رقم طلب عشوائياً وتسجيلاً للأحداث. طبقة المحاكاة تسمح بتكرار السيناريو نفسه مع تغيير قيمة مهلة واحدة.

اعرض لكل حدث وقتاً نسبياً من بدء الطلب، اسم الخدمة، المهلة المتبقية، حالة السياق، وسبب الإنهاء. تجنب تسجيل بيانات شخصية أو نصوص طلبات؛ معرف اصطناعي كافٍ لربط السطور. اجعل النظام يتعامل مع الطلبات المتزامنة بمعرفات منفصلة حتى لا تختلط الأحداث. وثائق gRPC تشرح انتقال deadline إلى الاستدعاءات اللاحقة في مكتباتها المدعومة؛ لا تفترض أن كل wrapper مخصص ينقل السياق تلقائياً.

مثال محسوب قبل تحويله إلى تجربة

افترض أن المهلة الكلية 500 ms، وأن التحقق المحلي يستهلك 60 ms، ثم يستهلك inventory نحو 240 ms، وتحتاج pricing إلى 170 ms. يبقى تقريباً 30 ms قبل الموعد، من دون احتساب النقل وجدولة النظام؛ لذا قد ينجح الاختبار على جهاز ويخفق على جهاز آخر. هذه أرقام سيناريو توضيحي يختارها الفريق، وليست قياساً عاماً لأداء gRPC. اطبع الموازنة كخط زمني لا كمتوسط واحد.

في التشغيل الثاني اجعل inventory ينتظر 320 ms؛ يجب أن يرى pricing مهلة أقصر أو سياقاً ملغى، ثم تنتهي المهمة التابعة بدلاً من استمرارها بصمت. سجّل ما إذا كان client تلقى deadline exceeded، وهل أغلقت الخدمة القناة أو أوقفت العمل التعاوني. لا تخلط بين طلب انتهى عند المستخدم ومهمة أوقفت فعلاً؛ التوثيق الرسمي يطلب من معالجات الخادم أن تستجيب للإلغاء وأن توقف العمل الذي لم يعد مطلوباً.

اكتب عقد الإلغاء لكل خدمة

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

افصل أخطاء deadline exceeded عن cancelled وعن فشل شبكة، وسجلها في حقول مستقلة. إذا أعادت خدمة داخلية خطأً، لا تحوله إلى نجاح جزئي إلا إذا عرف العقد أن النتيجة الجزئية صالحة. لا تجعل إعادة المحاولة تلقائية لكل انتهاء مهلة؛ إعادة الطلب قد تضاعف عملاً غير idempotent. يمكن ربط الدراسة بمقال إعادة تشغيل سياق التتبع، مع بيان أن المختبر الحالي يركز على سياق الطلب ووقف العمل لا إعادة بناء trace تاريخي.

اختبارات القبول وحالات الفشل

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

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

ما الذي لا يقيسه المختبر؟

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

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