Michael Johnsonبعد النشر، يمكن لـ Durable Object نشط لدى Cloudflare مواصلة العمل بالإصدار الحالي من التعليمات البرمجية إلى أن يدخل في حالة السبات أو تنقضي المهلة المحددة. وفي 30 أكتوبر، جعلت Cloudflare التحديث المؤجل هو الإعداد الافتراضي، بمهلة قصوى تبلغ خمس دقائق. ويغيّر ذلك سلوك الكائنات التي تعمل بالفعل أثناء النشر: فليس من الضروري أن يقطع التحديث عملها فورًا، وقد تستمر اتصالات WebSocket المدعومة عند الانتقال إلى إصدار جديد.
ما الذي يحدث أثناء النشر
Durable Objects هي كائنات يمكن الوصول إليها، لها هوية وحالة مستديمتان، وتستخدمها Cloudflare، من بين أمور أخرى، لتنسيق العملاء والمهام الطويلة وجلسات WebSocket. ويعمل إصدار واحد فقط من التعليمات البرمجية على الكائن الواحد في الوقت نفسه. لذلك، عند الاستبدال الفوري، قد يُعاد ضبط المثيل النشط، ما يقطع العمل أو الاتصالات.
أما السيناريو الافتراضي الآن فهو الانتقال المؤجل. بعد النشر، يواصل الكائن النشط معالجة الطلبات بالإصدار القديم. وإذا دخل في حالة السبات قبل انقضاء المهلة، فسيبدأ الإصدار الجديد عند ورود الطلب التالي. وإذا انقضت الدقائق الخمس وظل الكائن نشطًا، فستتم إعادة ضبطه ليعتمد الإصدار الجديد. ويكتمل نشر Worker على نحو مستقل؛ إذ يتعلق التأخير بموعد بدء الكائن النشط بالفعل بتنفيذ التعليمات البرمجية الجديدة.
من المستفيد من ذلك
يهم هذا التغيير الخدمات التي يُبقي فيها كائن واحد العمل مستمرًا بين الطلبات، مثل الجلسات الطويلة أو تنسيق عدة عملاء أو اتصال WebSocket. ويتيح الانتقال المؤجل فترة يمكن خلالها للكائن إكمال نشاطه الجاري بصورة طبيعية أو الدخول في حالة السبات قبل التحديث. وبالنسبة إلى WebSocket، توضح Cloudflare شرطًا منفصلًا: تظل الاتصالات التي تستخدم Hibernation API متصلة عندما يعتمد الكائن التعليمات البرمجية الجديدة بعد دخوله في حالة السبات.
والخلاصة العملية للفريق هي تحديد الكائنات النشطة التي قد تظل مشغولة لأكثر من بضع دقائق، والتحقق من واجهة WebSocket البرمجية المستخدمة. فهذا يحدد ما إذا كان ترتيب النشر الجديد سيمنح التطبيق فرصة لانتقال سلس، أم أن الاتصال سينتهي عند فرض التحديث.
خمس دقائق مهلة وليست ضمانًا
تصف Cloudflare التحديث المؤجل بأنه أفضل جهد ممكن: فقد يُعاد ضبط الكائن قبل ذلك، مثلًا عند تحديث بيئة التشغيل. وإذا لم يدخل في حالة السبات قبل انتهاء المهلة القصوى، فستطبق المنصة الإصدار الجديد عبر إعادة الضبط. لذلك، ينبغي حفظ الحالة المهمة في تخزين دائم وتصميم العمليات بحيث تراعي احتمال إعادة تشغيلها. وتوصي وثائق Cloudflare بحفظ الحالة التي ينبغي أن تستمر بعد عمليات النشر بدلًا من الاعتماد على ذاكرة المثيل النشط.
يمكن للفرق تجاوز السلوك في إعدادات Durable Objects، إما باختيار وضع التحديث الفوري أو تحديد مهلة أخرى للانتقال المؤجل. وقد يفيد الوضع الفوري عندما يلزم تفعيل الإصدار الجديد على الفور، مثلًا عند إصدار إصلاح عاجل؛ أما المهلة الأطول فقد تمنح الكائنات وقتًا إضافيًا، لكنها تطيل أيضًا الفترة التي تعالج فيها بعض المثيلات الطلبات بالإصدار القديم.
ما الذي ينبغي التحقق منه قبل النشر التالي
تحقق من توافق الطلبات بين Worker وDurable Object خلال الفترة التي قد يعملان فيها بإصدارين مختلفين. وتأكد من حفظ الحالة المهمة في التخزين، لا في الذاكرة وحدها. وبالنسبة إلى WebSocket، تحقق مما إذا كان التطبيق يستخدم Hibernation API؛ إذ قد تنتهي الاتصالات العادية عند تطبيق التحديث. وإذا كان النشر يتطلب انتقالًا فوريًا، فتحقق من إعداد الوضع صراحةً بدلًا من الاعتماد على القيمة الافتراضية الجديدة.
وهكذا، غيّرت Cloudflare التسوية الافتراضية عند النشر: إذ تحصل الكائنات النشطة على وقت محدود للانتقال بصورة طبيعية، مع احتفاظ الفرق بإمكانية تسريع التحديث عبر الإعدادات. وأهم ما يمكن للمطور فعله هو التحقق من التوافق بين الإصدارين القديم والجديد، ومن حفظ الحالة ونوع WebSocket قبل النشر التالي.
